Temps de chargement

Le temps de chargement d'une page ne se résume pas à un seul chiffre. Entre le clic et le moment où l'internaute peut lire et agir, plusieurs étapes se succèdent : la réponse du serveur, le premier affichage, l'apparition du contenu principal, puis la réaction de la page aux interactions. Chaque étape a sa mesure, et une page peut être rapide sur l'une et lente sur l'autre.

Les mesures à connaître

Google et l'équipe Chrome publient sur web.dev des seuils pour chacune de ces étapes. Trois d'entre elles forment les Core Web Vitals : le LCP, l'INP et le CLS. Les deux autres servent surtout au diagnostic.

Mesure	Ce qu'elle mesure	Bon résultat
TTFB	Délai avant le premier octet de la réponse, redirections, DNS, connexion et négociation TLS compris	0,8 s ou moins
FCP	Premier élément de contenu affiché	1,8 s ou moins
LCP	Affichage du plus grand élément visible : image, vidéo ou bloc de texte	2,5 s ou moins
INP	Délai de réaction aux clics, appuis et saisies	200 ms ou moins
CLS	Stabilité visuelle, mouvements inattendus de la mise en page	0,1 ou moins

L'INP a remplacé le FID dans les Core Web Vitals le 12 mars 2024. Le FID n'est donc plus la mesure de référence pour la réactivité d'une page.

Données de terrain et données de laboratoire

PageSpeed Insights affiche deux types de résultats qu'il faut distinguer. Les données de terrain proviennent du rapport CrUX de Chrome : ce sont les mesures de vrais visiteurs sur les 28 derniers jours. Les données de laboratoire viennent de Lighthouse, qui simule un chargement sur un appareil et un réseau fixes. Les premières disent ce que vivent les internautes ; les secondes aident à trouver la cause d'un problème.

Les valeurs de terrain se lisent au 75e centile, séparément sur mobile et sur ordinateur. Une page passe l'évaluation des Core Web Vitals quand 75 % des chargements au moins atteignent le seuil « bon » sur chacune des trois mesures. Le score de laboratoire sur 100, souvent mis en avant, sert au diagnostic : issu d'une seule simulation, il peut passer à côté de ce que vivent les visiteurs réels.

Le poids réel dans le classement

Google a annoncé en janvier 2018 que la vitesse deviendrait un facteur de classement sur mobile. Cette mise à jour, déployée le 9 juillet 2018, ne visait que les pages les plus lentes et une faible part des requêtes. Le même billet précisait qu'une page lente peut rester bien classée si son contenu est très pertinent.

Dans sa documentation sur l'expérience sur la page, Google indique que les Core Web Vitals sont utilisés par ses systèmes de classement, tout en déconseillant de viser un score parfait pour des raisons de SEO. La pertinence du contenu reste le premier critère. L'intérêt de la vitesse dépasse d'ailleurs le classement : une page qui tarde à s'afficher peut perdre des visiteurs avant même qu'ils aient lu une ligne, ce qui peut se refléter dans le taux de rebond.

Ce qui ralentit une page

Les causes reviennent souvent : un serveur lent ou trop loin des visiteurs, qui dégrade le TTFB, des images trop lourdes ou mal dimensionnées, qui retardent le LCP, des feuilles de style et des scripts qui bloquent l'affichage, des scripts tiers nombreux (publicité, mesure d'audience, widgets) qui occupent le navigateur et dégradent l'INP. Les décalages de mise en page viennent le plus souvent d'images, de publicités ou de bandeaux insérés sans espace réservé.

En pratique

La démarche la plus efficace part des données de terrain. Le rapport Core Web Vitals de la Google Search Console regroupe les URL similaires qui posent problème : comme les pages d'un même modèle partagent souvent le même défaut, corriger le modèle règle beaucoup d'URL à la fois. PageSpeed Insights sert ensuite à analyser un exemple de chaque groupe et à repérer l'élément LCP, les ressources bloquantes ou les scripts trop longs. Après une correction, il faut attendre que la fenêtre de 28 jours se renouvelle pour voir l'effet dans les données de terrain.