Performances web, score Keeping your Lighthouse 100.

La qualité de l’expérience des sites web est essentielle pour atteindre les objectifs commerciaux de votre site web et la satisfaction de vos visiteurs et visiteuses.

Adobe Experience Manager (AEM) est optimisé pour offrir d’excellentes expériences et des performances web optimales. Grâce à la collecte de données d’opérations Real Use Monitoring (RUM), les informations sont collectées en permanence à partir de l’utilisation sur le terrain et offrent un moyen d’effectuer une itération sur les mesures de performances d’utilisation réelle sans avoir à attendre que les données CRuX montrent les effets des modifications de code et de déploiement. Il est courant que les données de terrain collectées dans RUM s'écartent des résultats du laboratoire, car le réseau, la géolocalisation et la puissance de traitement des dispositifs réels sont beaucoup plus diversifiés que les conditions simulées dans un laboratoire.

Le service d'informations PageSpeed de Google s'est avéré être un excellent outil de mesure de laboratoire. Il peut être utilisé pour éviter la lente détérioration des performances et du score d’expérience de votre site web.

Si vous commencez votre projet avec le Boilerplate comme dans le tutoriel pour les développeurs, vous obtiendrez un score Lighthouse très stable sur PageSpeed Insight pour les appareils mobiles et de bureau à 100. Sur chaque composant du score lighthouse, il existe une zone tampon que le code du projet peut utiliser tout en restant dans les limites d’un score lighthouse 100 parfait.

Test De Vos Requêtes D’Extraction

Il s’avère qu’il est difficile d’améliorer votre score Lighthouse une fois qu’il est faible, mais il n’est pas difficile de le maintenir à 100 si vous le testez en permanence.

Lorsque vous ouvrez une requête de tirage (PR) sur un projet, les URL de test dans la description de votre projet sont utilisées pour exécuter le service PageSpeed Insights. Le robot GitHub d’AEM fera automatiquement échouer votre requête de tirage si le score est inférieur à 100 avec un peu de mémoire tampon pour tenir compte d’une certaine volatilité des résultats.

Les résultats sont pour le score mobile lighthouse, car ils ont tendance à être plus difficiles à obtenir que les ordinateurs de bureau.

Pourquoi utiliser Google PageSpeed Insights ?

De nombreuses équipes et individus utilisent leurs propres configurations pour mesurer les scores Lighthouse. Différentes équipes ont développé leurs propres harnais de test et utilisent leurs propres outils de test avec des configurations qui ont été mises en place dans le cadre de leurs pratiques de surveillance continue et de rapports de performance.

Les performances d’un site web ont une incidence sur son classement dans les résultats de recherche, qui est reflété par les principales vitales web dans le rapport crUX. Google possède une grande maîtrise des combinaisons moyennes pertinentes d’informations sur les appareils (par exemple, la taille de l’écran) ainsi que des performances réseau de ces appareils. Mais en fin de compte, le référencement est l’arbitre ultime de ce qu’est une bonne ou une mauvaise performance web. La configuration spécifique étant une cible en mouvement, les pratiques de performances doivent être alignées sur les caractéristiques moyennes actuelles des appareils et des réseaux au niveau mondial.

Ainsi, au lieu d’utiliser une configuration spécifique au projet pour les tests Lighthouse, nous utilisons les configurations mises à jour en continu dans le cadre des stratégies pour appareils mobiles et ordinateurs de bureau référencées dans les dernières versions de Google API PageSpeed Insights.

Bien que certains développeurs pensent pouvoir recueillir des informations supplémentaires à partir d’autres méthodes de mesure des scores Lighthouse, pour pouvoir avoir une conversation significative et comparable sur les performances entre les projets, il doit y avoir un moyen de mesurer les performances de manière universelle. Le service PageSpeed Insight par défaut est le test en laboratoire le plus fiable et le plus largement accepté lorsqu’il s’agit de mesurer vos performances.

Cependant, il est important de se rappeler que les recommandations que vous obtenez de PageSpeed Insights ne conduisent pas nécessairement à de meilleurs résultats, en particulier plus vous vous rapprochez d’un score lighthouse de 100.

Les données Web vitales (CWV) collectées par la collecte de données RUM intégrée jouent un rôle important dans la validation des résultats. Toutefois, pour des changements mineurs, la variance des résultats et le manque de points de données suffisants (trafic) sur une courte période rendent impossible l'obtention de résultats statistiquement pertinents dans la plupart des cas.

Chargement Triphasé (E-L-D)

La division en trois phases de la payload présente sur une page web permet d’obtenir un score lighthouse correct et de définir ainsi une référence pour une expérience client optimale.

L’approche de chargement en trois phases divise la payload et l’exécution de la page en trois phases

Phase E : Impatient

Avant toute chose, il est important de noter que le corps doit être masqué (avec display:none) pour vous assurer qu’aucune image ne commence à se télécharger et pour éviter toute CLS initiale.

