Regarder les données réelles, pas seulement une note verte
Si Lighthouse affiche 95 mais que les gens disent que le site est lent, je ne fais pas confiance à une seule note verte. Je regarde d’abord de vrais groupes d’URL dans Search Console, puis je trouve le coupable dans PageSpeed et DevTools.
L’erreur que j’éliminerais d’abord : Mettre le lazy-load sur l’image hero.
Quoi préparer et quel résultat attendre
- Résultat : Vous savez quelle ressource ou quel script ralentit la page, et vous pouvez vérifier le correctif avec des données de terrain, pas seulement un test labo.
- Ouvrez Search Console → Core Web Vitals et séparez Mobile/Desktop. Pour l’URL problématique, lancez PageSpeed Insights.
- Gardez les données sources et les droits d’accès séparés du résultat pour pouvoir vérifier ce que le travail sur la vitesse et les Core Web Vitals a réellement fait.
- Cibles d’un bon résultat : LCP sous 2,5 s, INP sous 200 ms et CLS sous 0,1. Après le correctif, cliquez sur start validation dans Search Console.
Trouver le problème principal et le corriger un par un
- Trouver l’URL problématique
Dans Search Console, ouvrez le groupe de problèmes, puis l’URL précise. Collez-la dans PageSpeed Insights et voyez quel est l’élément LCP.
Проверьте: Il est clair ce que l’utilisateur attend le plus longtemps.
Если не сработало: Vérifiez la page dans Chrome DevTools Performance avec un profil mobile.
- Corriger le premier écran
Compressez l’image hero, définissez les dimensions et ne mettez pas le lazy-load sur le visuel principal. Différez les widgets secondaires et les scripts tiers.
<img src="/hero.webp" width="1200" height="700" fetchpriority="high" alt="Technicien réparant un climatiseur">Проверьте: Le visuel principal apparaît sans attendre de JS lourd.
Если не сработало: Remplacez la vidéo/animation par une première image statique pour le test.
- Supprimer les décalages et les long tasks
Définissez width/height pour les images et iframes, réservez de l’espace pour les bannières, réduisez le JavaScript lourd et découpez les long tasks.
Проверьте: Sur un écran mobile, les éléments ne sautent pas pendant le chargement.
Если не сработало: Désactivez les widgets tiers un par un et trouvez le coupable.
- Tester un scénario réel
Dans DevTools, activez un CPU lent et un réseau mobile, rechargez la page et enregistrez Performance. Comparez avant et après sur la même URL.
Проверьте: Le correctif a amélioré la métrique nécessaire, pas seulement le score global.
Если не сработало: Annulez le dernier changement et testez-le isolément.
Je corrige d’abord l’élément LCP
Cibles pour un bon résultat : LCP ≤ 2,5 s, INP < 200 ms, CLS < 0,1. Si le LCP est l’image hero, ne mettez pas `loading=lazy` : définissez les dimensions, un format moderne et `fetchpriority=high`. Les images sous le premier écran, en revanche, doivent se charger en lazy.
Pour le CLS, réservez de l’espace pour les images, la vidéo, les iframes, le chat et la bannière cookies. Pour l’INP, ouvrez DevTools → Performance et cherchez les long tasks : chats, cartes, sliders et plusieurs widgets d’analytics à la fois.
<img src="/assets/hero.avif" width="1440" height="900" fetchpriority="high" alt="Équipe travaillant sur un processus">Ne confondez pas le labo et les utilisateurs réels
Enregistrez l’URL, l’appareil, la source de données, le LCP, l’INP et le CLS avant le changement. Après le correctif, revérifiez PageSpeed et DevTools sur la même URL, puis attendez la mise à jour des données de terrain Search Console. Si vous ne corrigez que le score mais laissez un formulaire lent ou un bouton qui saute, l’utilisateur n’aura pas une meilleure expérience.
- Désactivez d’abord les widgets tiers un par un.
- Ne mettez pas le lazy-load sur le visuel principal.
- Ne traitez pas les données mobile et desktop comme une seule métrique.
Un test — un coupable
Désactivez d’abord un widget tiers, remesurez et enregistrez le résultat. Puis restaurez-le et vérifiez le suivant. Ne réécrivez pas tout le frontend d’un coup : sinon vous revenez à l’ancienne version sans connaître la cause.
Pour chaque groupe d’URL, stockez `metric`, `device`, `source`, `before`, `after`, `change`, `owner` et `date`. Si le problème principal est un hero lourd, optimisez-le ; s’il s’agit d’INP, réduisez le JavaScript. Ne corrigez pas le CLS en changeant une police si un emplacement publicitaire crée le décalage.
LCP, INP et CLS : quoi vérifier exactement
| Critère | Question | Bon signe |
|---|---|---|
| Entrée | Qu’est-ce qui entre exactement dans le travail sur la vitesse et les Core Web Vitals ? | Ouvrez Search Console → Core Web Vitals et séparez Mobile/Desktop. Pour l’URL problématique, lancez PageSpeed Insights. |
| Action | Que le système a-t-il le droit de faire seul ? | Uniquement les actions listées à l’avance, sans accès à tout le compte |
| Vérification | Comment savoir que le résultat peut être accepté ? | Cibles d’un bon résultat : LCP sous 2,5 s, INP sous 200 ms et CLS sous 0,1. Après le correctif, cliquez sur start validation dans Search Console. |
| Échec | Où va un cas peu clair ? | Comparez Field data et Lab data, puis corrigez la seule ressource la plus lourde ; ne changez pas CDN, police et tout le JavaScript d’un coup. |
Ce qui doit changer après la mise en place
Vous savez quelle ressource ou quel script ralentit la page, et vous pouvez vérifier le correctif avec des données de terrain, pas seulement un test labo.
Quelles accélérations nuisent par accident au premier écran
Mettre le lazy-load sur l’image hero.
Corriger seulement le score labo et ignorer les données réelles.
Oublier les dimensions des images et iframes.
Ajouter encore un widget alors que le premier écran est déjà surchargé.
Quand la vitesse exige un travail d’architecture
Vous avez besoin d’un spécialiste si les points lents impliquent le CMS, le rendu serveur, un gros bundle JS ou plusieurs systèmes externes.
Que vérifier après l’optimisation
Pourquoi PageSpeed et Search Console affichent des chiffres différents ?
PageSpeed combine un test labo avec les données de terrain disponibles, tandis que Search Console utilise des visites réelles agrégées sur une période.
Faut-il un score de 100 ?
Non. Une performance stable des pages clés et de bonnes métriques réelles sur les appareils des clients comptent davantage.
Que faut-il corriger en premier ?
Ce qui affecte le contenu principal et le premier écran, puis les décalages de mise en page et les longues tâches interactives.
Quand le résultat apparaîtra-t-il dans Search Console ?
Les données de terrain ne se mettent pas à jour instantanément. Un test labo vérifie le changement tout de suite, tandis que le rapport réel a besoin de nouvelles visites.
