Diffusion dynamique contre design web adaptatif

Le design web adaptatif, Responsive Web Design

Dans cette solution, le serveur web envoie les mêmes fichiers HTML et CSS quel que soit le client (ordinateur de bureau, tablette, téléphone). L’adaptation visuelle aux écrans de petite taille est faite grâce au module Media queries apparu avec CSS3. Le principe général est d’outrepasser des déclarations CSS dédiées à l’affichage sur un grand écran lorsque la largeur de l’écran est inférieure à un certain nombre de pixels (seuil appelé “point de rupture”). Cela permet, sur un petit écran, de redimensionner ou déplacer un élément, de modifier n’importe quel attribut de style qui lui est appliqué, ou bien encore de masquer son affichage s’il est jugé visuellement superflu sur un mobile.

La diffusion dynamique, Dynamic Serving

Dans ce cas, le serveur détecte l’agent utilisateur (valeur User-Agent contenue dans l’en-tête HTTP) pour déterminer avec quel type de client (ordinateur de bureau, tablette, téléphone) il est en négociation. Cette détection d’agent permet d’envoyer du code HTML-CSS-JS et des médias (images, vidéo, etc.) différents selon le client. En bref, les utilisateurs mobile et bureau (desktop) ne reçoivent pas la même chose à partir de la même URL, contrairement au design web adaptatif.

Les avantages de la diffusion dynamique

Meilleure performance

La version que reçoit le mobile n’est pas seulement adaptée visuellement : le mécanisme de la diffusion dynamique permet de n’envoyer que le code nécessaire et des médias optimisés. Ainsi, le mobile n’a pas à recevoir des kilo-octets de code HTML-CSS dont il n’a que faire. Le travail sur la performance (poids, vitesse) devient alors extrêmement simple et efficace. C’est le plus gros avantage de la solution, et il peut être majeur dans certains contextes comme le commerce électronique où il y a un lien clair entre la réactivité et la transformation.

Ne pas déshabiller Pierre pour habiller Paul

Dans le cadre du design web adaptatif, on fait du “mobile en premier” et on adapte à l’ordinateur ensuite, ou bien l’inverse. Cela entraîne toujours des compromis pour la version d’affichage déclinée en second lieu. Avec mon écran 5K, il m’arrive souvent de tomber sur un site web qui a manifestement été pensé “Mobile First”, ce qui se traduit inévitablement par un appauvrissement autant graphique qu’ergonomique. Et sur un téléphone, nombreux sont les sites web qui ont de si navrantes déclinaisons pour mobile qu’on préférerait encore que l’on nous serve la version bureau. Avec la diffusion dynamique, il est inutile de faire des compromis entre les versions web et mobile.

Interactions optimisées

Si votre site est transactionnel et/ou implique des interactions complexes (pensez formulaires, processus de réservation, de vente, etc.), il est possible de concevoir des expériences utilisateur radicalement différentes. L’amélioration n’est peut-être pas énorme pour un site de contenus comme un blogue ou un magazine, mais pour la vente en ligne, c’est un atout important. Avec la diffusion dynamique, vous pouvez créer une expérience unique, plus proche de celle d’une application, pour vos utilisateurs sur mobile.

Meilleur des deux mondes

La diffusion dynamique n’exclut pas du tout le design web adaptatif. Il n’est pas interdit et même recommandé d’utiliser les media-queries dans le cadre de la diffusion dynamique afin d’adapter au mieux l’aspect visuel aux différentes tailles et orientations des écrans mobiles (téléphones, tablettes).

Les inconvénients

Le coût

Plus vos versions sont différentes, plus vous aurez des coûts de maintenance. Et si vous avez poussé un peu loin l’optimisation, vous avez en quelque sorte deux sites différents à entretenir. De plus, les prérequis techniques sont plus élevés que pour le design web adaptatif, qui est à la portée de tous, ce qui a aussi bien sûr un coût.

Détection ratée

