Diffusion dynamique contre design web adaptatif (2022)
Quand il s’agit d’adapter un site web au mobile (téléphones, tablettes), il existe aujourd’hui deux solutions techniques radicalement différentes. Aucune n’est vraiment supérieure à l’autre, chacune ayant son lot d’avantages et inconvénients. Seule la nature du projet web permet de faire le bon choix. Avec tout le buzz des dernières années autour du design adaptatif, la diffusion dynamique est aujourd’hui un peu oubliée des décisionnaires, mais conserve des atouts de poids dans certains contextes.
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.
Dynamic Serving vs. Responsive Web Design
When it comes to adapting Web sites to go mobile for smart phones or tablets, there are two radically different technical solutions. Neither one is inherently superior to the other; they both have advantages and disadvantages. The nature of your Web project should guide your choice. The buzz over the last years has been all about responsive design, leaving dynamic serving far behind; but this solution is a significant asset in some situations.
Responsive Web Design
In this solution, the Web server sends the same HTML and CSS files to all clients, regardless of whether the client is a desktop, tablet, or smartphone. Visual presentation is tailored to smaller screens by a special module, Media Queries, released with CSS3. The general principle is to override CSS declarations dedicated to the display on a large screen when the width of the screen is less than a certain number of pixels (threshold called “breakpoint”). Under the breakpoint, visual elements can be resized, modified or even hided if they are deemed unnecessary on smaller screens.
Dynamic Serving
In this situation, the server looks for the User Agent value in the HTTP header to determine whether it is dealing with a desktop, tablet, or smartphone. The server then sends out different HTML, CSS and JS code and media files (images, video, etc.) depending on the User Agent value. This means that mobile and desktop users receive different content from the same URL, unlike in the Responsive Web Design solution.
Advantages of Dynamic Serving
Superior Performance
Under Dynamic Serving, the mobile version of a Web site isn’t merely an adaptation of the full-fledged site, since the dynamic serving solution only sends out the necessary code and optimized media files. This way, the handheld device doesn’t receive megabytes of useless HTML-CSS code. Performance optimisation (as in weight and speed) becomes extremely easy and efficient. This is the biggest advantage of this solution, and it can be a sizeable one in some contexts, such as e-commerce, where reactivity is crucial to conversion.
Not Robbing Peter to Pay Paul
Responsive Web Design is an either-or solution: either you program for mobile devices then tailor to desktops, or you do the opposite. Whichever way you go, the second-place display type will be a compromise solution. When you look at a Web site designed for mobiles on a 5K screen, you immediately notice a step down in graphics and ergonomics. Conversely, so many Web sites are so poorly tailored for mobile devices that the desktop version would probably perform better! Dynamic Serving is a solution that does away with the need to compromise between versions.
Optimized Interaction
If your Web site is heavy on transactions and complex interactions, such as forms, you can design radically different user experiences depending on the platform. While this optimization isn’t relevant for content-based sites such as blogs or magazines, for on-line sales, it is a major draw. With Dynamic Serving, you can create a unique experience that will feel more like an application for your mobile users.
The Best of Both Worlds
Dynamic Serving and Responsive Web Design are not mutually exclusive. In fact, using media queries is recommended under Dynamic Serving in order to tailor visuals to the various sizes and orientations of mobile screens (phones, tablets).
Downsides
Cost
The more different the two versions are, the higher the maintenance costs will be. And if you’ve maxed out your optimization, you’ll basically have two different sites to maintain. Furthermore, the technical prerequisites are more cumbersome than in Responsive Web Design, which of course carries a cost of its own.
Failed Detection
User Agent detection is dependent on maintaining a dictionary of potential User Agents on the server. This list must always be up-to-date, under pain of non-detection of new agents. And since detection errors are always a possibility in any case, it’s a good idea to allow the user to switch to a different version than the one detected.
What About Google?
Google, the ultimate arbiter of taste, prefers Responsive Web Design. And looking down on us mortals from Mountain View, it has not felt the need to justify its preference, as is its wont. We are supposed to bow down and accept the pronouncement without question. But we dare hypothesize that Google fears cloaking techniques based on agent detection, and frauds are so much easier to detect on Responsive Web Design sites.
That said, will Google somehow penalize you for choosing this solution? The answer is no, as long as you observe one simple rule: use a valid “Vary” HTTP header to signal that you’re tailoring the content to the User Agent (Vary: User-Agent).
You don’t want Google on your back… so don’t forget:
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...)To reassure you, John Mueller vouched a few years ago for Google’s search-engine neutrality (at 13:05):
“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 then added that it’s really a question of usability rather than SEO.
The “Vary” HTTP header has another advantage: is stops the cache system of some ISPs from sending mobile users a pre-cached desktop version.
A Word on Separate URLs
One solution akin to Dynamic Serving is to perform detection but to serve the various platforms from separate URLs, for example “www.example.com” and “m.example.com”. This solution has little or no advantages, in my view, while presenting its share of challenges if it isn’t perfectly implemented. Say, for example, that your desktop has been sent a link from a mobile and you find yourself prisoner to the m.example.com version on your large screen. No problem, you’ll just manually correct the URL – until you discover, to your absolute frustration, that www.example.com keeps redirecting you to m.example.com due to a stupid cookie. I bet this has already happened to you.
If you do choose to use separate URLs, don’t forget to indicate the bidirectional relationship between the two with a “link” tag and the rel="canonical" and rel="alternate" annotations. This can be done in the header or in the sitemap. Don’t forget to issue a HTTP 302 code for redirecting. As long as you observe these rules, you should get along fine with Googlebot.
In any case, you should avoid client-side detection, since it involves some measure of latency, while the JavaScript code requires some time to load and execute.
What to Choose?
It all depends on your budget and your site. If you’re on a tight budget and your site is simple and light, requiring little interaction, then Responsive Web Design is the way to go. For anything else, you should consider Dynamic Serving.
But you should also think of the type of clients who use your site: if they are mostly mobile, you may want to go for Dynamic Serving, no matter what kind of site you have.