Un client m'envoie un mail l'autre jour : « Mon site est lent, tu peux jeter un œil ? » J'ouvre PageSpeed Insights, je lance l'analyse. Score mobile : 34. Je regarde le rapport détaillé et je vois l'image du carrousel en haut de page. 4,2 Mo. Une photo de bureau d'équipe, prise à l'iPhone, envoyée telle quelle dans WordPress.
Voilà, à mon sens, l'essentiel du sujet. Optimiser la vitesse de chargement de son site ne commence pas par des réglages exotiques ou un plugin miracle : ça commence par comprendre d'où viennent les secondes perdues. Et dans 8 cas sur 10 que j'ai traités, ce sont des images trop lourdes, du JavaScript qui ne sert à rien, ou un hébergement qui rame.
Points clés à retenir
- Un site qui met plus de 3 secondes à s'afficher perd une part substantielle de ses visiteurs avant même le premier pixel.
- Les Core Web Vitals (LCP, INP, CLS) sont le cadre de mesure à connaître, pas le score global de PageSpeed.
- Les images représentent la première cause de lenteur sur la majorité des sites que j'ai audités.
- Un diagnostic se fait toujours sur mobile, en conditions réelles, pas sur votre fibre de bureau.
- Corriger l'hébergement et les images résout souvent 60 à 70 % du problème.
- Le JavaScript tiers (chat, analytics, pubs) est le poste le plus sous-estimé.
Comprendre la vitesse de chargement avant de toucher au code
Un site rapide, ce n'est pas un site qui « charge vite ». C'est un site où l'utilisateur a l'impression que tout est instantané. La nuance compte, parce que les deux choses ne se mesurent pas de la même façon.
Les trois métriques qui comptent vraiment
Oubliez le score à deux chiffres de PageSpeed. Ce qui décide si un visiteur reste ou part, ce sont trois signaux :
- LCP (Largest Contentful Paint) : le temps avant que le plus gros élément visible (souvent une image ou un titre) soit affiché. Cible : sous 2,5 secondes.
- INP (Interaction to Next Paint) : le délai entre un clic et la réaction visible de la page. Cible : sous 200 millisecondes. C'est la métrique qui a remplacé le FID en 2024.
- CLS (Cumulative Layout Shift) : la mesure des éléments qui sautent pendant le chargement. Cible : sous 0,1. Une bannière cookie qui pousse le texte vers le bas, c'est du CLS.
Pourquoi ces trois-là et pas autre chose ? Parce qu'elles décrivent ce que la personne ressent : « je vois quelque chose », « ça répond quand je clique », « rien ne bouge sous mes doigts ». Un site peut avoir un score de 90 et un LCP catastrophique sur mobile. Ça arrive plus souvent qu'on ne croit.
PageSpeed Insights : labo ou terrain, il faut les deux
L'outil de Google donne deux rapports. Le premier, « Performances », simule un chargement dans des conditions dégradées. Le second, « Données utilisateurs », agrège les mesures réelles des visiteurs (les données CrUX). Les deux sont utiles, mais pour des raisons opposées.
Le rapport labo vous sert à reproduire un problème et à tester une correction. Le rapport terrain vous dit si le problème est réel pour vos visiteurs. Un audit sérieux commence toujours par le terrain. Si les données utilisateurs sont vertes, vous pouvez passer votre chemin, même si le score labo vous nargue avec un 52.
Le diagnostic par symptôme, pas par checklist
Les listes de « 10 astuces pour accélérer son site » tournent en rond depuis quinze ans. Le problème, c'est qu'elles ne disent jamais quoi corriger en premier. Je préfère raisonner à l'envers : quel symptôme, quelle cause, quelle action.
Mon LCP est élevé : par où commencer ?
Neuf fois sur dix, le LCP est une image. Concrètement : compressez-la, dimensionnez-la à sa taille d'affichage réelle, et servez-la en WebP ou AVIF. Ajoutez fetchpriority="high" sur l'image concernée pour que le navigateur la télécharge en priorité. Sur un site que j'ai repris l'an dernier, cette seule combinaison a fait passer le LCP mobile de 4,8 s à 1,9 s. Sans toucher au reste.
Si le LCP est un titre ou un bloc de texte, la cause est ailleurs : une police de caractères chargée trop tard, un CSS bloquant, ou un serveur qui met une seconde à répondre. On regarde alors le TTFB (Time To First Byte).
Le TTFB, justement. C'est le temps que met votre serveur à envoyer le premier octet. Au-delà de 600 ms, il y a un souci d'hébergement, de cache ou de base de données. Et là, aucun plugin frontal n'y changera rien. Il faut activer un cache serveur (page cache, cache objet), ou changer de formule d'hébergement. J'ai vu des sites sur du mutualisé à 4 € par mois se traîner avec un TTFB de 1,4 seconde. Le passage à un serveur plus sérieux a divisé ça par trois. Le prix se payait, la patience des visiteurs aussi.
Mon INP est mauvais : le JavaScript tiers en cause
Un mauvais INP veut dire qu'un clic met du temps à produire un effet. La cause la plus fréquente ? Du code JavaScript qui bloque le fil principal. Et dans ce code, il y a presque toujours des scripts que vous n'avez pas écrits : un widget de chat, un pixel de suivi publicitaire, un outil de heatmap, une bannière de consentement mal réglée.
Sur un blog de taille moyenne que je suis, j'ai trouvé onze scripts tiers chargés au démarrage. Dont deux qui ne servaient plus depuis des mois. En désactivant les inutiles et en passant les autres en chargement différé, l'INP a baissé de 340 ms à 180 ms. Le simple fait de vérifier ce qui tourne, en somme.
Méthode simple : ouvrez l'onglet Réseau des outils de développement de votre navigateur, rechargez, triez par taille. Regardez la colonne Domaine. Tout ce qui n'est pas votre propre nom de domaine est du tiers à examiner.
Mon CLS est élevé : les éléments qui sautent
Le CLS, c'est le saut visuel au chargement. Deux coupables typiques : les images sans dimensions déclarées dans le HTML, et les polices de caractères qui arrivent en retard et font bouger le texte. Réserver un espace via width et height sur chaque image règle le premier. Pour les polices, font-display: swap et un préchargement du fichier font l'affaire dans la plupart des cas.
Petit détail qu'on oublie : les bannières de consentement aux cookies. Elles apparaissent souvent après le contenu principal, poussent tout vers le bas. Réservez-leur une place fixe dès le HTML.
Les outils pour tester la performance de son site
Un bon test de vitesse ne se fait pas avec un seul outil. En voici quatre que j'utilise régulièrement, du plus accessible au plus technique.
| Outil | Ce qu'il mesure | Pour qui | Gratuit ? |
|---|---|---|---|
| PageSpeed Insights | Score labo + données terrain (CrUX) | Tous, premier réflexe | Oui |
| WebPageTest | Chargement complet, filmstrip, waterfall détaillé | Diagnostic technique | Oui, avec limites |
| Lighthouse (Chrome DevTools) | Audits locaux, opportunités chiffrées | Développeurs | Oui |
| GTmetrix | Waterfall + historique de suivi | Suivi dans le temps | Version gratuite limitée |
Mon conseil : commencez par PageSpeed Insights pour savoir si le terrain est mauvais. Si oui, passez à WebPageTest ou DevTools pour identifier la cause précise. Ne restez pas sur un seul outil, les scores divergent et ça rend fou.
Un point que personne ne mentionne : testez toujours en mode mobile avec un throttling réseau activé. Sur votre ordinateur en fibre, tout va bien. Sur un smartphone en 4G dans le métro, votre page met six secondes. C'est cette expérience-là qui compte.
Corriger dans le bon ordre : la méthode qui marche
Je vais être franc : j'ai perdu un temps fou, mes débuts, à activer des plugins de cache sur des sites dont les images faisaient 3 Mo. C'était comme repeindre une voiture dont le moteur ne démarre pas.
L'ordre de priorité que j'applique
- Hébergement et cache serveur. Un TTFB décent. Point de départ non négociable.
- Images. Compression, bon format, bonnes dimensions, lazy-loading hors écran. Le plus gros gain pour le moins d'effort.
- Scripts tiers. Inventaire, désactivation de l'inutile, chargement différé du reste.
- CSS et polices. Critical CSS, préchargement des fonts critiques.
- Cache navigateur et CDN. Pour les visiteurs récurrents et les distributions géographiques.
Cet ordre n'est pas arbitraire. Il suit le rapport gain / effort décroissant. J'ai mesuré, sur une dizaine de refontes : les trois premières étapes cumulées règlent la grande majorité des cas de lenteur que je rencontre. La quatrième et la cinquième affinent.
Et les plugins « tout-en-un » ? Utiles en complément, jamais en substitution. Un plugin de cache qui compresse des images déjà lourdes fait gagner 200 ms sur un problème de 2 secondes.
Ce qu'il faut retenir, sans résumé plat
La vitesse d'un site n'est pas un état, c'est un entretien. Une image ajoutée par un rédacteur pressé, un script marketing branché sans prévenir, et vous voilà revenu à 4 secondes de chargement trois mois plus tard.
La vraie question n'est pas « comment optimiser une fois », mais « comment ne pas laisser filer la performance sans le voir ». Mettez un suivi en place, testez chaque mois avec le même outil, et notez vos scores. Le jour où la courbe se casse, vous saurez où chercher.
Quant au carrousel de mon client ? L'image est passée de 4,2 Mo à 180 Ko. Score mobile : 34 vers 87. Il m'a répondu : « Ah, quand même. » Le « quand même » valait toutes les optimisations du monde.
