Le web mobile et la performance

Tout site sortant aujourd’hui doit avoir été pensé avec des contraintes mobiles, et utiliser des techniques d’amélioration progressive pour délivrer rapidement les fonctionnalités sur toutes plateformes.

En attendant cette conclusion, nous commencerons par essayer de connaître notre utilisateur, puis nous verrons les tactiques et stratégies propres au mobile.

Où est le problème ?

La 4G a débarqué, des mobiles à 8 processeurs se vendent, et la plupart des gens utilisent leur mobile depuis chez eux : en Wifi ! À priori le métier de spécialiste performance web serait donc mort et vous me trouverez en train de parler HTML5 à mes chèvres dans le Larzac, merci au revoir. À moins que…

L’utilisation

La « situation de mobilité » est-elle un mythe ? L’expérience et une étude Google montrent clairement que les ¾ des gens utilisent majoritairement leur mobile depuis le confort de leur canapé / lit / lunette, derrière le wifi familial. 15% de ces mêmes Français ont même la fibre.

Le temps passé dans une situation confortable est majoritaire mais cela est justement dû à la réalité de la situation de mobilité : cela doit être très rapide. Dans un magasin, les gens vérifient les prix des concurrents sur le Web : si votre page ne s’affiche pas en plus de quelques secondes, vous avez perdu la guerre des prix dès la première bataille (afficher le prix) ! Dans la rue, l’utilisateur va vouloir connaître les horaires de cinéma ou les restaurants du coin : si c’est votre coeur de métier vous n’aurez toutes vos chances qu’en affichant rapidement l’information demandée. Dans les situations d’attente, les gens dégainent les téléphones pour consulter réseaux sociaux et mails : si votre page a la chance d’être dans leur fil d’information, il va falloir afficher la promesse très rapidement (un article sur les félins à travers les âges, une vidéo de chats, le lolcat du jour…). Enfin la préparation d’achat se fait fréquemment sur mobile (plus discret dans l’open space, à portée de main lors des pauses clope voire au feu rouge), même si la finalisation de la commande se fait encore majoritairement sur l’ordinateur du foyer voire sur tablette.

Tout cela ne compte que pour quelques secondes dans les statistiques mais les utilisateurs se souviendront de votre marque de manière très positive si vous avez résolu leur problème rapidement.

La connexion

Les données de cette année montrent clairement une amélioration des débits 3G (6 Mb/s en moyenne selon Akamai) et la 4G à la française envoie du poney au galop (21−32 Mb/s constatés selon Degrouptest, pointes de 34 Mb/s selon Akamai).

Mais si vous êtes utilisateur régulier du mobile, vous devinez la vérité derrière ces excellentes moyennes : même avec une puce et un abonnement 4G vous ne chargez parfois pas du tout les pages et vous esquissez un sourire triomphant lorsqu’un site web se charge aussi bien qu’au bureau. C’est parce que l’ennemi numéro 1 du chargement de page web reste la latence réseau, et même sur une 4G de bonne qualité les latences constatés par Degrouptest sont entre 50 et 100 ms.

Concrètement :

• ligne du haut : une 4G de cadre parisien avec 20 Mb/s de débit mais 200 ms de latence (les murs de Paris sont épais),
• ligne du bas : l’ADSL de la mamie du Cantal avec 2 Mb/s et 20 ms de latence (oui son DSLAM est proche).

L’affichage via la connexion à 2 Mb/s commence 1 seconde plus tôt, le formulaire est utilisable 2 secondes plus tôt et le site au complet se charge 5 secondes plus vite.

Ajoutez à cela que les réseaux 3G des grandes villes sont saturées, et qu’en fonction de l’endroit, de l’heure de la journée, du jour de la semaine et de la position de votre doigt sur le mobile, les performances ne sont pas du tout les mêmes. Dans certains cas pas un octet ne passe.

Tout ça pour dire que les grands principes de la limitation du nombre de requêtes d’abord, puis du poids du contenu restent valables.

L’utilisateur

Tout le monde n’investit pas dans un bidule avec 8 processeurs et 3 Go de RAM, par contre les utilisateurs mobiles sont clairement habitués à ce que les interfaces soient fluides et réactives, et même à ce qu’on leur affiche des données en l’absence de réseau. Ajoutez à cela le fait que l’on sert fréquemment des sites mobiles minimalistes et vous comprendrez que l’utilisateur a bien du mal à accepter que les sites qu’il consulte mettent du temps à apparaître, ou laggent lorsqu’il scrolle.

