Comprendre l'optimisation du rendu des navigateurs

Que ressentez-vous quand un site met une éternité à charger ? Vous voyez le tableau : la page finit par s'afficher, mais impossible de cliquer ou de faire défiler parce que ça mouline encore en arrière-plan. 

Et quand, enfin, la page réagit, des animations à gogo rendent tout poussif et brouillon… Ça vous est déjà arrivé ? 

Moi oui — et pas plus tard que récemment. Et, incroyable mais vrai, je le vois encore souvent, alors qu’il existe tant d’outils et de bonnes pratiques d’optimisation. 

L’optimisation du rendu dans le navigateur est un vaste sujet qui couvre de nombreux domaines, des outils, des techniques et une infinité de possibilités d’amélioration. 

Cet article se concentre surtout sur la livraison efficace de la page côté utilisateur : temps de chargement, façons de les mesurer et leviers d’amélioration quand on travaille en frontend. 

Aspects de l’optimisation d’une page

Quant à rendre les pages plus rapides et plus réactives après le chargement (actions utilisateur plus vives et animations plus fluides), cela fera l’objet d’un autre article de blog. 

Commençons par les aspects suivants de l’optimisation d’une page, tels qu’on peut les aborder dans les paramètres de Chrome :

Pourquoi optimiser le rendu d’une page

Cycle de vie de l’application — le modèle RAIL 

Comment auditer une page — indicateurs et outils disponibles

Techniques d’optimisation — diverses solutions et astuces pour accélérer un site sur quatre volets : environment, assets, build et delivery

*(Comme l’optimisation du rendu et l’audit ont énormément évolué ces dernières années, impossible de tout couvrir en détail ici. Certains sujets ne seront qu’effleurés ; autant que possible, je pointerai vers des ressources externes pour aller plus loin.) 

Pourquoi optimiser le rendu dans le navigateur ? 

Beaucoup d’études et d’articles ont déjà montré à quel point les performances et diverses métriques d’expérience utilisateur comptent pour les entreprises.

Un collègue a récemment rédigé un excellent article qui rassemble de nombreuses données sur l’impact de l’UX d’un site sur des domaines clés d’une entreprise présente sur Internet. 

Vous pouvez lire cet article ici. 

Voici quelques chiffres rapides qui donnent la mesure de l’enjeu : 

Temps de chargement plus rapides : toute page qui se charge en moins de 5 secondes enregistre +25 % de visibilité publicitaire, +70 % de durée de session et −35 % de taux de rebond. 

Cinq secondes, ce n’est toutefois pas l’idéal. Une étude de 2016 a montré qu’un mobinaute sur deux s’attend à ce qu’une page se charge en moins de deux secondes, et jusqu’à 53 % des visiteurs abandonnent si cela dépasse 3 secondes. 

En 2017, Google a publié un rapport sur la façon dont le temps de chargement augmente le taux de rebond. Le même rapport indique que la vitesse de chargement initiale est le facteur le plus important aux yeux des utilisateurs lorsqu’on parle d’expérience utilisateur. 

En fait, c’est 3 fois plus important que l’apparence du site. C’est même considéré comme plus crucial que la facilité à trouver l’information recherchée ! Le temps de chargement est aussi directement corrélé aux revenus : 80 % des internautes sont prêts à payer davantage pour une bonne expérience.

Assez de théorie. Passons à la technique.

RAIL et le cycle de vie de l’application

Quand on parle de performances web, il est utile de se référer au modèle RAIL. RAIL distingue 4 étapes du cycle de vie d’une application (à ne pas confondre avec le cycle de vie des composants dans les principaux frameworks) : Response, Animation, Idle et Load. 

Cet ordre ne correspond toutefois pas à la chronologie réelle lorsqu’on ouvre un site (où l’on parlerait plutôt de LIAR : Load, Idle, Animation, Response).

 Je vais m’en tenir à cet ordre et détailler l’importance de chaque étape, une par une. 

