Approche côté serveur du responsive web

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, maitre 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é cross-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 maitrise 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 (plutôt moins) bien réussis.

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

  • le partage depuis un version wap ou mobi (email, facebook, …) s’affichant sur ordinateur
  • des années de SEO ruinées dût à des erreurs de Duplicate content
  • les tablettes redirigées vers un site wap ou mobi
  • Opera Wii et autres consoles affichant une interface tactile
  • WindowsPhone, WebOS ou Bada pas assez connu donc non redirigé vers wap/mobi.

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 10 nouveaux projets par jour de grille/flux/layout/responsive/adaptive/grille-pain/cloud tout en CSS et Javascript.

Pour s’adapter à la multiplicité toujours grandissante des périphériques mobile disponible 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, … 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 que les navigateurs aussi se trompent, mentent honteusement voire se plantent totalement.

Quelques exemples:

  • iOS6 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.
  • BlackberryOS 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, en 3gp…)
  • iOS ou Android prennent en compte mousemove sur écran tactile.
  • IE10 sous WindowsPhone gère SVG. Mais utilisé en background-image, il sont pixelisés à 72 dpi puis agrandi au DPI de l’écran. Le rendu est juste 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 de 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, saoul ou un peu simplet…

ç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é 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).

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.
  • iOS7 ne sait pas poser un text-shadow sur une webfont et la navigation bug avec le appcache.
  • 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.

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…).

Si votre version mobile-first par défaut est fait correctement, ce cas de figure n’impliquera que peu voire pas de casse. Par exemple, à la sortie de WindowsPhone 8, Facebook.com 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) APRES le chargement de la page, et un appel ajax communique le résultat des détections au serveur. Dès la second visite, un profil adapté est en place.

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 stats. 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 nouveaux 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 a personne d’autre.

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 travaillant ensemble pour afficher au mieux un document web.

Posted in Uncategorized

Leave a Reply

Your email address will not be published. Required fields are marked *