Du coup un tombereau d’études utilisateur ou d’analyse statistiques démontrent ce que l’on pressent déjà : le temps coûte cher.

Absolument tous les indicateurs marketing sont touchés :

• le taux de rebond (Etsy : ajouter 160Ko d’images = +12% de taux de rebond),
• le taux de clic (DoubleClick : supprimer 1 redirection = +12% de taux de clic),
• l’abandon pur et simple de la page (Radware : 60% d’abandon après 4 secondes de page blanche),
• l’abandon du processus d’achat (Wallmart : ‑50% de conversion par seconde),
• l’abandon du visionnage (Akamai : ‑6% de vidéo vue par seconde d’attente),
• la perception négative de la marque.

Le côté amusant de l’histoire : si vous surveillez vos taux de rebond sur mobile en vous disant « ça va encore, » dites-vous que les statistiques sont en dessous de la réalité puisque dans les cas des pages blanches, il est probable que la requête remontant sur le serveur qui comptabilise les hits ne soit jamais partie.

Nos sites !

Étant donné que les grands chefs regardent les sites sur des mobiles qui valent le prix de ma première voiture, via le wifi de la boite et qu’ils s’arrêtent à la homepage, forcément il y a un peu de laisser-aller sur les sites, y compris dédiés mobile. Le poids des sites dits dédiés mobile (mDot) augmente régulièrement. La bonne idée d’avoir un site mobile dépouillé et ergonomiquement efficace s’efface pour laisser la place aux mauvaises habitudes des sites desktop : on met tout sur la HomePage, et on rajoute un maximum d’information sur les pages intérieures.

Le RWD devient la norme pour les refontes graphiques, mais rarement le « mobile first » : on se retrouve donc avec des spécifications planifiant 5 breakpoints, devant afficher des images « retina » tout en gérant IE 6 (oui cette spécification existe vraiment). Le poids des sites en général a doublé en 3 ans et grâce au RWD on demande maintenant d’afficher des sites de 2 Mo et 100 requêtes sur mobile. Ça finirait par arriver si l’utilisateur était encore là pour le voir.

Sur ces même sites cross-device, votre département marketing a bien sûr opté pour la totale :

• de l’analytics (augmentation du nombre de requêtes),
• des publicités (poids, temps d’exécution, requêtes),
• de l’A/B Testing (retardement volontaire de l’affichage, temps d’exécution),
• des boutons sociaux (le moindre bouton G+ rajoute 100 Ko et des dizaines de requêtes)

Et les tendances webdesign du moment ne sont plus aux coins arrondis qu’on aurait pu régler en CSS3 en pouffant, mais aux polices de caractère (blocage temporaire du rendu, texte invisible, poids), aux « hero images » (l’image principale en 1200×800, retina-ready, cordialement) ou pire aux slideshows (pourtant une mauvaise idée) qui peuvent charger de grosses images invisibles.

L’arsenal technique

Le problème est donc bien réel et s’inscrit dans la durée : les utilisateurs seront de plus en plus exigeants, les sites de plus en plus gourmands, et la latence des réseaux mobiles ne fera pas de grands progrès. Ce qui tombe bien c’est qu’on peut y faire quelque chose.

Le chemin critique

D’accord le chemin critique est connu depuis 2006, désolé de redire les choses mais sur mobile il ne faut surtout pas se rater sur les bases. Prenons un cas un peu extrême (iOS < 8, grosse latence, débit correct).

Pourquoi 9 secondes avant le premier pixel, et 10 avant de voir quelque chose d’utile ? Regardons l’action au ralenti, avec la trace réseau suivante.

Vous pouvez considérer que tout ce qui est à gauche de la ligne verticale verte (l’affichage du premier pixel) est sur le chemin critique. Un effort d’optimisation est déjà en place car les CSS sont déjà groupés et les JavaScript sont chargés de manière asynchrone. Sauf que c’est à cause de cette dernière optimisation que le site est ralenti : ce qui marche sur navigateur de bureau n’est pas forcément vrai sur mobile.

