Vitesse et Core Web Vitals
Je corrige la cause d’un site lent. Pas le symptôme.
La plupart des missions de vitesse se résument à un plugin de cache, un minificateur et un nouveau test plein d’espoir. Cela fait bouger le score de laboratoire et laisse le vrai problème en place. Je mesure où passe réellement le temps, je corrige ces points, et je vous remets un avant/après que vous pouvez reproduire sur votre propre machine.
01DémonstrationEn direct depuis votre navigateur
Cette page, mesurée pendant que vous la lisez.
N’importe qui vendant de l’optimisation peut vous montrer la capture d’un bon test. Voici les chiffres que votre propre navigateur a enregistrés en chargeant cette page, comparés aux seuils utilisés par Google. Ouvrez l’onglet Réseau et vérifiez-les.
Balisage, styles, script et trois polices : tout ce qu’il faut pour afficher ce que vous lisez.
Le poids médian d’une page web selon le HTTP Archive.
02DiagnosticOù passe vraiment le temps
La lenteur est un symptôme. Voici les causes.
Presque tous les sites lents qu’on m’envoie le sont pour deux ou trois des raisons suivantes. Le diagnostic sert à savoir lesquelles, car la correction de chacune est complètement différente, et acheter la mauvaise correction, c’est ainsi qu’on finit par payer deux fois pour de l’optimisation.
Le serveur réfléchit trop longtemps
Un Time to First Byte élevé signifie que le travail se fait avant qu’un seul octet n’atteigne le navigateur. Sur WordPress, ce sont souvent des requêtes non mises en cache dans une boucle de gabarit, une table d’options en autoload qui a grossi jusqu’à plusieurs mégaoctets, ou un plugin qui appelle une API externe pendant l’affichage de la page. Aucune optimisation front-end ne touche à cela.
Le plus grand élément à l’écran est énorme
Une image principale exportée à 4000 pixels de large et servie en PNG fait échouer le Largest Contentful Paint à elle seule. La solution n’a rien de glorieux : des dimensions correctes, des formats modernes, un srcset pour que les téléphones ne téléchargent pas la version bureau, une largeur et une hauteur explicites, et fetchpriority sur la seule image qui compte.
Des scripts bloquent l’affichage
Chaque script synchrone dans le head est un panneau stop avant que le navigateur puisse dessiner. Gestionnaires de balises, widgets de chat, outils de tests A/B et chargeurs de polices sont les suspects habituels, et ils sont souvent chargés sur toutes les pages pour une fonctionnalité utilisée sur une seule.
La page bouge pendant le chargement
Le Cumulative Layout Shift vient d’éléments qui arrivent tard sans espace réservé : images sans dimensions, polices web qui changent de taille, bannières de cookies et publicités insérées au-dessus du contenu existant. C’est généralement le moins cher des trois à corriger et le plus agaçant à subir.
Les interactions semblent collantes
Interaction to Next Paint a remplacé First Input Delay en mars 2024, et c’est une métrique bien plus exigeante. Elle mesure le temps qu’une interaction met à produire une réponse visible, sur toute la visite, pas seulement la première. Les sites échouent parce que trop de JavaScript se dispute le thread principal.
03MéthodeVraiment une séquence
Comment se déroule le travail.
- 01
Le diagnostic, avant tout devis
- J’analyse le site et je vous envoie par écrit où passe le temps, classé selon ce que cela vous coûte et la difficulté de la correction. Ce document vous reste, que vous m’engagiez ou non.
- 02
Une référence en données terrain
- Les scores de laboratoire varient d’un test à l’autre. J’enregistre d’abord les données terrain du Chrome UX Report, pour qu’à la fin nous comparions ce qu’ont vécu les vrais visiteurs, et non deux tests faits à des jours différents.
- 03
Corriger les causes, les plus grosses d’abord
- Le travail se fait en préproduction, un changement à la fois, chacun mesuré séparément. Regrouper dix changements ne vous apprend rien sur celui qui a fonctionné, et vous empêche d’annuler celui qui a nui.
- 04
Vérifier, puis vous transmettre la méthode
- Vous recevez l’avant et l’après, les étapes pour reproduire les deux, et une note sur ce qui défera peu à peu le travail : en général, le prochain plugin que quelqu’un installera.
04QuestionsPosées souvent, réponses franches
Ce qu’on me demande avant de m’engager.
Un plugin de cache va-t-il régler mes Core Web Vitals ?
En partie, au mieux. Le cache améliore le temps de réponse du serveur, ce qui aide le Time to First Byte. Il fait très peu pour un Largest Contentful Paint causé par une image principale trop lourde, rien pour un décalage de mise en page dû à des éléments sans dimensions, et rien pour un Interaction to Next Paint dû à un JavaScript trop lourd. La plupart des sites m’arrivent avec un plugin de cache déjà installé et échouent quand même.
Pourquoi mon score PageSpeed Insights change-t-il sans arrêt ?
Le grand chiffre en haut est un test de laboratoire sur un appareil lent simulé, et il varie d’un test à l’autre. La section du dessous, les données terrain du Chrome UX Report, est ce que Google utilise réellement : une moyenne glissante sur 28 jours de vrais visiteurs. Suivez les données terrain et ignorez les petites variations du score de laboratoire.
Combien de temps avant que l’amélioration se voie dans Google ?
Comme les données terrain sont une fenêtre glissante de 28 jours, comptez environ quatre semaines pour que le changement soit entièrement pris en compte, et davantage sur les sites à faible trafic qui mettent du temps à réunir assez d’échantillons. Quiconque promet un changement de classement immédiat parle du score de laboratoire, pas de celui qui compte.
Quelle amélioration pouvez-vous promettre ?
Aucune avant d’avoir regardé, et c’est pourquoi le diagnostic passe avant le devis. Un site chargé de plugins avec une image principale non optimisée a beaucoup de marge facile. Un site déjà léger côté front-end mais lent dans la base de données, c’est un autre travail, à un autre prix. Je préfère vous donner un vrai chiffre après une heure d’analyse qu’un chiffre impressionnant tout de suite.
Dois-je refaire le site ?
En général, non. La plupart des problèmes de vitesse viennent d’une poignée de causes précises plutôt que d’un défaut de fond, et les corriger coûte bien moins cher qu’une refonte. Si je pense que vous avez atteint le plafond de ce que le site actuel peut faire, je vous le dirai, mais c’est l’exception, et vous n’avez pas intérêt à ce que je commence par là.
Qu’est-ce que l’INP, et a-t-il remplacé le FID ?
Interaction to Next Paint a remplacé First Input Delay comme Core Web Vital en mars 2024. Le FID ne mesurait que le délai avant que le navigateur commence à traiter votre première interaction. L’INP mesure le temps que met toute l’interaction à produire une réponse visible, sur l’ensemble de la visite. Il est nettement plus difficile à réussir, et on l’échoue généralement pour une raison : trop de JavaScript sur le thread principal.
Mon site était rapide et il est devenu lent. Qu’est-ce qui a changé ?
D’après mon expérience, presque toujours l’une de trois choses : un plugin ou un script de suivi ajouté depuis, une équipe éditoriale qui téléverse des images en pleine résolution directement depuis l’appareil photo, ou une base de données qui a grossi en silence (révisions d’articles, transients expirés, table d’options en autoload). Les trois sont peu coûteuses à corriger une fois identifiées.
Prochaine étape
Envoyez-moi l’URL. Je vous dirai ce qui ne va pas.
La première chose que vous recevez est un diagnostic écrit qui vous reste dans tous les cas. Si la réponse honnête est que votre site va déjà bien, c’est ce que dira le document.