Les fameux Core Web Vitals !
Depuis quelques temps, Google a changé les algorithmes de calcul de performance en passant à la version « Insights ».
Et bim !, ça a dégringolé. En masse.
Sur ce site, la perte en mobile est de l'ordre de 9 points sur un échantillon de 10 pages, tracé sur plusieurs mois. Comme on me l'a dit, passer de presque 99 à 89 ou 90, ça reste un problème de riche. Oui, mais ça a l'avantage de pousser à vouloir faire encore mieux.
Histoire de s'amuser, j'ai demandé ceci à Google Gemini.
Voici deux rapports Pagespeed Insights
Page 1 et Page 2
Sachant que ce sont deux pages totalement identiques, peux-tu m'expliquer pourquoi les FCP et LCP sont aussi différents ?
Pour info, les scores sont les suivants en mobile :
- Page photographie-page-1.html : FCP 1.4s, LCP 2.8s.
Score global à 96, FCP est donc au vert, LCP au rouge (>2.5). - Page photographie.html : FCP 1.8s, LCP 2.3s.
Score global à 97, FCP est donc au rouge (> 1.5), LCP au vert.
En mode graphique, ça donne ça.
-
Page photographie-page-1.html -
Page photographie.html
Et voici sa réponse.
C'est une excellente question qui met en lumière la variabilité et la complexité des tests de performance effectués par Google PageSpeed Insights (PSI), même sur des URL apparemment identiques.
Bien que les deux pages photographie-page-1.html et photographie.html soient structurellement les mêmes, leurs métriques de laboratoire (FCP et LCP) sont significativement différentes.
Voici les raisons principales expliquant cet écart, malgré l'identité du code :
La Variabilité du Test
Ou le « Bruit du Laboratoire ».
Les scores de laboratoire (ceux générés par Lighthouse) sont des simulations et sont sujets au "bruit" :
- Ressources Serveur Temporaires : Même si le contenu est mis en cache, des variations minimes dans la rapidité de la réponse du serveur (Time to First Byte - TTFB), le temps de traitement de la requête par le serveur de Google, ou la disponibilité des ressources CDN peuvent survenir entre deux exécutions. Une petite latence supplémentaire sur la première requête peut ralentir l'intégralité de la chaîne de rendu.
- Problèmes de Réseau Éphémères : La simulation de réseau dans le centre de données de Google n'est pas parfaite. Des micro-ralentissements sur le réseau qui simule la 4G lente peuvent affecter le chargement des ressources critiques, notamment le CSS ou les polices, qui sont essentiels au FCP (First Contentful Paint).
- Bruit du CPU : L'environnement d'exécution de Lighthouse est un conteneur partagé. La charge des autres processus ou l'allocation du CPU à l'instance de test peuvent varier légèrement, impactant la vitesse à laquelle le navigateur simulé exécute le JavaScript et rend le DOM, ce qui affecte directement le LCP (Largest Contentful Paint).
Le Phénomène de Mise en Cache du Serveur
CDN/Cache Edge.
Le facteur le plus courant est lié aux couches de mise en cache qui existent avant votre serveur d'origine (comme un CDN ou un cache Varnish/Nginx Edge).
- Statut du Cache :
- Test 1 (Lent) : La première URL a pu être testée immédiatement après l'expiration de son cache (état MISS). Le serveur a dû régénérer la page, ou le CDN a dû télécharger le contenu depuis l'origine, ce qui ajoute un délai au TTFB et, par conséquent, au FCP/LCP.
- Test 2 (Rapide) : La deuxième URL a pu bénéficier d'un cache HIT (le contenu était déjà disponible en mémoire ou sur le CDN Edge), ce qui a permis de servir la page beaucoup plus rapidement.
Bien que les pages soient identiques, si leur URL est différente, elles ont un cache séparé. Si une URL n'a pas été demandée récemment, elle est plus susceptible de subir un cache MISS.
Détection du LCP et FCP
Mécanismes Spécifiques.
Le FCP et le LCP sont sensibles à la séquence exacte du rendu des pixels.
- FCP (Rendu Initial) : Le FCP est le moment où le premier élément du DOM ou du CSS est rendu. Si la première URL a eu un délai (même de quelques centaines de millisecondes) sur le premier octet de réponse, son FCP sera inévitablement plus élevé.
- LCP (Rendu du Plus Grand Élément) : Le LCP mesure le rendu du plus grand bloc de texte ou image visible. Si le navigateur simulé, lors du test de la première URL, a dû attendre un script ou une police critique pendant un court instant, cela peut avoir déplacé le LCP significativement plus tard, même si le code est identique.
Conclusion : La différence de performance observée est presque certainement due à des fluctuations transitoires au niveau du réseau ou du cache du serveur/CDN, plutôt qu'à une différence dans le code source de la page elle-même. Pour obtenir une lecture plus fiable, il est toujours recommandé d'exécuter l'audit PSI plusieurs fois pour chaque URL et de comparer les scores moyens.
Analyse…
Pourquoi il ne faut pas prendre au pied de la lettre ces fameux résultats ?
Regardons d'abord les conditions du test réalisés en mobile, la question est moindre en desktop.
Conditions du test fournies par l'application :
- Navigateur : User-agent "Mozilla/5.0 (Linux; Android 11; moto g power (2022)) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/137.0.0.0 Mobile Safari/537.36"
- Émulation du Moto G Power, puissance du processeur/de la mémoire non limitée: 438 Limitation du processeur: 1,2x slowdown (Simulated) Émulation de l'écran: 412x823, DPR 1.75 Version d'axe: 4.11.0
- Connexion 4G lente : Limitation de bande passante réseau: 150 ms TCP RTT, 1 638,4 kbit/s throughput (Simulated) Position du navigateur : Europe
- Session avec consultation d'une seule page : Ces données proviennent d'une session avec consultation d'une seule page, contrairement aux données de champ qui résument plusieurs sessions.
- Chargement de page initial
Le device simulé : on ne peut pas dire qu'on soit dans le haut de gamme ! Certes, ça garantit la prise en compte d'utilisateurs ne disposant pas d'un terminal de compétition. Il n'est pas interdit de penser que dans la vraie vie, la perception réelle sera bien différente.
Concernant la connexion, même combat. Partir d'une connexion 4G lente, on vise le bas, et selon la zone géographique et le service proposé, la cible réelle est limitée. À l'heure de la 5G, on est plus souvent sur cette bande passante ou de la 4G rapide, voir du wifi.
La session avec consultation d'une seule page et chargement initial abolit l'ancienne version de Lighthouse qui faisait une moyenne de 3 revues de la même page, prenant donc en compte la mise en cache client pour les ressources statiques. Si tant est que c'était bien géré…
En bref, avoir un « score » est une chose, mais rien ne remplacera jamais la véritable expérience de l'utilisateur.
Ça ne veut bien évidemment pas dire qu'il ne faille pas en tenir compte, non plus. C'est un excellent outil pour dénicher les optimisations nécessaires, voir supprimer les APIs tierces que l'on trouve à foison, trop souvent par effet de mode, et qui sont la plupart du temps inutiles. Où pour lesquelles il y a des alternatives.
C'est un peu comme la nourriture : le « fait maison » est bien meilleur que les plats industriels préparés…
Sur ce, je retourne méditer.