Déplacer les JavaScript en bas de page aurait aussi été une mauvaise idée, grâce à notre ami Safari iOS qui refuse d’afficher quoi que ce soit tant que ces fichiers ne sont pas là. Ici comme sur la plupart des sites, on gagnerait plusieurs secondes en chargeant de manière classique les fichiers JS agglomérés, en haut de page.

Pour résumer :

• testez sur les vraies plate-formes avant d’appliquer des recettes qui marchent ailleurs.
• choisissez la bonne stratégie de chargement des JS : de manière classique en haut de page, ça marche souvent très bien
• les recettes classiques doivent être appliquées : groupement en 6 requêtes maximum des HTML / CSS / JS
• minification et gzip des ressources de type texte

La police

Les fonts sont la grosse tendance 2013 et sont maintenant présentes sur la moitié des sites. C’est joli tout plein mais ça retarde encore le moment où l’utilisateur peut accéder au contenu. En fait il y a 3 états possibles pour l’affichage de votre texte.

Phase 1 : pas de bras, pas de chocolat, le texte est là mais masqué. Un peu dommage pour un site essentiellement basé sur le contenu textuel.

Phase 2 : le navigateur en a marre et vous sauve la mise en affichant le texte. Mal stylé mais fonctionnel.

Phase 3 : tout va bien, le site est quasiment comme sur la maquette. On espère que l’utilisateur regarde encore.

Savoir coder

L’art ancestral de l’amélioration progressive doit aussi s’appliquer aux polices : la phase 2 n’existe que si vous avez bien pensé à préciser une police système de fallback. Dans le cas contraire l’utilisateur regardera plus longtemps le site sans rien pouvoir y lire.

Pour raccourcir voire éliminer la phase sans tete lisible, il s’agit de faire un travail approfondi de coopération intégrateur / designer : 1 ou 2 polices maximum, de moins de 40Ko, testées sur toutes les plate-formes (mention spéciale à Chrome sur XP)

Ensuite vient le travail d’optimisation :

• la font critique doit avoir sa place dans vos 6 premières requêtes.
• chargement asynchrone des polices secondaires (variantes, titres invisibles, police d’icônes…).

Il y a des techniques plus avancées permettant de toujours afficher du texte même si ça n’est pas la font finale, ce qui ne plaît pas toujours. Vous pouvez également utiliser les data:uri et un encodage base64 de votre police directement dans le CSS, mais vous l’alourdissez du poids de la police.

Testez.

Se méfier des autres

Je vois encore des développeurs inclure des scripts depuis des serveurs qui ne leur appartiennent pas. Il s’agit le plus souvent d’une version plus ou moins à jour de jQuery ou de HTML5 shim. Les bénéfices sont nuls, et le risque énorme. Vous pensiez sérieusement que les serveurs des grands de ce monde sont disponibles 100% du temps ? Ou qu’ils répondent toujours plus vite que vos propres serveurs ?

Non.

Sur ces graphes, on voit les temps d’affichage de sites majeurs (ligne du haut) augmenter de 20 secondes pendant le temps où les serveurs Facebook sont moins disponibles. Pour faire le point des dangers page par page, je vous conseille d’utiliser SPOF-O-Matic.

Sur mobile la résolution du nouveau nom de domaine est particulièrement pénible à cause de la latence. Les stratégies sont relativement simples, en fonction de la nature de la ressource :

• widget / bouton : utiliser la version asynchrone pour ne pas dépendre des autres,
• widget / bouton : mieux, une version statique vous évite 100–200Ko et des temps d’exécution énormes,
• JavaScript ou CSS tiers : rapatriez le script bien au chaud chez vous, groupez-le avec les autres si il est critique
• polices : rapatriement sur vos serveurs, quitte à payer une licence

Publicités, trackers et autres A/B testing

Ils requièrent tous d’être en haut de page pour être exécutés en premier et sont massivement déployés sur les sites même dédiés mobiles. Le département marketing moderne se doit de posséder au moins un exemplaire de chaque catégorie.

Les solutions techniques non bloquantes sont à négocier d’abord en interne pour faire prendre conscience du problème, puis auprès des fournisseurs, de moins en moins réfractaires. On arrive fréquemment à mettre les publicités dans des iframes et les scripts de tracking en asynchrone. Pour l’A/B testing ou certaines zones de publicité vitales, une bonne option, techniquement complexe, consiste à rapatrier en local, de préférence de manière automatisée, le code JS du prestataire, puis à l’inclure comme le reste des JS critiques en haut de page.

