Approche côté serveur du responsive

Rémi Grumeau ~ 10 minutes

Commentaires (6)

Les erreurs du passé

Avant d’entrer dans le vif du sujet, il me semble important de se rappeler ce qu’est le web, l’essence même du web : un document mis à disposition publiquement par un ordinateur A affiché sur l’écran d’un autre ordinateur B lorsqu’il le demande. 45 ans plus tard, et bien que la minitelisation du web a changé l’ordinateur A en salle serveur d’OVH ou Amazon et que l’ordinateur B est maintenant un smartphone ou une tablette, au bout du compte, ça reste deux « ordinateurs » s’échangeant un document.

L’arrivée des langages dynamiques et des bases de données a focalisé tout l’attention de l’industrie sur l’ordinateur A, devenu un noeud central, maître incontesté du web. En résulte que la presque totalité des projets web et IT, et donc des développeurs, étaient orienté côté serveur : ASP, PHP, Perl, Java JSP, et plus tard SPIP, WordPress, Zend… Le tout en prenant un peu de haut les technologies côté client, jugeant notamment CSS ou JavaScript comme « des trucs d’artistes » servant juste faire clignoter un bouton et créant plus de nouveaux problèmes qu’autre chose (majoritairement le référencement pour AJAX, la compatibilité entre navigateurs pour CSS).

Evidemment, à chaque nouvelle problématique, c’est côté serveur que l’on cherche la solution, vu que c’est ce que l’on maîtrise le mieux. Et à l’arrivée des smartphones, la première réaction a été, de gérer ça côté serveur. Redirection vers les versions WAP existantes ou mise en place de .mobi, plus ou moins bien réussis (plutôt moins).

Le résultat n’était pas très probant (liste non exhaustives):

  • Le partage depuis une version WAP ou .mobi (par e‑mail, sur Facebook, …) s’affichant sur ordinateur – des années de SEO ruinées dû à des erreurs de contenu dupliqué
  • Les tablettes redirigées vers un site wap ou mobi
  • Opera Wii et autres consoles affichant une interface tactile
  • Windows Phone, WebOS ou Bada pas assez connu donc non redirigé vers WAP/mobi

Nos erreurs du passé

Globalement, c’était donc plutôt raté. Mais si on y arrive pas côté serveur, faisons-le côté client !

Le côté client de la force

Depuis quelques années, la « mode » est maintenant au 100% côté client. Peu ou presque plus rien de neuf côté serveur (a part Node.JS), mais dix nouveaux projets par jour de grille/flux/layout/responsive/adaptive/grille-pain/cloud tout en CSS et JavaScript.

Pour s’adapter à la diversité toujours grandissante des périphériques mobile disponibles sur le marché, on décide de demander au navigateur ce qu’il sait faire, et on tri par fonctionnalité plutôt que par navigateur : tactile, grand ou petit écran, HTML5, … En charge au site, une fois chargé et fort de ces informations, d’indiquer au navigateur les scripts, CSS et images adaptés pour lui. On parle d’amélioration progressive, module par module.

La solution semble simple, idéale et sans faille possible. Il y a cependant plusieurs problèmes majeurs, notamment le fait que les navigateurs aussi se trompent, mentent honteusement, voire se plantent totalement.

Quelques exemples :

  • iOS 6 indique gérer la localisation, mais en mode webapp, il ne retournera jamais de position. Ni d’erreur. Le test dit oui, mais dans les faits, c’est non.
  • Blackberry OS 6 & 7 indique gérer la balise HTML5 vidéo. Et c’est vrai. En revanche, il n’y a aucun codec vidéo. Et donc en vrai, pas de vidéo (enfin si, seulement au format 3GP).
  • iOS ou Android prennent en compte mousemove sur écran tactile.
  • IE10 sous Windows Phone gère SVG. Mais utilisé en background-image, il sont pixelisésà 72 dpi puis agrandi au DPI de l’écran. Le rendu est alors ignoble.

Second problème, et de taille, c’est la charge de ces tests. Entre les scripts de détection eux mêmes, les chargements supplémentaires résultant de ces tests, la charge de leur exécution et le ré-affichage à plusieurs reprises de la page nécessaire… c’est le temps de chargement initial et la réactivité des premières secondes du site qui en pâtit.

Dernier problème, c’est en fait la logique elle même. Le site web, en voulant bien faire, passe ses journées à poser toujours les mêmes questions aux mêmes navigateurs, aux mêmes mobiles, a chaque chargement de page, depuis des mois et des mois. Que penseriez-vous d’une personne qui a chaque début de discussion vous redemande votre espèce, civilité, prénom et si vous savez marcher ? Probablement qu’il est malade, amnésique, ou un peu saoul.

Phénomène de « client-side amnesia »
Phénomène de « client-side amnesia »