La détection de l’agent utilisateur passe par la maintenance sur le serveur d’un dictionnaire des agents utilisateurs possibles. Cette liste doit impérativement être maintenue à jour au risque de ne pas détecter de nouveaux agents. En outre, une erreur de détection étant toujours possible, il est préférable de prévoir pour l’utilisateur la possibilité de changer la version qui lui est distribuée.

Et Google dans tout ça ?

Le grand dieu Google dit préférer le design web adaptatif. Et le monstre de Moutain View n’a pas jugé utile de motiver rationnellement cette préférence, ce qui est à l’image de bien d’autres messages divins. Il est seulement dit : “Le responsive design est le modèle que nous recommandons”. Pourquoi ? Vous n’avez pas à savoir, misérable mortel. Nous avons toutefois une idée de la raison : Google veut à tout prix éviter les techniques de dissimulation (cloaking) basées sur la détection d’agent. Et les tentatives de triche sont bien plus aisées à débusquer sur un site en design web adaptatif.

Cela dit, est-ce que Google pénalise d’une façon ou d’une autre cette solution ? La réponse est non, en aucun cas si vous respectez une règle simple : l’utilisation d’un en-tête “HTTP Vary” valide pour signaler que vous modifiez le contenu en fonction de l’agent utilisateur (Vary: User-Agent).

Vous ne voudriez définitivement pas vous fâcher avec la divinité suprême du web… alors, n’oubliez pas :

GET /page-1 HTTP/1.1
Host: www.example.com
(...etc.)

HTTP/1.1 200 OK
Content-Type: text/html
Vary: User-Agent
Content-Length: 6785
(...etc.)

Pour vous rassurer, John Mueller de Google a assuré il y a quelques années déjà de l’agnosticité du moteur de recherche en la matière (à partir de 13 min. 5) :

So, if you use responsive or dynamic serving or separate mobile URLs, it is essentially up to you. It is something that you can also mix, where you say: ‘well, part of my website is fully responsive, and part of it just sniffing user agent to make sure that we can like serve them properly.’ From my point of view, I just really make sure that everything works on mobile as well.

John Mueller ajoute que le choix est vraiment plus une question d’utilisabilité que de SEO.

L’en-tête HTTP “Vary” a aussi le grand intérêt d’éviter au système de cache présent chez certains fournisseurs d’accès à Internet (ISP) d’envoyer à un utilisateur de mobile une version desktop déjà mise en cache.

Un mot sur les URLs distinctes

Une solution proche de la diffusion dynamique est de réaliser la détection, mais de servir sur des URLs différentes, comme www.example.com et m.example.com. Cette technique n’apporte pas d’avantage décisif (voire aucun à ma connaissance), mais certainement des problèmes quand elle n’est pas parfaitement implémentée. Prenons par exemple le cas où on vous a envoyé un lien d’un mobile et que vous vous retrouvez prisonnier en le consultant sur votre grand écran de la version m.example.com. La seule échappatoire semble alors de corriger manuellement l’URL… jusqu’à votre hurlement de frustration quand vous découvrez que désormais www.example.com vous redirige sans pitié sur m.example.com à cause d’un cookie idiot. Il y a de grandes chances que cela vous soit déjà arrivé.

Si vous choisissez cette option des URLs distinctes, n’oubliez pas d’indiquer la relation bidirectionnelle entre les deux URLs, avec une balise link et les attributs rel="canonical" et rel="alternate". Cela peut être fait dans le head ou dans le sitemap. N’omettez pas non plus d’émettre un code HTTP 302 à la redirection. Si vous respectez ces consignes, vous éviterez de vous brouiller avec Googlebot.

Dans tous les cas, évitez les détections côté client. Elles introduisent une latence, le temps de charger et exécuter le code JavaScript nécessaire.

Que choisir ?

Tout dépend de votre budget et de votre site. Si votre budget est serré et que votre site est simple et léger, sans beaucoup d’interactions, la solution est sans conteste le site en design web adaptatif. Si votre projet ne correspond pas à cette description, vous pouvez commencer à envisager la diffusion dynamique.

Il faut aussi considérer votre clientèle : si elle est très majoritairement sur mobile, il pourrait être utile de considérer la diffusion dynamique, quelle que soit la nature de votre site.