Les 3 caches

C’est comme les 3 coquillages : on peut faire sans, mais les gens du futur se moqueront. Partant du principe qu’il n’y a pas plus rapide qu’une requête qu’on ne fait pas, il convient de maîtriser rapidement les 3 techniques suivantes sur mobile.

Le cache HTTP

Depuis toujours la recette est simple :

• mettre des temps de cache très longs sur toutes les ressources statiques (plus d’1 mois),
• en cas de mise en production d’une nouvelle version, la mise à jour des caches clients se fait par le changement des URLs pointant sur les statiques.

Point.

Sur navigateurs de bureau, on pourrait s’arrêter là mais sur mobile le cache HTTP peut se révéler très volatile, voire capricieux. Si l’OS estime qu’il a besoin de mémoire, il peut vider le cache du navigateur. C’est la raison pour laquelle certains sites ont développé leur propre système de mise en cache, en se basant sur localStorage.

DOM Storage

localStorage est un système simplissime de stockage de clé / valeur, de 5Mo minimum. Pour limiter les accès au serveur, stockez‑y des informations aussi simples qu’un historique de navigation ou lourdes et complexes, comme une liste de toutes les marques automobile et des modèles. L’utilisation en est tellement facile que c’en est ennuyeux.

Du coup certains en abusent.

Certains sites stockent carrément du HTML, du CSS, du JavaScript, des images ou des fonts puis via un système classique de gestion de session évitent de renvoyer les ressources au client.

Application Cache (dit offline)

L’énorme avantage ergonomique d’une application native installée chez l’utilisateur, c’est qu’elle va s’ouvrir quand vous appuyez dessus, même si à ce moment-là vous transitez par le tunnel sous la manche. Imaginez que l’on puisse faire de même avec nos sites : il suffirait d’aller une seule fois sur une des pages pour rapatrier l’ensemble de l’interface, et toute la navigation se ferait en local. Les mises à jour du contenu ne se feraient que lorsque la connexion est rétablie et on ne dépendrait pas de la validation d’un store pour mettre à jour son application.

Figurez-vous que la technologie existe, et date même d’une époque lointaine où Apple ne pensait pas encore à l’app store et à Objective C pour écrire des applications mais bien au Web et ses langages . Faites-moi plaisir et enfourchez votre mobile pour aller sur l’URL suivante :

http://appcache.offline.technology/demo/

Une fois la page chargée complètement (scrollez en bas pour voir les logs), passez offline (mode avion), puis allez sur la 2^de page nommée cache. Non seulement la page s’affiche comme si de rien n’était mais l’image du machin vert est également présente alors qu’elle ne peut pas être dans le cache HTTP classique.

Si vous utilisez Chrome, vous pouvez regarder sur chrome://appcache-internals/ votre liste des sites utilisant cette technologie.

À ce stade de la compétition vous avez peut être déjà entendu dire beaucoup de mal sur appCache. C’est effectivement le genre d’API qui demande du temps et de l’amour pour être bien comprise, mais elle apporte un énorme confort utilisateur et est très bien supportée sur mobile et même sur bureau. Elle est très adapté aux sites qui se comportent comme des applications (une seule page) mais il existe des techniques à base d’iframe pour partager ce super cache entre plusieurs pages d’un site plus classique.

Les images

Elles représentent fréquemment les deux tiers du poids des sites et ralentissent le chargement des ressources critiques.

Éviter de les charger

Captain Obvious a dit : c’est plus rapide sans image. C’est pas faux et il commence à y avoir pas mal de techniques permettant d’éviter des requêtes :

• CSS3 pour les dégradés, arrondis, rotations et opacités. Dommage que ça ne soit plus à la mode.
• Les caractères unicodes des polices fournies avec les OS : ►★✓⇢ ✎♥☎ ♻⚠☻☺⇨ (attention si vous visez également IE8 sur Windows XP)

Lorsque certaines images sont critiques pour votre interface, vous pouvez les embarquer directement dans le HTML ou le CSS. C’est la technique du data:uri couplé à l’encodage en base64. Oui ça a l’air sale mais uniquement si c’est mal fait.

