.

Fasterize accélère la vitesse de chargement des sites web, et ce de façon automatisée.
Si la rapidité d’un site web est un challenge, l’automatisation de la webperf l’est tout autant ! Nous sommes évidemment en veille constante pour suivre les évolutions de l’état de l’art afin de proposer des fonctionnalités et des services adaptés tout en s’assurant de “remettre un peu d’ordre” dans les sites de nos clients.
Voici les enjeux prioritaires que nous avons identifiés pour 2019.

Notre métier, c’est la webperf. Since 2011, nous travaillons sur tous ses aspects :

  • mise en cache et réseau, dont on constate qu’ils sont généralement délégués à l’hébergeur et au CDN ;
  • traitement des pages envoyées au navigateur, ce qui est généralement assumé par les plateformes e-commerce, le CMS et les équipes de développement.

En matière de performance web automatisée, loin de nous l’idée de ne faire que sortir des nouvelles features en pagaille, nous travaillons aussi sur l’amélioration de l’existant afin de continuer à répondre aux besoins de nos clients et nous adapter toujours mieux à leur environnement.

Tags et third parties vs. Time to Interactive et Speed Index

Tags, third parties, services tiers ou widgets… 2018 est l’année du ras le bol : ils polluent tout simplement la performance !

La tendance est d’y déporter un grand nombre de fonctionnalités, même celles qui sont essentielles pour un site. Or cette pratique peut se révéler problématique en termes de garantie du service minimum (SLA) : comment faire pour leur appliquer un timeout ? Que faire en cas d’interruption du service ?

Autre phénomène lié aux third parties : vous scrutez votre Speed Index à la loupe, mais avez-vous mesuré votre Time to Interactive ? Car maintenant que votre Speed Index est optimisé, c’est bien souvent là que le bât blesse, et la façon dont sont implémentés ces third parties est bien souvent à l'origine des ralentissements. En effet, votre page a beau s’afficher rapidement, s’il n’est pas possible d’interagir aussi vite, la déception risque d’être au rendez-vous pour vos utilisateur.rice.s.

Comment traiter tous ces sujets à la fois ? La réponse se trouve certainement du côté des Service Workers qui permettent d’y apporter des réponses efficaces, tels que ceux que Fasterize prévoit. Ils apportent aussi des solutions pour automatiser la webperf sur des pages proposant des contenus personnalisés.

Gestion des JS et de la personnalisation

Nous venons de le voir, de plus en plus de sites e-commerce font opérer leurs fonctionnalités par des services tiers, notamment pour les contenus personnalisés. Certains sites en deviennent presque des “coquilles vides” qui ne font qu’accueillir applications en JS et des third parties.

Résultat : beaucoup d'éléments sont (re)générés dans le navigateur. Certains sites font appel à des scripts tiers, quand d’autres se chargent presque exclusivement en JS sans HTML côté serveur. Conséquence : un outil qui automatise la webperf  risque d’avoir très peu de quoi se nourrir pour procéder à l’amélioration de la vitesse de la page, le JS étant plus difficile à parser / comprendre que le HTML. Mais nous avons plus d’un tour dans notre sac, car grâce aux Service Workers (encore eux), nous déployons l’intelligence du moteur d’optimisation là où il y a justement à manger : dans le navigateur.

Autre exemple d’une pratique que nous observons et qui peut être contre-productive : ajouter un seul bundle contenant l’ensemble du JS du site et l’associer à un tag manager qui gère les fichiers tiers.

Et côté CSS ?

JS et CSS au régime

Eh bien… Idem côté CSS. Nous observons de plus en plus une concaténation à outrance du CSS (cela concerne aussi le JS) avec la mise en place d’un ou deux fichiers contenant l’ensemble du CSS d’un site en haut de page.

Cela amène plusieurs problèmes : d’une part, le navigateur télécharge du CSS inutile pour la page et construit un CSSOM plus lourd ; d’autre part, le navigateur ne peut pas utiliser les dernières évolutions telles que le streaming CSS.

Par ailleurs, les avancées récentes des navigateurs rendent possible l’affichage des éléments situés au dessus d’une balise CSS. Cela invite donc à repenser cette règle qui consiste à placer le CSS en haut d’une page.

Le challenge pour nous ? Garder uniquement la portion du CSS et du JS utile à l’affichage immédiat de la page. Cela se traduit par l’exploration de techniques :

  • de chargement du critical CSS,
  • de détection des dépendances entre fichiers JS pour générer des bundles adaptés via différentes solutions (tree-shaking, code splitting, lazyloading).

Mais revenons quelques instants à la question de la personnalisation.

Personnalisation (le retour) et mise en cache

Une question revient assez souvent chez Fasterize, et c’est sans surprise : “comment améliorer le temps de réponse serveur des pages... face à la personnalisation croissante des contenus, alors que cela les rend de moins en moins “cachables” ?”.
En pratique, les plateformes e-commerce récentes, telles Hybris ou Salesforce Commerce Cloud, proposent une catégorisation poussée des utilisateur.rice.s et sont capables de générer des pages différentes pour chacun.e.s. Dans ce cadre, mettre en place une stratégie de cache peut relever du parcours du combattant. De notre côté, nous adressons ce sujet grâce au SmartCache pour les zones contenant des informations personnalisées lorsqu’elles sont identifiables.

Mais comment faire pour les pages avec beaucoup de contenu dynamique ?
Nous ne mettons tout simplement pas la page en cache ! Mais nous préférons servir le plus tôt possible au navigateur des éléments sur les ressources de la page (Early Hints).

La mise en place de ces Early Hints passe par des en-têtes HTTP Link rel=preload, le support de l’HTTP/2 Push ou encore le support à venir du code HTTP 103.

Passons maintenant à un grand classique de la webperf : le poids des images.

L’automatisation des images responsive

Autre sujet largement abordé dans l’univers de la webperf : l’implémentation des images responsive.

De manière générale, différentes solutions existent :

  • l’utilisation de l’attribut srcset
  • l’utilisation de la balise picture
  • la prise en compte des Clients Hint côté serveur
  • la mise en place de Service Workers dédiés.

En ce qui concerne l’automatisation, le défi consiste à traiter deux problématiques à la fois :

  • générer des images de différentes tailles, formats, DPI, niveau de compression à partir d’une image présente sur le site,
  • servir la bonne image.

La première étape pour Fasterize consiste à prendre en compte le format WebP et à gérer le srcset.

Rester à la pointe sur les formats et les protocoles

Nous évoquions au début de cet article le fait que notre objectif n’est pas uniquement de sortir de nouvelle fonctionnalités, mais aussi de maintenir l’existant et l’améliorer.

Nous avons constaté qu’une majorité de sites ne tirent pas encore parti des améliorations des protocoles réseaux et formats de compression, alors qu’ils sont parfois devenus la norme : brotli, webp, woff2, ou encore TLS 1.3 côté réseau.

Ainsi, nous savons innover mais aussi “rester state of the art” ! Nous avons par exemple été parmi les premiers en France à proposer du HTTP/2 et du TLS 1.3, ce qui a permis aux utilisateurs qui n’ont pas la main sur leur infrastructure de profiter facilement de ces améliorations.

Certains de ces sujets sont en cours de traitement, d’autres déjà adressés - stay tuned pour découvrir prochainement et plus en détails les évolutions que nous mettons en œuvre...

D'ici là, faites un tour sur notre livre blanc pour décrypter et améliorer votre webperf :
Nouveau call-to-action