Ça semble stupide à dire, mais le script le plus rapide et le moins couteux, c’est celui que l’on ne lance pas, l’image la plus légère celle que l’on ne charge pas. Et surtout sur mobile où la latence est forte et le débit instable, la requête la plus rapide est celle que l’on ne fait pas. En clair, moins le navigateur doit attendre et moins il doit en faire, mieux il se porte !

Retrouver la mémoire

La détection côté client reste un must pour ce qui a vocation à changer ou être activé / désactivé : géolocalisation, orientation, débit, cookies, JavaScript…

En revanche :

  • Une souris ne sortira pas des fesses de votre iPad pendant la nuit.
  • Un iPhone ou un Note2 ne changera pas de taille d’écran, ni de DPI (Retina)
  • iOS ne gère pas Flash ni WebM.
  • Android 4.x gère le WebP.
  • Blackberry 6 & 7 ne sera jamais une tablette.
  • Peu de chance qu’une Xbox soit utilisée sur un écran tactile.

Il n’y a donc absolument aucun intérêt de continuellement leur poser la question. On le demande une fois, on stocke l’information, et on la réutilise. Cela permet, en prenant le cas concret des images, d’envoyer directement la bonne image au bon format et à une définition adaptée, sans avoir à afficher un visuel en basse qualité, tester le navigateur puis charger une seconde image en meilleure qualité (comme le prône le mobile-first).

Optimisation pour écran retina
Un écran « Rétina » affiche plus proprement un JPEG qualité 40 si 2x plus grand qu’un JPEG qualité 70

Au delà des informations détectées et enregistrées, il y aussi ce qu’un navigateur ne vous dira jamais mais que vous savez par expérience :

  • Un Galaxy Ace ou un Blackberry Curve, c’est lent et ça rame. On oublie les transitions.
  • Un champ texte sélectionné sur la navigateur Android masque / passe au dessus de tout le reste.
  • La géolocalisation sur WindowsPhone est très (trop) lente.
  • iOS 7 ne sait pas poser un text-shadow sur une webfont et la navigation bug avec le cache d’application.
  • 96 % des gens cliquent sur la première image d’un carrousel : dégagez-le ! (ok, ça a peu de rapport avec le reste, mais pitié, dégagez-le quand même…)

Sans compter les cas ou la détection n’est pas possible (emails, image & vidéo, bannières, …). Il n’y a aucune raison de ne pas envoyer une image optimisé rétina au client mail de l’iPhone, et cela sans pour autant la superposer à une image « normale » via CSS / responsive.

Pas de détection côté client possible dans un email responsive
Pas de détection côté client possible dans un e‑mail responsive

Dans la pratique

Dans un premier lieu, il est important de lister les informations dont vous avez besoin.

Si votre site ou projet est très simple, voué à disparaitre rapidement (aka site événementiel / promotionnel, jeu concours, …), un simple script taillant dans le gros fera le café pour 90 % de vos visiteurs. A l’inverse du mobile-first, cherchez ici à détecter les navigateurs de bureau en premier, puis les principales tablettes du marché. Et traitez tout le reste comme des mobiles (mobile-first).

Veillez cependant à toujours garder un oeil sur vos stats utilisateurs et bien vérifier que si une nouvelle tablette ou navigateur de bureau explose en popularité, il est important qu’il ne soit pas géré comme un mobile (Petit rappel : cela a pris 2 ans à Chrome pour dépasser les 10 % de parts de marché. Vous devriez les voir venir…).

Statistiques

Si votre version mobile first par défaut est faite correctement, ce cas de figure n’impliquera que peu voire pas de casse. Par exemple, à la sortie de Windows Phone 8, Facebook affichait la version mobile/wap. Pas très sexy certes, mais accessible et rapide. 2 mois plus tard, la version smartphone (similaire à iOS) a été activée, prenant en compte les spécificités d’IE10 mobile (Pointer Events, hack du viewport, …).

Pour ceux qui ont envie d’aller plus loin, si votre service est plus spécifique, une plateforme vouée à évoluer dans le temps ou à être réutilisée à plusieurs reprises, des profils complets et détaillés côté-serveur permettent d’affiner chaque page, script ou media au navigateur ou périphérique qui le demande. On parle alors de profilage côté-serveur (ou « server-side profiling »).

La mécanique est simple : à la première visite, un profil par défaut est généré selon les données connues pour l’agent utilisateur du visiteur. Si inconnu, un profil par défaut (mobile first) est utilisé. Si connu ou reconnu, le profil correspondant est utilisé (un cookie permet de garder trace de l’id unique de ce profil).

Selon ces données, tout est pré-mâché avant téléchargement : scripts et feuilles de styles groupés, images et vidéos optimisées et au format optimal, balises HTML adaptées. Si le navigateur n’est pas connu, on ajoute des scripts de détection côté client (Modernizr ou autres) après le chargement de la page, et un appel AJAX communique le résultat des détections au serveur. Dès la seconde visite, un profil adapté est en place.