Dans la phase eager, la première action consiste à « décorer » le DOM : la séquence de chargement effectue quelques réglages, ajoute principalement des classes CSS aux icônes, boutons, blocs et sections et crée les auto-blocs. Voir la page Balisage, sections, blocs et blocage automatique pour plus d’informations sur les balises résultantes.

Le corps peut alors déjà être affiché, étant donné que les sections ne sont pas encore chargées et restent masquées.

Ensuite, la première section complète est chargée avec une priorité donnée à la première image de cette section, le « candidat LCP ». En théorie, plus la première section comporte de blocs, plus le chargement des LCP est rapide.

Une fois le LCP candidat et tous les blocs de la section chargés, la première section peut être affichée et les polices peuvent commencer à se charger de manière asynchrone.

Cela met fin à la phase avide.

LCP

En règle générale, l’LCP est l’image « héros » affichée en haut d’une page. Il est essentiel de s’assurer que cette image est chargée et affichée dès que possible dans la séquence de chargement (voir la phase Eager).

Tout ce qui doit être chargé pour que le LCP réel s’affiche doit être chargé. Dans un projet, il s’agit généralement des balises, des styles CSS et des fichiers JavaScript.

Dans de nombreux cas, l'élément LCP est contenu dans un bloc, où le bloc .js et .css doivent également être chargés.

Il est recommandé de conserver la payload agrégée avant que la LCP ne s’affiche en dessous de 100 Ko, ce qui entraîne généralement un événement LCP plus rapide que 1 560 ms (score LCP à 100 dans PSI). Surtout sur mobile, le réseau a tendance à être limité en bande passante, de sorte que la modification de la séquence de chargement avant LCP a peu ou pas d’impact.

Le chargement depuis ou la connexion à une deuxième origine avant que l’LCP ne se produise est fortement déconseillé, car l’établissement d’une deuxième connexion (TLS, DNS, etc.) ajoute un retard significatif au LCP.

Il existe des situations où l’élément LCP réel n’est pas inclus dans le balisage transmis au client. Cela se produit lorsqu’il y a une indirection ou une recherche (par exemple un service appelé, un fragment chargé ou une recherche devant se produire dans une .json) pour l’élément LCP.
Dans ce cas, il est important que le chargement de la page attende, en devinant le candidat LCP (actuellement la première image de la page), que le premier bloc ait apporté les modifications nécessaires au DOM.

Il existe d’autres situations où le contenu contient 2 images principales, l’une pour bureau, l’autre pour mobile. Comme ci-dessus, il est important de s’assurer que l’image correcte est considérée comme la LCP candidate et que le bloc « héros » doit être ajusté pour supprimer l’image inutile du DOM (supprimez l’image de bureau sur les appareils mobiles ou vice versa) pour ne pas charger une image consommatrice de bande passante ou, pire encore, chargez d’abord l’image inutile en tant que LCP candidat.

Enfin, le LCP peut être autre chose qu'une image, une vidéo, un texte long… Pour tous ces cas, une compréhension approfondie de la séquence de chargement et de la façon dont le candidat LCP est calculé est nécessaire pour effectuer les optimisations correctes.

Phase L : différée

Dans la phase lazy, la partie de la payload chargée n’affecte pas le temps de blocage total (TBT) et, finalement, le premier délai d’entrée (FID).

Cela inclut des éléments tels que le chargement des sections suivantes et de leurs blocs (JavaScript et CSS), ainsi que le chargement de toutes les images restantes en fonction de leur attribut loading="lazy" et d’autres bibliothèques JavaScript qui ne sont pas bloquantes. La phase différée correspond généralement à tout ce qui se passe dans les différents blocks que vous allez créer pour répondre aux besoins du projet.

Au cours de cette phase, il serait toujours souhaitable que la majeure partie de la payload vienne de la même origine et soit contrôlée par la première partie, de sorte que des modifications puissent être apportées si nécessaire pour éviter un impact négatif sur la TBT, la TTI et la FID.

Phase D : différée

Dans la phase retardée, les parties de la payload sont chargées qui n’ont pas d’impact immédiat sur l’expérience et/ou qui ne sont pas contrôlées par le projet et proviennent de tiers. Pensez aux outils marketing, à la gestion du consentement, aux analyses étendues, aux modules de conversation/interaction, etc. qui sont souvent déployés par le biais de solutions de gestion des balises.

Il est important de comprendre que, pour minimiser l’impact sur l’expérience client globale, le début de cette phase doit être considérablement retardé. La phase retardée doit se situer au moins trois secondes après l’événement LCP afin de laisser suffisamment de temps pour que le reste de l’expérience soit réglé.

La phase retardée est généralement gérée dans delayed.js qui sert de fourre-tout initial pour les scripts qui provoquent des TBT. Idéalement, les problèmes de TBT sont supprimés des scripts en question, soit en les chargeant en dehors du thread principal (dans un programme de travail web), soit en supprimant simplement le temps de blocage réel du code. Une fois les problèmes résolus, ces bibliothèques peuvent facilement être ajoutées à la phase différée et être chargées plus tôt.