L’image la plus importante à charger est celle indiquant justement qu’il y a chargement ! Pourquoi ne pas mettre également le logo ou une image de contenu réellement importante.

Il ne faut pas abuser de la technique car elle alourdit le HTML et le CSS qui sont des ressource critiques, mais sur quelques petites images stratégiques cela fait patienter l’utilisateur.

Chargement à la demande

C’est à se demander pourquoi les navigateurs ne le font pas déjà d’eux-mêmes : l’idée est bêtement de ne pas charger les images qui ne sont pas visibles ! C’est radical pour les sites avec beaucoup d’images car cela libère la bande passante pour les ressources critiques et les images qui sont visibles. Voici un bon exemple de librairie, utilisé notamment sur lequipe.fr, bureau ou mobile. Naviguez dessus (c’est pour le travail) et scrollez très vite : vous verrez les images apparaître au fur et à mesure de votre progression dans la page.

Cette technique seule sauve des dauphins tous les jours.

Les images responsive

Comment servir le meilleur rapport poids / qualité à l’utilisateur mobile ?

Le standard

Votre plus grand problème concernant les images à délivrer sur mobile est de comprendre ce que vous voulez réellement en faire. Le problème est de définir le problème si vous voulez, en répondant à ces 4 questions :

• adaptation à la taille du viewport : veut on servir des petites images aux petits écrans ?
• écran haute densité de pixels (ok, retina©) : veut-on leur servir des images de très haute qualité ?
• art direction : pourquoi ne pas afficher des images au cadrage différent en fonction de la taille de l’écran ?
• format de l’image : veut-on servir du WebP à Chrome, du JPG XR à windows et du JPG 2000 à iOS ?

Pour compliquer l’affaire, sachez que :

• un écran retina peut avoir un petit viewport,
• deviner la bande passante de l’utilisateur est hautement hasardeux,
• vous ne connaissez pas la seule valeur qui compte : la taille physique de l’écran et la distance écran-œil.

Si vous êtes capable d’écrire un cahier des charges répondant à ces questions, alors vous pouvez vous pencher sur la réponse officielle et standard au problème : <picture>. Le temps que ça marche partout, la librairie JS officielle est picturefill 2.0.

La peinture étant un peu fraîche, il n’y a pour l’instant pas de retour sur la mise en production de cette technique. L’amélioration de performances devra donc se tester chez vous, en particulier sur les plateformes sans support.

Fait à la main, roulé sous les aisselles

Difficile pour une solution générique de faire mieux que du code écrit spécifiquement. À force j’utilise généralement chez mes clients un petit ensemble de techniques :

• JPG grande résolution, qualité 0 : pour une image unique à faire passer sur tous type d’écran, éditée à la main. Ça passe pour 90% des JPG. (à essayer sur un écran haute densité),
• images basse définition pour remplir l’espace, suivies du chargement de la haute définition. Le JPG progressif marchant mal sur iOS, c’est une manière d’avoir le même effet,
• lazy-loading pour la majorité des images, images embarquées pour les critiques,
• quand on peut, des formats vectoriels : SVG et polices d’icônes.

Combinez, testez et saupoudrez de JS pour obtenir de beaux effets. La maintenance n’est pas facile mais les résultats sont bons.

Interfaces fluides

Vous avez remarqué que les smartphones sont capables de jouer de manière fluide des jeux 3D mais ont des difficultés dès qu’il s’agit de retailler des divs ou de jouer avec du texte ? Au contraire de la 3D, il n’existe pas de puce dédiée à recalculer un DOM qui bouge ou l’écoulement des caractères. Il va donc falloir aider un peu nos pages.

Animations

Elles peuvent être fluides si on les travaille au corps. D’abord il y a un certain nombre de propriétés CSS qu’il vaut mieux ne pas animer comme top, left, width et height. On leur préférera les variations de transforms comme translateX() ou scale() qui ont la bonne idée d’être pris en charge directement au niveau du processeur graphique.

Vous pouvez essayer dans l’ordre :

• les transitions CSS, qui suffisent à la plupart des sites,
• les animations CSS, quipermettent des effets plus avancés
• enfin si JS doit tout piloter (un jeu par exemple), utilisez requestAnimationFrame, arrêtez jQuery animate et préférez des librairies spécialisées comme D3.js, GSAP ou TweenJS qui génèrent du CSS3.

