Vitesse du site en 2026 : Core Web Vitals, seuils officiels et notre cas avec le blog mobile
Le serveur répondait en 0,23 seconde, mais sur mobile les articles n’apparaissaient pas du tout. Voici les seuils officiels des Core Web Vitals, ce que dit Google de leur effet sur la recherche, et notre cas : visuels d’environ 2 Mo à 213 Ko et quoi vérifier.
Quels indicateurs de vitesse Google juge-t-il essentiels ?
Les Core Web Vitals sont trois indicateurs. LCP (chargement) : le plus grand élément doit s’afficher en 2,5 secondes ou moins. INP (réactivité) : la page doit réagir aux actions en 200 millisecondes ou moins. CLS (stabilité visuelle) : un décalage de mise en page de 0,1 ou moins. Ils se mesurent au 75e centile des chargements, séparément sur mobile et ordinateur, et une page ne réussit que si les trois sont bons. L’INP a remplacé le FID en 2024. Web.dev précise que les indicateurs stables ne changent pas plus d’une fois par an : les « nouveaux seuils 2026 » cités par certains blogs ne sont pas confirmés par Google.
La vitesse influence-t-elle le classement ?
Google indique que les Core Web Vitals, avec d’autres aspects de l’expérience sur la page, correspondent à ce que ses systèmes de classement cherchent à récompenser, et recommande vivement de bons résultats. Google ne donne pas de poids distinct à la vitesse : ce n’est pas un bouton magique, mais une condition parmi d’autres. Les données réelles des utilisateurs figurent dans le rapport Core Web Vitals de la Search Console.
Qu’avons-nous trouvé sur notre propre site ?
Le 11 novembre 2026, nous avons ouvert le blog Metriverra sur un téléphone, et les articles mettaient « très longtemps » à charger. Les mesures ont montré que le serveur répondait en 0,23 seconde : il n’était pas en cause. La liste de 19 articles formait un seul bloc avec une animation d’apparition déclenchée quand 12 % du bloc était visible. Sur mobile, le bloc mesurait 8 509 pixels de haut pour un écran de 844, soit 9,9 % : le seuil n’était jamais atteint et les articles restaient invisibles. En plus, les visuels étaient servis en taille réelle, environ 2 Mo par liste. Nous avons retiré l’animation de la liste, découpé en pages de 10 et 9 articles et servons des visuels réduits : 12 visuels pesaient 213 Ko au lieu d’environ 2 Mo.
Que vérifier sur votre site ?
Ouvrez le rapport Core Web Vitals de la Search Console et commencez par les pages mobiles. Testez les pages dans une vraie fenêtre mobile, pas seulement le temps de réponse du serveur : un contenu masqué jusqu’au déclenchement d’un script ne sera tout simplement pas vu. Servez des images adaptées à l’écran (srcset) et chargez en différé celles sous la ligne de flottaison, mais pas l’image principale. Réservez l’espace des images pour éviter les sauts de mise en page. Et rappelez-vous que les scripts et balises lourds dégradent la réactivité, donc l’INP.
Que faire maintenant
- Ouvrez le rapport Core Web Vitals de la Search Console et commencez par les URL mobiles.
- Testez les pages clés en fenêtre mobile : le contenu est-il visible sans attendre animations et scripts ?
- Servez des images adaptées à l’écran et des copies réduites pour les listes et cartes.
- Ne différez pas le chargement de l’image principale du premier écran, seulement celles en dessous.
- Contrôlez les indicateurs après chaque changement important du site, pas une fois par an.
Metriverra affiche chaque jour le comportement des visiteurs et les conversions : après un changement de vitesse, comparez rebonds et ventes avant et après.
En bref
- Seuils Google : LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 au 75e centile.
- Les indicateurs stables changent au plus une fois par an ; les « nouveaux seuils 2026 » ne sont pas confirmés.
- Google : les Core Web Vitals correspondent à ce que les systèmes de classement récompensent.
- Notre cas : serveur à 0,23 s, mais articles invisibles sur mobile à cause d’une animation.
- Visuels de la liste : ~2 Mo → 213 Ko.
Sources: web.dev — Web Vitals · Google Search Central — Understanding Core Web Vitals and Google search results