La phase de Loading correspond au chargement initial de la page. Évidemment, plus c’est court, mieux c’est. Différentes sources suggèrent que cet événement devrait prendre entre 1 et 5 secondes maximum, mais selon les métriques Google, au-delà de 2,5 secondes, cela « nécessite des améliorations ». 

C’est l’un des paramètres les plus essentiels pour l’utilisateur. 

La phase Idle est le moment après le chargement initial où l’utilisateur réfléchit à ce qu’il va faire. La page attend son interaction ; on peut donc y terminer des tâches retirées du chargement initial (images, vidéos, sections de commentaires). 

Ces tâches devraient être exécutées en blocs de 50 ms pour que, dès que l’utilisateur interagit, la réponse à son action soit prioritaire sur tout ce qui se passe en arrière-plan. 

Pour que les Animations paraissent fluides, chaque frame doit être générée en moins de 16 ms. Dans un article sur le modèle RAIL sur web.dev, on peut lire : 

Dans les moments sous pression comme les animations, la clé est de ne rien faire quand c’est possible, et le strict minimum quand ça ne l’est pas. Autant que possible, profitez des 100 ms de la phase Response pour pré-calculer les opérations coûteuses afin de maximiser vos chances d’atteindre 60 fps. 

La phase Response correspond à la réaction à une action utilisateur (appuyer sur un bouton, changer de route, etc.) et devrait intervenir en moins de 100 ms — c’est le délai au-delà duquel l’utilisateur perçoit un « lag ». 

Sur le schéma ci-dessus, Load et Idle sont en bleu, tandis qu’Animation et Response sont en vert. En effet, Loading et Idle ne se produisent qu’une fois par nouvelle page (dans une SPA, potentiellement une seule fois pour toute la session), alors qu’Animation et Response sont répétées à chaque interaction.

Utiliser Google Web Vitals

Pour mesurer les performances d’un site et savoir si, quand et où optimiser, il nous faut des outils — idéalement universels pour comparer des résultats entre pages. 

Google a pris les devants avec Web Vitals. Web Vitals est une initiative de Google qui propose des repères unifiés pour les signaux de qualité essentiels à une excellente expérience utilisateur sur le Web. 

Il existe de nombreux outils de mesure et d’optimisation, mais Google a voulu en proposer un compréhensible et exploitable par tous. 

Dans ce but, ils ont également défini un sous-ensemble baptisé Core Web Vitals, qui mesure trois volets de l’UX : chargement, interactivité et stabilité visuelle. 

Ces volets sont mesurés via trois métriques :

Source: https://web.dev/vitals/ 

Largest Contentful Paint (LCP) — mesure le temps de chargement initial. L’objectif est d’être sous 2,5 secondes. Au-delà de 4 secondes, l’expérience est jugée médiocre.

First Input Delay (FID) — mesure l’interactivité. Une action utilisateur devrait être prise en compte en moins de 100 ms, sinon le site paraît lent. 

Cumulative Layout Shift (CLS) — indique la stabilité de la mise en page. Si le contenu se déplace pendant le chargement (images qui poussent le texte, publicités tardives, etc.), l’UX est jugée mauvaise.

Mesurer les Core Web Vitals avec Lighthouse

Il existe plusieurs façons de mesurer les Core Web Vitals (et d’autres métriques). L’outil que tout développeur devrait connaître est Lighthouse : un outil automatisé et open source pour mesurer les performances d’un site et en signaler les faiblesses. 

Il se trouvait auparavant dans l’onglet Audits des DevTools, mais a été retiré et remplacé par une extension Chrome dédiée.

Si le site à auditer est déjà en ligne, pas besoin d’extension. L’outil est accessible ici. Lighthouse intègre les trois indicateurs ci-dessus (LCP, FID, CLS), et d’autres encore. 

Voyons cela :

Voici un audit Lighthouse lancé sur un site pris au hasard avec ses résultats correspondants :

Source: https://web.dev/measure/ 

On distingue quatre grandes sections : Performance, Accessibilité, Bonnes pratiques et SEO. Puisque nous nous concentrons sur la performance, détaillons ce score.