Process

Il est alors important que les données de profil soient propres et dans la mesure du possible vérifiées. Là encore, faites vos devoirs et regardez vos statistiques. Identifiez les principaux navigateurs et périphériques et tentez de les tester pas vous-même : mettez à contribution les mobiles et tablettes de vos amis ou utilisateurs ainsi que les émulateurs. Rien de bien nouveau ici, si vous ne le faites pas déjà, je ne peux que vous y encourager vivement !

Une autre option trop souvent ignorée est celle de simplement sortir de chez soi et aller dans les boutiques opérateurs. Elles sont remplies de mobiles prêts à être testés.

Des composants responsive côté serveur

En tant que développeur, chaque module d’une page a un but : afficher une image, une vidéo, un bloc de texte, lister les liens d’un menu, … Un composant par but souhaité, le profil serveur s’occupe de le générer au mieux, et le client de l’afficher de la meilleure façon possible.

Rapidement, la création de composants responsive côté serveur s’imposera comme le saint graal pour créer vos documents et applications :

  • Pas besoin des CSS de fallback PNG quand les dégradés CSS sont pris en compte.
  • Pas besoin de multiples sources vidéos (webm, ogg, mp4 + media queries) ni fallback si l’on sait quel codec fonctionne.
  • Aucune raison de générer des balises HTML5 sur IE8, et donc de charger HTML5shiv – les meta destinés aux bots (SEO) ne servent à personne d’autre.

Composants côté serveur

Regardez simplement comment Google génère ses WebFonts … oui madame, un joli composant responsive côté-serveur.

Retour au fondement du web : le serveur et le client travaillent ensemble pour afficher au mieux un document web.

6 commentaires sur cet article

  1. Kenny, le lundi 23 décembre 2013 à 09:46

    Joli article, mais ca va à l’encontre de l’utilisation de proxy cache à la Varnish pour des sites à haute charge, où l’on va faire le maximum pour ne gérer qu’un cache par page (et pas un par type de terminal supporté, sans compter l’overhead sur l’UA sniffing et/ou detection du cookie).

    Et j’ai aussi toujours autant de mal (peut être à tord ?) avec le UA sniffing …

    Quelqu’un a des retours d’XP sur une utilisation RESS avec du Varnish devant ?

    Merci pour ce partage en tout cas ;)

  2. Thomas Blumenfeld, le lundi 23 décembre 2013 à 11:35

    C’est marrant, la toute dernière version de Ruby on Rails (4.1) apporte justement un moyen de gérer le responsive côté serveur avec les ActionPack Variants : http://coherence.io/blog/2013/12/17/whats-new-in-rails‑4–1.html

    Le but est sur une appli MVC de gérer le V différemment en fonction du type de device client. Donc contenu + CSS + JS + images.

    L’apport de cette technique n’est pas uniquement la performance mais aussi l’ergonomie d’affichage qui peut différer entre smartphone, tablette et ordi. Dans ce cas le C de MVC peut aussi éventuellement varier.

  3. Marie, le lundi 23 décembre 2013 à 13:42

    Merci pour cet article ! Ton constat sur les limites de la détection côté front est super (j’ai appris pleins de choses).

    Toutefois, je reste un peu sur ma faim : au vu du titre, « Approche côté serveur du responsive », je m’attendais à ce que le chapitre « Des composants responsive côté serveur » ne soit pas qu’un chapitre, mais le gros de ton article.

    Par exemple, pour moi qui ne suis pas dev, j’aurais trouvé intéressant que tu détailles ce que contiennent tes fonctions PHP htmlTag() ou htmlTagHead() par exemple, pour pouvoir jouer avec sur mes projets perso.

    Et, globalement, j’aurais été intéressée par davantage d’exemples concrets de cette détection côté serveur.

    Peut-être dans un prochain article ? :)

  4. Nicolas Steinmetz, le mardi 24 décembre 2013 à 11:46

    Est-ce que cette génération de profil ne revient pas à refaire peu ou prou du UA agent sniffing (certes peut être amélioré ?)

    Si je trouve l’idée de la génération de « profils » intéressant en me disant que je ne teste qu’une fois le device et ensuite je lui rend un profil donné. Si cela permet certes une approche optimisée, est-ce que cela ne crée par une tripotée de profils à créer (certes limité coté iOs pour le moment, mais pour le reste, c’est plutôt fragmenté & diversifié) et surtout à maintenir avec un cout associé non négligeable ?

    Merci en tous cas pour la réflexion.

  5. adrien, le mardi 7 janvier 2014 à 11:18

    bizarre tout l’article est illisible.
    c’est contraignant ces fautes de caractères… sous FireFox

  6. TOMHTML, le samedi 11 janvier 2014 à 22:43

    Il n’y a pas pire expression que « responsive côté serveur ». Je croise les doigts pour ne plus la croiser en 2014.