LCP : le temps d’affichage de ce qui compte
Le LCP mesure le moment où le plus grand élément visible — souvent une image de tête ou un titre — est affiché. Sous 2,5 secondes, c’est bon ; au-delà de 4, c’est mauvais. Les causes habituelles : un serveur lent à répondre, une image de tête trop lourde ou chargée trop tard, des feuilles de style et des polices qui bloquent l’affichage, des scripts tiers chargés avant le contenu. Les corrections : un hébergement réactif, une image de tête servie à la bonne taille en format moderne et chargée en priorité, des polices hébergées sur le site, des scripts déplacés après le contenu.
INP : la réactivité quand on touche l’écran
L’INP mesure le délai entre une interaction — un tap, un clic, une frappe — et la réponse visible de la page, sur l’ensemble de la visite. Sous 200 millisecondes, c’est bon ; au-delà de 500, c’est mauvais. Les causes : des scripts lourds qui occupent le processeur du téléphone — constructeurs de pages, outils de mesure, chats, carrousels —, des menus et des formulaires qui attendent un script pour fonctionner. Les corrections : moins de script, du script chargé après l’interaction, des interactions qui fonctionnent sans script — un menu, un lien, un formulaire n’en ont pas besoin.
CLS : ce qui saute pendant le chargement
Le CLS mesure les déplacements de contenu pendant le chargement : un bouton qui descend parce qu’une image apparaît au-dessus, un texte qui se décale quand la police arrive, un bandeau qui pousse la page. Sous 0,1, c’est bon ; au-delà de 0,25, c’est mauvais. Les causes : des images sans dimensions déclarées, des polices qui remplacent une police de secours de taille différente, des bandeaux et des publicités injectés après coup. Les corrections : déclarer la taille de chaque image et vidéo, réserver l’espace des éléments qui arrivent tard, choisir une police de secours proche.
Mesurer : les outils gratuits
L’outil de mesure de vitesse de Google — PageSpeed Insights — donne pour une adresse les trois mesures en conditions réelles, si le site a assez de trafic, et une simulation sinon, avec les causes et les corrections. La Search Console, rubrique « Signaux web essentiels », donne l’état de toutes les pages du site, groupées par problème. Le navigateur, en mode développeur, permet de reproduire une visite sur un téléphone lent. Mesurez sur mobile : c’est là que Google mesure, et là que les scores sont mauvais.
Pourquoi mesurer sur mobile, et en conditions réelles
Google mesure les Core Web Vitals sur les visites réelles de vos visiteurs, majoritairement sur téléphone, souvent en 4G, avec des appareils de puissance moyenne. Un site qui paraît rapide sur l’ordinateur d’un développeur peut être lent pour un client dans la rue. La simulation de l’outil de Google donne une indication ; les données réelles de la Search Console — disponibles quand le site a assez de trafic — font foi. C’est sur elles que Google classe.
Les seuils, et ce que « bon » veut dire
Google classe chaque mesure en bon, à améliorer ou mauvais, sur le 75e percentile des visites réelles : trois visiteurs sur quatre doivent avoir une bonne expérience. Un site « bon » sur les trois mesures a un léger avantage de classement, et surtout un taux de conversion meilleur — un site lent perd des visiteurs avant même qu’ils lisent. Les sites construits par l’agence visent des valeurs bien en dessous des seuils : moins de deux secondes, moins de cent millisecondes, un déplacement quasi nul ; ce site en est un exemple mesurable.
Les corrections qui rapportent le plus, dans l’ordre
Les images : servies à la taille de l’écran, en format moderne, avec des dimensions déclarées, chargées à la demande sauf celle de tête — c’est souvent la moitié du gain. Les scripts tiers : chaque outil de mesure, de chat, de carte ou de réseau social chargé sur toutes les pages coûte ; les retirer ou les charger à la demande. Les polices : deux fichiers maximum, hébergés sur le site, avec une police de secours proche. Le serveur : un temps de réponse sous deux cents millisecondes, avec un cache. Le code : un thème ou un site léger, sans constructeur de pages. Dans cet ordre, parce que c’est l’ordre de l’effort par rapport au gain.
Les cas où il faut refaire plutôt que corriger
Un site sur un template lourd avec un constructeur de pages, une boutique avec trente extensions, un site à plusieurs mégaoctets par page : les corrections gagnent un peu et plafonnent vite, parce que la cause est structurelle. L’audit dit quand la refonte coûte moins que l’accumulation de corrections. Un site statique bien construit obtient les trois mesures en bon sans effort particulier ; c’est un argument de plus pour ce choix technique.
Ce que l’agence observe sur ses projets
Les sites repris en audit arrivent avec un LCP de trois à six secondes sur mobile, un INP dégradé par les scripts, et un CLS causé par les images sans dimensions. Après reconstruction, les trois mesures passent en bon avec une marge large.