En bas du rapport, six métriques décrivent différentes facettes des performances :

Speed Index (SI) — comparaison de l’indice de vitesse de votre page avec celui de sites réels, d’après les données de HTTP Archive. Plus d’infos sur le Speed Index ici. 

Time to Interactive (TTI) — mesure le temps nécessaire avant que la page devienne pleinement interactive. Il prend en compte, entre autres, le FCP, l’enregistrement des gestionnaires d’événements des éléments visibles et la réponse aux actions en moins de 50 ms.  Détails ici sur le calcul du TTI. 

Total Blocking Time (TBT) — étroitement lié à la phase Idle du modèle RAIL. Il additionne le temps où la page est bloquée par l’exécution de tâches longues en arrière-plan. Idéalement, chaque tâche ne devrait pas dépasser 50 ms. 

Cela dit, Lighthouse n’est pas parfait. Avec le temps, des incohérences ont été observées, documentées notamment sur le site de Calibre et dans cet article de blog. 

PageSpeed

Un autre excellent outil de mesure est le site PageSpeed de Google Developers. C’est très simple : collez l’URL à auditer, cliquez sur Analyze. En quelques secondes, vous obtenez un rapport en deux parties et pouvez choisir le type d’appareil. 

Commençons par la seconde partie, Diagnose Performance Issues. Ça vous dit quelque chose ? Normal : c’est le même rapport que Lighthouse. PageSpeed embarque les résultats de laboratoire de Lighthouse. 

Cool. Ou pas. Et si votre page affiche des performances moyennes sans que vous sachiez précisément pourquoi ? Lighthouse vous aide là aussi. 

En faisant défiler, vous verrez une liste de problèmes potentiels par aspect de performance, avec des pistes de solution. Ils sont marqués et triés selon leur sévérité et leur impact. 

La première partie du rapport est la plus importante car elle reflète l’expérience RÉELLE des utilisateurs sur votre site, basée sur des sessions réelles d’utilisateurs Chrome. Vous voyez ainsi le comportement en conditions réelles, par opposition au contexte plus « laboratoire » de Lighthouse. 

Vous pouvez en outre mesurer séparément l’expérience sur desktop et mobile.

En haut du rapport PageSpeed, vous verrez un indicateur que nous n’avons pas encore abordé : FCP (First Contentful Paint). 

Le FCP indique le moment où l’utilisateur voit déjà un premier contenu. C’est une métrique utile, car il est crucial qu’au moins quelque chose apparaisse rapidement sur la page :

Source: https://pagespeed.web.dev/ 

Tout cela fait beaucoup de théorie et de ratios. Passons aux raisons principales de mauvais scores — et à la façon de les améliorer. 

Optimiser via Environment, Assets, Build et Delivery 

Puisqu’on parle enfin d’optimisation, voici dix astuces pour rendre votre page ultra-rapide et ne plus jamais rien optimiser.

Je plaisante. 

En fait… pas totalement. Qu’est-ce que je veux dire ?

Des tonnes de guides expliquent comment optimiser les performances web. Vitaly Friedman a écrit un article remarquable qui couvre quasiment toutes les méthodes d’optimisation du rendu en 2021 — une lecture fleuve d’environ 3 heures. 

Avec la variété des environnements de développement, les combinaisons sont infinies. Ce qui marche dans une app ne fonctionnera pas forcément dans une autre. 

Nous n’allons donc pas tout couvrir ici — cela exigerait un autre pavé de 3 heures et répéterait des auteurs plus pointus que moi. 

À la place, voici une liste de points à considérer pour optimiser votre application, sur quatre volets accessibles au développeur frontend : environment, assets, build et delivery.

Environment 

Build tools — Grunt, Gulp, Webpack, Parcel, Rollup, Snowpack… Tant que vos objectifs de maintenance et de performance sont atteints, vous êtes sur la bonne voie, quelle que soit la config. En cas d’hésitation, notez que Webpack existe depuis longtemps et propose une vaste panoplie de plugins d’optimisation. 