CSS 3 avec modération

Remplacer les images de décoration par CSS c’était une bonne idée jusqu’à ce que vous réalisiez que le scroll lag sérieusement depuis que vous avez rajouté une ombre portée sur toute la hauteur de votre liste. De fait, tous les effets d’ombre, de transparence et de coins arrondis sont calculés en continu et cela peut coûter cher.

Une seule règle : tester, et sur de vrais mobiles bien sûr.

Calculs

On ne calcule pas tous les jours une suite de Fibonacci mais si ça vous arrive, utilisez les Web Workers. Sur les mobiles modernes ça vous donne accès à un second processeur pour exécuter du JavaScript. Sur les autres, la bonne veille technique du setTimeout(0) reste valable pour exécuter des boucles lourdes sans bloquer l’interface. Devinez qui vous a écrit un script pour ça ?

Testez !

Les derniers navigateurs mobiles acceptent enfin le déboguage à distance ! Cela signifie que vous allez pouvoir utiliser le profiler que vous connaissez sur de vrais téléphones et débusquer les endroits qui font ramer votre interface.

Pour les anciens OS comme Android 2.3, cela reste la devinette, rassurez vous.

Impliquer, mesurer, surveiller

On ne peut pas résoudre le problème qu’on ne voit pas. Avant de commencer tout projet de performance, il faut définir ce que doit être la performance, prendre un point de départ, choisir ses métriques, et surveiller automatiquement les performances dans le temps.

Sinon le projet performance s’arrêtera après la mise en prod des premières améliorations de performance.

Il fut un temps où il était possible d’avoir une équipe Web composée d’une seule personne : référencement, accessibilité, code, design, administration système, c’était fun. Mais aujourd’hui, à toutes vos compétences techniques il faut maintenant rajouter une grosse capacité à comprendre pourquoi l’on code et comment dialoguer avec le reste de la boite.

Donc par pitié, ne partez pas en croisade solitaire contre les lenteurs de votre site, au risque que personne dans la boîte ne s’en aperçoive. Il faut d’abord sensibiliser et évangéliser sur le coût du manque de performance pour la société et l’image du produit. Toute l’introduction de cet article est là pour cela.

Une fois que vous avez l’oreille des décideurs, faites écrire dans ce qui se rapproche le plus d’une spécification les objectifs de performance : en dessous de quels temps considère-t-on qu’il faut agir ? Vous pouvez par exemple prendre ces chiffres, relativement universels sans être trop ambitieux :

1. Pour 80% des utilisateurs
2. Premier rendu en moins de 2 secondes
3. Fonctionnalité principale en moins de 5 secondes
4. Navigation de page en page en moins de 2 secondes

Les utilisateurs et le premier rendu

Les deux premiers points demandent à déterminer l’équipement des utilisateurs :

• Quels navigateurs ?
• Quelle est la puissance des mobiles ?
• Quelle est la qualité de leur connexion ? (l’origine géographique peut suffire à la deviner)

Les seuls moments où on vous a dit que le site était lent, c’est lorsque vos collaborateurs ont essayé de l’utiliser sans le Wifi du bureau. Comme des vrais gens donc. Il faut reproduire ces conditions de manière systématique et certaine pour constater les dégâts et juger des progrès avec le temps.

Le temps de premier rendu est relativement facile à vérifier avec des outils comme WebPagetest.org. Ce qui est plus compliqué c’est de paramétrer WebPagetest avec une simulation de connexion qui soit réaliste par rapport à vos utilisateurs. Comme ce n’est pas le cas de Webpagetest.org par défaut, je vous donne mes paramètres beaucoup plus représentatifs de la France.

WebPagetest s’installe également en interne, et peut piloter des mobiles.

La fonctionnalité principale

Là ça se complique : comment déterminer le temps d’accès à la fonctionnalité principale ? Aucun outil ne peut faire cela automatiquement pour vous car seul vous connaissez bien votre interface (prends ça Skynet). Par contre vous pouvez collecter automatiquement des temps en JavaScript et vous les envoyer dans l’outil de tracking qui vous sied (G. Analytics peut suffire au début).

Si vous êtes un site de news ou à contenu visuel, trackez la fin de téléchargement de la première image visible utile par exemple (tiens, voici du code qui peut vous y aider). Si votre fonctionnalité principale dépend de JavaScript (vidéo, moteurs de recherche complexes, application…), il est encore plus facile de minuter le moment où le contenu devient interactif.

