Performances web, score de 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. Avec la variable Surveillance d’utilisation réelle (RUM) collecte de données d’opérations, les informations sont continuellement collectées à partir de l’utilisation sur le terrain et permettent d’itérer sur les mesures de performances d’utilisation réelle sans avoir à attendre que les données CRuX montrent les effets des changements de code et de déploiement. Il est courant que les données de terrain collectées dans RUM diffèrent des résultats de laboratoire, car le réseau, la géolocalisation et la puissance de traitement pour les appareils réels sont beaucoup plus variés que les conditions simulées dans un laboratoire.

La variable Service Google PageSpeed Insight est 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 démarrez votre projet avec le modèle standard, comme dans la variable Tutoriel du développeur, vous obtiendrez un score Lighthouse très stable sur PageSpeed Insight pour Mobile et bureau à l’adresse 100. Sur chaque composant du score de Lighthouse, il y a un tampon pour que le code du projet soit utilisé et reste dans les limites d’une balise parfaite. 100 score de phare.

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 conserver à 100 si vous 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 par rapport à . Le robot GitHub AEM échoue automatiquement votre requête de tirage si le score est inférieur à 100 avec un peu de tampon pour expliquer une certaine volatilité des résultats.

Les résultats correspondent au score du phare mobile, car ils ont tendance à être plus difficiles à obtenir que le poste de travail.

Pourquoi 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 configurées dans le cadre de leurs pratiques de surveillance continue et de reporting de performances.

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

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

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

Toutefois, il est important de se rappeler que les recommandations que vous obtenez de PageSpeed Insights ne mènent pas nécessairement à de meilleurs résultats, en particulier plus vous approchez d’un score de phare de 100.

Les principales valeurs de Web (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 les changements mineurs, la variance des résultats et le manque de points de données (trafic) suffisants sur une courte période rendent impossible l’obtention de résultats statistiquement pertinents dans la plupart des cas.

Chargement en trois phases (E-L-D)

Disséquer la payload d’une page web en trois phases rend relativement simple l’obtention d’un score de phare propre et, par conséquent, la définition d’une ligne de base pour une expérience client optimale.

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

Phase E : impatiente

Dans le impatient phase, tout ce qui doit être chargé pour la valeur LCP à afficher est chargé. Dans un projet, il s’agit généralement des balises, des styles CSS et des fichiers JavaScript.

Dans de nombreux cas, la variable LCP élément est contenu dans un bloc (souvent créé par un blocage automatique), où le bloc .js et .css doit également être chargé.

Le chargeur de blocs démasque progressivement les sections, ce qui signifie que tous les blocs de la première section doivent être chargés pour l’événement LCP pour devenir visible. C’est pourquoi il peut s’avérer judicieux d’avoir une section plus petite contenant le moins possible en haut d’une page.

Il est préférable, en règle générale, de conserver la charge utile agrégée avant l’événement LCP s’affiche en dessous de 100 Ko, ce qui génère généralement une LCP plus rapide que 1 560 ms (LCP score à 100 (PSI). Surtout sur mobile, le réseau a tendance à être limité par la bande passante, ce qui modifie la séquence de chargement avant LCP a un impact minimal, voire nul.

Chargement ou connexion à une seconde origine avant le LCP est fortement déconseillé, car il est fortement déconseillé d’établir une deuxième connexion (TLS, DNS, etc.) ajoute un délai significatif à la variable LCP.

Phase L : azy

Dans le paresseux , la partie de la payload chargée n’affecte pas le temps de blocage total (TBT) et, en fin de compte, le premier délai d’entrée (FID).

Cela inclut des éléments tels que les blocs de chargement (JavaScript et CSS) et le chargement de toutes les images restantes en fonction de leur loading="lazy" et d’autres bibliothèques JavaScript qui ne bloquent pas. La phase paresseuse est généralement tout ce qui se passe dans les différentes blocks vous allez créer pour couvrir les besoins du projet.

Au cours de cette phase, il serait toujours conseillé que la majeure partie de la charge utile provienne de la même origine et soit contrôlée par le premier, de sorte que des modifications puissent être apportées si nécessaire pour éviter un impact négatif sur la variable TBT, TTI et FID.

Phase D : différée

Dans le delay , les parties de la payload sont chargées sans impact immédiat sur l’expérience et/ou ne sont pas contrôlées par le projet et proviennent de tiers. Pensez aux outils marketing, à la gestion des consentements, aux analyses étendues, aux modules de conversation/interaction, etc. qui sont souvent déployés par le biais des 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 différée doit être au moins trois secondes après l’événement LCP pour laisser suffisamment de temps pour que le reste de l’expérience soit réglé.

La phase différée est généralement gérée dans delayed.js qui sert de fourre-tout initial pour les scripts qui provoquent TBT. Idéalement, la variable TBT les problèmes sont supprimés des scripts en question soit en les chargeant en dehors du thread principal (dans un web worker), 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 de différé et chargées plus tôt.

Dans l’idéal, il n’y a pas de temps de blocage dans vos scripts, ce qui est parfois difficile à réaliser avec la technologie couramment utilisée comme les gestionnaires de balises ou les outils de génération pour créer des fichiers JavaScript volumineux qui sont bloqués lorsque le navigateur les analyse. Du point de vue des performances, il est conseillé de supprimer ces techniques, de vous assurer que vos scripts individuels ne se bloquent pas et de les charger individuellement sous la forme de fichiers plus petits séparés.

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 la balise 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 qu’elles sont mises à jour avec des modifications de création à différents moments) doivent être conservées dans des documents distincts afin de rendre la chaîne de mise en cache entre les origines et le navigateur plus simple et plus efficace. Le fait de séparer ces ressources augmente les taux d’accès au cache et réduit l’invalidation du cache et la complexité de la gestion du cache.

Polices

Comme les polices web sont souvent une pression sur la bande passante et chargées à partir d’une origine différente via un service de polices comme https://fonts.adobe.com ou https://fonts.google.com, il est pratiquement impossible de charger les polices avant l’événement LCP, c’est pourquoi ils sont généralement ajoutés au lazy-styles.css et sont chargés après l’événement LCP s’affiche.

Blocs LCP

Dans certains cas, la variable LCP 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 qui doit se produire dans une .json) pour la variable LCP élément .
Dans ce cas, il est important que le chargement de la page attende avec l’hypothèse LCP candidat (actuellement la première image de la page) jusqu’au premier bloc a apporté les modifications nécessaires au modèle DOM.
Pour identifier les blocs à attendre avant de bloquer pour la variable LCP Chargement, vous pouvez ajouter les blocs qui contiennent le LCP à l’élément LCP_BLOCKS tableau dans scripts.js.

Bonus : La vitesse est verte

Construire des sites web qui sont rapides, petits et rapides à rendre n'est pas seulement une bonne idée pour offrir des expériences exceptionnelles qui se convertissent mieux, c'est aussi un bon moyen de réduire les émissions de carbone.