Chaque nouvelle année s’accompagne de son lot de prédictions. Comme les “bonnes résolutions”, les mêmes se retrouvent souvent d’année en année, ou au contraire ne sont pas observées.
Pour 2020, à défaut d’une boule de cristal, nous avons sondé nos experts webperf pour savoir quelles tendances ils pensent voir émerger ou se confirmer.
Des features webperf intégrées nativement aux navigateurs
Les navigateurs seront amenés à proposer de plus en plus de fonctionnalités, et notamment à intégrer nativement des optimisations webperf.
Dans sa conférence à Perf.now() 2019, Ilya Grigorik souligne que malheureusement, la web performance s'adresse surtout aux sites à forte audience, et toute la “longue traîne” passe totalement à côté. Pourquoi ? Parce que l’investissement pour appliquer les bonnes pratiques est trop important et surtout disproportionné à l’échelle de leur business.
Des acteurs comme Google ont longtemps donné les outils aux éditeurs pour qu’ils implémentent eux-mêmes les bonnes pratiques (l’ajout de nouvelles API Javascript : Intersection Observer, RequestIdleCallback…), ce qui n’a réellement profité qu’aux plus gros acteurs qui avaient les moyens de le faire.
La solution pour un web globalement plus rapide : faire en sorte d’automatiser les optimisations, et aussi faire en sorte qu’elles soient gratuites en termes de budget et de ressources. Et pour ce faire, pourquoi ne pas laisser ce rôle aux navigateurs ? Si l’implémentation manque alors potentiellement de finesse, l’amélioration devient malgré tout accessible au plus grand nombre.
C’est en tout cas le propos d’Ilya Grigorik, qui concerne principalement les images, mais qui peut tout à fait s’appliquer à d’autres optimisations webperf.
D’ailleurs, Chrome permet déjà de lazyloader les images en ajoutant un attribut loading à la vénérable balise IMG. A terme, cette fonctionnalité sera-t-elle active sans attribut ?
Même si cette première implémentation de Chrome est sujette à débat, les premières pierres de l’édifice sont en place.
Demain, les navigateurs pourraient être par exemple capables de retraiter les images lors de l’upload vers un serveur ? Est-ce souhaitable ? Quels sont les risques pour la neutralité du net (nous avons déjà soulevé cette question à propos de Chrome Lite Pages) ?
Est-ce que le lazyload natif de Chrome rendrait les autres lazyloaders inutiles ? D’après Aaron Peters, a priori nous n’en sommes pas là.
L’évolution des navigateurs rendra forcément certaines optimisations et bonnes pratiques caduques ; de la même manière que HTTP/2 a rendu obsolètes des optimisations comme la concaténation, le sharding, le cookie-less domain, le critical CSS inlining/preloading…
Mais est-ce que cela signifie que nous n’aurons plus rien à faire chez Fasterize ? Absolument pas ! D’abord nous avons constaté que malgré le déploiement de HTTP/2, des techniques censées disparaître comme la concaténation sont finalement encore valables. Et ensuite, parce que nous devrons par exemple continuer à agir sur les JavaScript (ce que nous verrons un peu plus tard dans cet article) pour décaler leur exécution et les rendre non bloquants, automatiser la mise en place de pages de débordement…
Par ailleurs, nos missions vont probablement se porter vers d’autres domaines comme le Cloud SEO.
Google fait main basse sur la webperf
Google fait maintenant autorité dans le domaine de la web performance. Tout d’abord, Chrome est devenu l’unique navigateur à encore proposer des évolutions orientées webperf : le preloading, l’API Intersection Observer, l’API RequestIdleCallback, le lazyload natif… Firefox a ainsi de plus en plus de mal à exister et stagne à 7 % de part de marché en Europe. Malgré des efforts (la prise en compte du format d’images Webp par exemple), les dernières évolutions instaurées par Chrome continuent de creuser l’écart (Firefox ne supporte toujours par le preloading par exemple).
Google a aussi écrasé la concurrence en termes de monitoring en imposant ses métriques et son outil. Discuté et décrié, le Time To Interactive en est le plus bel exemple. Côté outillage, Lighthouse et surtout le Chrome User Experience Report (CrUX) sont maintenant omniprésents et utilisés dans tous les outils Google : Search Console, Page Speed Insight.
L’exploration de nouvelles métriques
Entre explorations et volonté de mesurer toujours mieux ce que perçoivent les internautes, deux indicateurs ont retenu notre attention.
Le LCP
Annoncé à l’automne 2019 pour prendre le relai du First Meaningful Paint (FMP), le Largest Contentful Paint (LCP) mesure le temps nécessaire pour l’affichage du plus grand élément dans le viewport. Une mesure centrée utilsateur.rice, donc, qui tente d’évaluer la perception de vitesse en tenant compte de l’apparition de contenus importants et qui rassurent sur le fait que le site fonctionne.
Le Frustration Index
Dans une démarche presque “meta”, Tim Vereecke propose de mesurer non plus des événements, mais le temps entre ces événements avec le FRUSTRATIONindex.
Partant du postulat que la frustration peut naître de l’attente entre ces événements, et pas seulement du temps nécessaire pour qu’ils surviennent, Tim Vereecke a identifié 4 étapes marquantes dans le chargement d’une page pour établir un score :
- Affichage du titre (TTFB)
- Affichage du 1er contenu est visible (FCP)
- La page est visuellement prête (Speed Index, TTVR pour Boomerang, LCP pour Chrome)
- La page est interactive et prête à être utilisée (Largest value of Pageload et TTI)
Le FRUSTRATIONindex peut être calculé aussi bien par des outils de monitoring de synthèse ou de RUM, une version beta est proposée ici si vous voulez tester.
La Privacy
La protection des données personnelles - ou privacy - fait partie des préoccupations des internautes, et donc des éditeurs qui sont de plus en plus soumis à la pression de divers organismes et dispositifs. Parmi les plus connus : la CNIL, qui reçoit un nombre croissant de plaintes, ou encore la RGPD (certains essaient d’ailleurs de jongler plus ou moins habilement avec).
Cette pression vient en fait de tous les côtés : également de la part des utilisateur.rices, mais aussi des navigateurs qui - sans aller jusqu’à des dispositifs extrêmes tels que les bloqueurs de pop-up il y a une quinzaine d’années - proposent des modes adblock permanent, à l’instar de Brave.
L’effet immédiat que nous avons constaté à l’entrée en vigueur de la RGPD est l'amélioration des performance des sites visités sans cookies, car beaucoup n’incluaient pas les Third Parties tant que les CGU n’étaient pas acceptées.
Alors, si tout le monde continue à militer pour davantage de privacy, on peut imaginer qu’il y aura de moins en moins de scripts tiers, et donc de meilleures performances.
La gestion de l’offline
La gestion de l’offline n’est pas une préoccupation récente, mais elle pose de telles difficultés qu’elle est peu adressée.
Dans la veine de ce que permettent de faire les Progressive Web Apps (PWA), le principe consiste à afficher une page web… sans internet. Ainsi, lorsqu’une page est présente dans le cache offline du navigateur, l’affichage est immédiat même s’il n’y a pas de réseau.
En termes de développement, il suffit ensuite de choisir quelle version du contenu doit s’afficher : celle en cache ; une version plus ancienne ; ou plutôt une page d’attente pour éviter l’affichage de contenus potentiellement périmés, quitte à attendre d’accéder à nouveau au réseau.
Une fois cette technique adoptée, l’affichage pour l’utilisateur.rice standard (avec du réseau) est quasi instantané, étant donné qu’on peut se passer d’une nouvelle requête serveur pour récupérer les données.
C’est ce que propose par exemple L’Equipe avec son mode offline, ce qui est encore plus efficace que le système classique de cache côté client.
Du Front-end au Back-end : JavaScript se faufile partout
Passion JS - qui est toujours plus présent en Front mais qui revient aussi côté serveur. Ce paradigme apporte son lot d'opportunités mais soulève aussi quelques difficultés - qui ne sont pas sans solution, heureusement, puisqu’on observe une réelle prise de conscience du problème que pose l’exécution des JS à tout-va côté client.
Dans ce sens, nous étudions actuellement des fonctionnalités qui permettraient de gérer au mieux les Third Parties :
- blocage des Third Parties conditionnellement (par exemple, supprimer un A/B inactif)
- séquençage du chargement des Third Parties pour éviter trop de requêtes en parallèle
- mise en place d’un timeout de chargement.
La “nouveauté” : le Server Side Rendering
Bien que le concept soit aussi âgé que le Web, le Server Side Rendering tend à se (re)déployer massivement, simplifié par des framework comme next.js, nuxt.js...". Comme c’est dans les vieux pots qu’on fait les meilleurs soupes, on revient à la génération de HTML côté serveur, mais en JS (lequel devient présent du début à la fin de la chaîne).
S’il est plus fastidieux à mettre en place qu’un rendu uniquement côté client, l’un des avantages du Server Side Rendering est de permettre d'améliorer à la fois :
- le SEO, avec la garantie d’une meilleure indexation, même s’il existe une version navigateur du crawler de Google ;
- et l’affichage, plus rapide puisque le HTML est construit côté serveur et ne nécessite plus d’attendre l’exécution de JS côté client.
Citons l’exemple de CDiscount.com, dont le rendu est particulièrement rapide grâce à un développement full React + styled-components - il n’y a même pas de fichier CSS à charger parce qu’il est embarqué directement dans le HTML. Le Speed Index est ainsi dopé, cette technique étant l’équivalent de l’optimisation webperf qui consiste à inliner les CSS.
Ce dispositif peut faire gagner beaucoup de temps sur l’affichage pour les internautes, mais mal configuré, il peut être responsable d’une réactivité médiocre. Pourquoi ? Eh bien, à cause de l’exécution des JS qui peut prendre du temps sur des mobiles d’entrée de gamme (nous allons y revenir), ce qu’illustre très bien le FRUSTRATIONindex.
Alors, comment surfer au mieux sur cette tendance et accélérer l’affichage autant que l’interactivité de vos pages ?
Voici les solutions que nous pressentons :
- les évolutions des bundlers tels que Webpack et consorts (une technologie qui exige une certaine expertise et sur laquelle nous pouvons d’ailleurs vous accompagner) :
- le tree-shaking (n’embarquer que le code utilisé) de Webpack qui gère des cas de plus en plus fins,
- les librairies nativement ES6+ qui sont prises en charge,
- un minifier plus efficace
- un écosystème de plug-ins qui s’étoffe...
- l’évolution des frameworks JS comme React, qui travaille sur ces sujets avec une réflexion résolument orientée webperf ;
- la possible intégration de Web Assembly à des frameworks JS majeurs, pour un code nativement plus rapide ;
- l’utilisation des Web Workers dans des frameworks JS, pour ne pas bloquer le thread principal ;
- en plus des outils qui permettent de tester unitairement, fonctionnellement, la qualité de code, la couverture du code, l'accessibilité etc., la maturation et la multiplication d’outils permettant de tester la webperf dans le cadre d’une intégration continue (CI), pour aussi mieux gérer le Budget Performance :
Le risque : JS sur les mobiles peu puissants
Nous abordions déjà ce sujet en 2019 : il est impératif de tester un site sur TOUS les devices, même (surtout) les mobiles d’entrée de gamme.
En France, le budget médian consacré à un téléphone mobile est de 200 euros. C’est une information à intégrer à tout prix pour se rendre compte des conditions réelles d’utilisation de ses visiteur.se.s. Eh oui, dans la plupart des cas, la majorité de l’audience mobile n’est pas équipée de portables dernier cri !
Depuis les 3 dernières années, les sites contiennent beaucoup plus de JS que ce que la plupart des mobiles sont capables de supporter. Nous le constatons d'ailleurs auprès de nos clients chez Fasterize : même sur des sites que nous optimisons, étant donné la quantité de JS côté Front-End, le temps d’exécution des JS peut quasiment égaler et parfois dépasser le temps nécessaire pour charger les fichiers, comme on le voit par exemple :
- dans cette présentation de Tim Kadlec à Perf.now(), à partir de données CrUX, où on voit qu’il faut 3,4 s pour exécuter 1,9Mo ;
- dans ce cas client où il faut environ 1,8s pour charger le fichier en 4G, 1,6 s pour l'exécuter sur un mobile.
Alors, même si les mobiles évoluent et sont de plus en plus puissants, le web n’est pas forcément plus rapide dans l’absolu (c’est aussi ce que souligne Gilles Dubuc de Wikipedia dans son talk à We Love Speed 2019).
En somme, le meilleur moyen pour se rendre compte de la vitesse de son site est de le tester dans des conditions qui correspondent à la réalité des utilsateur.rice.s.
De manière générale, les temps de chargement deviennent un enjeu de plus en plus important pour l’ensemble des acteurs du web, mais en parallèle, les contenus multimédias et la personnalisation vont croissant… en même temps que la navigation sur mobile.
Alors, ces tendances vont-elles se confirmer ? D’autres vont-elles émerger en cours de route ? Nous sommes évidemment impatient.e.s de le découvrir !
Et pour rester au courant de ce qui se passe dans l’univers de la webperf et chez Fasterize,
abonnez-vous à notre newsletter mensuelle :