Framework — Angular, Vue, React, Svelte ? Gardez en tête que les frameworks modernes ne favorisent pas forcément les appareils modestes. Et, dans une SPA, chaque page n’a pas besoin de charger l’intégralité du framework. Pour aller plus loin, lisez cette excellente étude de cas Netflix ici

Rendering — Server-Side, Static, Streaming Server-Side, Client-Side… Quel que soit votre choix, la priorité est de minimiser l’écart entre LCP et TTI.

Baseline performance cost — Plutôt que d’adopter un framework « pur », vous pouvez aussi vous en passer — ou choisir une alternative opinionated comme Next.js, Nuxt.js ou React, etc. Voici une étude intéressante sur le coût performance des frameworks. 

Source: https://timkadlec.com/remembers/2020-04-21-the-cost-of-javascript-frameworks/

Assets

AVIF, AV1, WebP, WebM — Utiliser des formats photo et vidéo modernes peut réduire drastiquement les temps de chargement. Le support de WebM et AVIF continue de s’étendre.

Responsive images — Utilisez toujours des images responsives avec srcset, sizes et l’élément <picture>. Les images d’arrière-plan peuvent aussi être responsives — regardez la propriété CSS image-set. 

Web fonts, Google Fonts — Un vaste sujet en soi, à creuser dans cet article.

Brotli — Un format de compression sans perte open source prometteur. 

GIFs — Oubliez-les : côté poids, c’est catastrophique. Préférez des vidéos HTML en boucle :

Source: https://www.smashingmagazine.com/2021/01/front-end-performance-2021-free-pdf-checklist/#defining-the-environment 

Build

JS modules, pattern module/nomodule (differential serving) — À voir dans la documentation du moteur V8 et sur le blog Planete Performance.

Tree-shaking, code-splitting, scope-hoisting — Vous les connaissez sans doute : ils sont standard dans des builders comme Webpack. 

Web worker — Pour réduire le TTI, déléguez une partie des calculs initiaux à un web worker. 

Optimisation des SPA — La majorité des devs frontend utilisent aujourd’hui des frameworks SPA. Il y a évidemment beaucoup à faire pour améliorer leurs perfs, mais pour rester concis, voici un excellent article pratique de CSS-Tricks. 

Identifier et supprimer le CSS/JS inutilisé — Utilisez Chrome DevTools (outil Coverage), ou Puppeteer qui sait aussi préparer du contenu pré-rendu.

Partial hydration — Pour creuser, lisez ces études de cas : celle-ci pour React, et cet article pour Vue. 

Cache-Control — Le caching n’est pas nouveau, mais dès qu’on creuse, l’iceberg apparaît. Les stratégies et pièges sont nombreux pour définir la mise en cache par le navigateur. Pour une intro rapide, rendez-vous ici. Pour aller plus loin, cet article montre comment un aller-réseau peut parfois être plus rapide que le cache.

Librairies tierces — Moins il y en a, mieux c’est. Selon thirdpartyweb.today, les librairies tierces comptent pour 57 % de tout le code JS exécuté. Et si vous en avez besoin, préférez l’auto-hébergement.

Source: thirdpartyweb.today 

Delivery

Lazy loading — En plus d’utiliser defer ou async pour certains scripts, le lazy-loading natif est déjà supporté par tous les navigateurs (pour les images ; les iFrames suivront). 

Intersection Observer — Selon sa définition : l’Intersection Observer API permet d’observer de façon asynchrone l’intersection d’un élément cible avec un ancêtre ou avec le viewport du document. En clair, elle offre un contrôle fin sur les éléments sur le point d’entrer dans le champ de vision. Combinée au lazy-loading, c’est très puissant. Si vous ne l’avez jamais utilisée, voici un bon exemple concret.

Content visibility — Une fois supportée partout, on pourra faire du lazy-loading de sections entières en pur CSS. Si votre homepage est longue (multiples sections), il sera pertinent de les rendre juste avant leur apparition à l’écran. Voici un excellent exemple pour accélérer le LCP. 