Dans l’idéal, vos scripts ne comportent pas de temps de blocage, ce qui est parfois difficile à réaliser, car les technologies couramment utilisées, telles que les gestionnaires de balises ou l’outil de création, créent des fichiers JavaScript volumineux qui se bloquent lorsque le navigateur les analyse. Du point de vue des performances, il est conseillé de supprimer ces techniques, de s’assurer que vos scripts ne sont pas bloquants et de les charger individuellement en tant que fichiers plus petits et distincts.

En-tête et pied de page

L’en-tête, et plus précisément le pied de page, ne se trouvent pas dans le chemin critique vers le LCP. C’est pourquoi ils sont chargés de manière asynchrone dans leurs blocs respectifs. En règle générale, les ressources qui ne partagent pas le même cycle de vie (c’est-à-dire qui sont mises à jour avec des modifications de création à différents moments) doivent être conservées dans des documents distincts pour rendre la chaîne de mise en cache entre les origines et le navigateur plus simple et plus efficace. La séparation de ces ressources augmente les taux d’accès au cache et réduit l’invalidation du cache et la complexité de sa gestion.

Polices

Comme les polices web sollicitent souvent la bande passante et sont chargées à partir d’une autre origine via un service de polices tel que https://fonts.adobe.com ou https://fonts.google.com, il est dans la plupart des cas impossible de charger les polices avant le LCP. C’est pourquoi elles sont chargées juste après.

Par défaut, le modèle AEM Boilerplate implémente la technique font fallback pour éviter les CLS lors du chargement de la police. Il serait contre-productif de précharger les polices (via les indications précoces, h2-push ou le balisage) et d’avoir un impact important sur les performances.

Bonus : La vitesse est verte

La création de sites web rapides, petits et rapides à afficher n’est pas seulement une bonne idée pour offrir des expériences exceptionnelles qui convertissent mieux, c’est également un bon moyen de réduire les émissions de carbone.

Sources courantes des problèmes de performance

Au fil du temps, nous avons rassemblé un ensemble d’antimodèles qui ont un impact négatif sur les performances et qu’il faut éviter de respecter les bonnes pratiques de ce document.

Les indications précoces / h2-push / pré-connexion font partie du budget réseau

Instinctivement, il serait logique de demander au navigateur de télécharger autant de ressources que possible et aussi tôt que possible, avant même que le traitement des balises ne commence. Mais souvenez-vous que l’objectif ultime est d’avoir une page stable à montrer au visiteur le plus rapidement possible. LCP moment est un bon indicateur pour cela.

En règle générale, pour qu’un LCP puisse 100 sur Mobile avec PageSpeed Insight, les contraintes de réseau sont configurées de manière à ce qu’il ne puisse y avoir qu’un seul hôte avec une payload réseau ne dépassant pas 100 Ko, car la configuration est largement limitée en bande passante. Les indications précoces, h2-push et la pré-connexion consomment cette bande passante, en téléchargeant des ressources qui ne sont pas requises pour LCP et qui ont donc un impact négatif sur les performances, et doivent être supprimées.

Redirections pour la résolution des chemins

Si un visiteur demande www.domain.com et est redirigé vers www.domain.com/en, puis vers www.domain.com/en/home,, il reçoit une pénalité pour chaque redirection, ce qui a une incidence négative sur les performances. Cela est principalement visible dans les Core Web Vitals mesurés via RUM ou CrUX, car les résultats de laboratoire dans PageSpeed Insights excluent par défaut la surcharge de redirection du test en laboratoire.

Injection de scripts client CDN

Nos balises, mais également nos origines .aem.page et .aem.live, sont optimisées pour les performances. Nous faisons très attention à toute partie de la payload, ainsi qu’à la séquence de chargement des ressources.

Certains fournisseurs de réseau CDN et certaines configurations injectent des scripts qui consomment de la bande passante et créent du temps de blocage, avant que les LCP n’aient un impact négatif sur les performances. Ces scripts doivent être désactivés ou chargés de manière appropriée dans la séquence de chargement après LCP.

La comparaison d’une origine .aem.live du rapport d’informations PageSpeed avec le site correspondant précédé par un réseau CDN de clients (par exemple, site de production) montrera l’impact négatif produit par un réseau CDN en dehors du contrôle d’AEM.

Impact de l’ITF du réseau CDN et de l’implémentation du protocole

Selon le fournisseur du réseau CDN, il existe des différences dans les implémentations de protocole et les caractéristiques de performances pour la diffusion pure de la payload HTTP. Des outils supplémentaires tels que WAF et d’autres infrastructures réseau en amont d’AEM peuvent également avoir une incidence négative sur les performances.
La comparaison d’une origine .aem.live du rapport d’informations PageSpeed avec le site correspondant précédé par un réseau CDN de clients (par exemple, site de production) montrera l’impact négatif produit par un réseau CDN en dehors du contrôle d’AEM.