La navigation interne

Le dernier point consiste à ne pas décevoir l’utilisateur après la première page, que ce soit la vitesse de chargement des pages suivantes ou la fluidité de l’interface.

Là vous pouvez surveiller les taux de mise en cache client (utilisation avancée de WebPagetest Monitor) et simuler des navigations dans vos tests de performance.

Il n’y a pas de moyen facile et automatique de surveiller que l’interface elle-même est fluide sur mobile : contentez-vous d’une vérification systématique et digitale.

Stratégies de chargement

Il faut jouer avec la perception utilisateur et afficher quelque chose d’utile le plus rapidement possible. Cela demande à s’asseoir autour d’un café avec les autres équipes et à écrire la liste des priorités d’une page. Charge à vous de traduire cela en code pour régler l’ordre dans lequel les ressources vont être chargées par le navigateur.

Prenons 2 exemples de sites qui ont fait ce travail de priorité des requêtes.

Home Google

La fonctionnalité principale est évidemment l’affichage du champ texte. Mais les fonctionnalités secondaires sont légion : autocomplete sur ce champ, l’obligatoire intégration Google+, le menu, la suggestion de géolocalisation et même une bannière d’auto-promotion.

Google n’attend pas : il embarque un CSS minimaliste et suffisant dans le HTML, le HTML ne contient que le champ et des éléments pour définir la structure de la page. En 1 requête et 22Ko, soit l’équivalent de 2 allers-retours réseau, la fonctionnalité principale est déjà utilisable. Ensuite arrivent plus de 200Ko de ressources diverses pour afficher et rendre fonctionnel le reste de la page.

Home avec carrousel massif

Cette homepage était principalement vue depuis la Chine, il a donc fallu la calibrer pour des petits débits / grosses latences : elle était déjà optimisée pour le mobile. Par contre il fallait également afficher dans un carrousel plusieurs images de haute qualité de 1200 pixels de large.

Du point de vue du réseau, charger plusieurs ressources en parallèle est généralement vu comme une bonne idée. Sauf lorsque le débit est ténu et les ressource trop grosses comme c’est le cas ici. Le chargement de plusieurs images en simultané ralentissait le chargement des ressources du chemin critique.

Il a donc fallu prioriser : logo, texte, et image principale d’abord.

Les fonctionnalités secondaires sont les icônes, un moteur de recherche (non visible ici) les autres images du carrousel et des images bien plus bas.

Adieu donc la police, utilisation de data:uri pour embarquer le logo en base64, inclusion en <img src> traditionnel de la première image du carrousel (et seulement elle) et on développe un petit script pour aller chercher de manière asynchrone les photos suivantes avant de vraiment démarrer le carrousel.

Conclusion : Mobile first

Ça n’est pas du lâcher de buzzword gratuit mais bien une adaptation à la manière dont nos utilisateurs utilisent nos sites, qu’ils soient en situation de mobilité, dans un pays lointain ou qu’ils fassent partie des 20% de français avec moins de 2Mb/s.

Le mobile first est l’héritier de la pensée « amélioration progressive » : délivrons très rapidement la promesse initiale, chargeons les fonctionnalité supplémentaires après et en fonction des capacités du client. Cela oblige à se poser la vraie question : quelles sont les priorités de chaque page ?

Cela s’intègre parfaitement avec un processus de conception moderne où designer et intégrateur web passent pas mal de temps l’un à côté de l’autre pour fignoler les maquettes sur les mobiles.

Nous avons évoqué une palanquée de techniques : certaines sont connues depuis bientôt 10 ans, beaucoup émergent et certaines sont devenues dangereuses. Toutes répondent à une situation particulière donc c’est à vous de tester ce qui marche ou pas, page à page.

Le processus de travail est presque aussi important que les techniques individuelles : la communication et l’effort de groupe sont vitaux pour maintenir la qualité à travers le temps. Sans monitoring ou automatisation des déploiements cela va rester amateur et pénible. Sans soutien hiérarchique du client (interne, externe, hiérarchique, bref celui qui vous paye) vous n’irez pas bien loin seul. Ou pire vous serez frustré par ce métier pourtant formidable qui est le nôtre.