Critical CSS — Pratique courante : séparer ou marquer le CSS au-dessus de la ligne de flottaison et l’inclure dans le <head>.

Service worker — Ils permettent aussi de réduire fortement les chargements suivants grâce aux ressources en cache

Rendering performance — Pour qu’un site paraisse réactif, il faut comprendre le pipeline de rendu des frames et l’optimiser. C’est un vaste sujet en soi ; nous publierons un article dédié pour optimiser les phases Animation et Response du modèle RAIL.

Connection-aware components — Profitez des API de navigateur pour adapter le rendu selon la bande passante (voir l’objet navigator.connection). Très utile pour une application mondiale où les débits vont du très lent à l’ultra-rapide :

Source: https://dev.to/addyosmani/loading-web-pages-fast-on-a-20-feature-phone-8h6 

Optimisation proactive et réactive du navigateur

La liste ci-dessus peut sembler intimidante. Vous vous demandez peut-être : pour que mon site soit au top, dois-je tout passer en revue ? 

Il est bon d’avoir ces points à l’esprit, mais l’optimisation doit mêler proactif et réactif. Certaines bonnes pratiques sont évidentes et à intégrer dès l’écriture du code : gestion des dépendances, SSR, gestion des assets, polices, tree-shaking, bibliothèques tierces, caching et lazy-loading. Les intégrer au quotidien augmente fortement vos chances d’obtenir de bons scores à toute analyse de performance. 

Si les résultats restent décevants, les outils cités feront ressortir les points faibles à optimiser ensuite (Webpack, CDN, SSR, differential serving, partial hydration, imports différés, rendu différé, Critical CSS, service worker, etc.). 

Si vous voulez voir un parcours d’optimisation sur la landing d’une grande marque de mode, regardez cette vidéo d’Addy Osmani, l’un des spécialistes Google de l’optimisation.

Vous pouvez aussi dépasser le code et le serveur, et plonger dans la configuration au niveau du navigateur pour optimiser Google Chrome. Pour beaucoup d’utilisateurs, explorer simplement les paramètres de Google Chrome suffit à faire ressortir des options comme l’accélération matérielle et le flag « Override software rendering list ». Sur certaines machines, l’accélération matérielle délègue le travail au GPU et aide réellement Chrome à afficher des pages complexes plus fluidement ; sur d’autres, elle introduit saccades et artefacts visuels. Dans ces cas, désactiver l’accélération matérielle dans les paramètres de Chrome peut rendre le navigateur plus stable et prévisible sur des sites riches en animations ou en graphismes.

Pour des diagnostics plus poussés, Google Chrome embarque aussi un Gestionnaire des tâches (Shift+Esc) qui montre quels onglets, extensions et processus consomment le plus de CPU et de mémoire pendant le chargement. Cela facilite l’identification d’une extension du Chrome Web Store qui dégrade les performances, même si votre code et votre serveur sont optimisés. En combinant une hygiène stricte des extensions avec une configuration raisonnable du navigateur, vous gagnez une couche de contrôle supplémentaire sur les performances réelles, en complément de toutes les optimisations de rendu et de livraison décrites plus haut. 

En résumé

À ce stade, j’espère que l’importance d’offrir une expérience utilisateur optimale est claire. Après avoir abordé les deux premières étapes du modèle RAIL, la bonne approche du chargement des pages et la façon de fournir rapidement le contenu recherché devraient l’être aussi.

Nous avons également vu Lighthouse et PageSpeed, deux outils qui aident à identifier ce qui plombe la réactivité d’une page. Puis un aide-mémoire condensé listant des techniques d’optimisation pour atteindre cet objectif. 

Au final, souvenez-vous que les sujets décrits ici ne sont que la partie émergée de l’iceberg. J’espère toutefois que cela vous donnera envie d’explorer plus loin certaines pistes évoquées — et qu’en le faisant, vous renforcerez sensiblement vos compétences en optimisation de sites.

Bon code !