L'indice de vitesse est-il vraiment la métrique clé de Google pour le mobile ?

Qu'est-ce que l'indice de vitesse dont parle Google ?

Le Speed Index mesure la rapidité avec laquelle le contenu visible se charge pendant le chargement d'une page. Contrairement au simple temps de chargement complet, il capture l'expérience visuelle perçue par l'utilisateur : une page peut techniquement finir de charger en 8 secondes, mais si 90% du contenu visible apparaît en 2 secondes, le Speed Index sera bas (donc bon).

Cette métrique a longtemps été un pilier de Lighthouse et PageSpeed Insights. Elle se calcule en millisecondes et représente l'évolution de la complétude visuelle dans le viewport au fil du temps. Un Speed Index de 3000 ms signifie qu'en moyenne, le contenu visible s'affiche complètement en 3 secondes.

Pourquoi cette déclaration pose-t-elle question aujourd'hui ?

Depuis mai 2021, Google a officiellement intégré les Core Web Vitals comme facteur de classement mobile : LCP (chargement), FID/INP (interactivité), CLS (stabilité visuelle). Le Speed Index n'a jamais été mentionné dans cette communication officielle sur les signaux d'expérience de page.

Pourtant, cette déclaration affirme que Google utilise principalement le Speed Index. Le mot est important : il suggère une priorisation, voire une exclusivité de cette métrique pour évaluer la vitesse mobile. Le seuil de 5000 ms indiqué ici est aussi beaucoup plus permissif que les recommandations Core Web Vitals (LCP sous 2500 ms pour être « bon »).

D'où vient ce seuil de 5000 millisecondes ?

Le chiffre de 5000 ms ne correspond à aucun standard publiquement documenté dans les guidelines Core Web Vitals. Les seuils officiels de Lighthouse classent le Speed Index comme « bon » en dessous de 3400 ms, « moyen » entre 3400 et 5800 ms, et « mauvais » au-delà.

Si Google fixe réellement un seuil interne à 5000 ms, cela impliquerait une tolérance supérieure à celle affichée dans ses propres outils d'audit publics. Soit cette déclaration est antérieure à la refonte des métriques, soit elle révèle un écart entre le discours public (CWV) et les critères réels de crawl/indexation mobile.

• Speed Index : métrique de perception visuelle, calcule la complétude progressive du viewport
• Seuil 5000 ms : plus permissif que les recommandations Lighthouse (3400 ms) et bien au-delà du LCP optimal (2500 ms)
• Contradiction apparente : aucune mention du Speed Index dans la communication officielle sur les Core Web Vitals depuis 2021
• Implication praticien : si ce seuil est encore appliqué, de nombreux sites classés « moyens » sur LCP pourraient techniquement passer la barre Google
• Datation probable : cette déclaration sent fortement l'ère pré-CWV, quand le Speed Index était encore LA métrique phare de Google pour le mobile

Cette déclaration est-elle encore d'actualité en pratique ?

Soyons honnêtes : tout indique que cette déclaration est obsolète. Depuis l'annonce officielle des Core Web Vitals comme facteur de classement mobile (Page Experience Update), Google n'a jamais repositionné le Speed Index comme métrique principale. Les outils officiels (Search Console, PageSpeed Insights) ne remontent que LCP, INP et CLS dans les rapports d'expérience.

Les tests terrain confirment que les sites qui améliorent leur LCP sans toucher au Speed Index constatent des gains de positionnement mobile. À l'inverse, un site avec un Speed Index excellent mais un LCP catastrophique ne bénéficie d'aucun avantage observable. Le marché a tranché : les CWV sont la réalité praticienne actuelle. [À vérifier] : Google pourrait-il encore utiliser le Speed Index comme signal secondaire en arrière-plan, sans jamais le documenter publiquement ?

Pourquoi Google aurait-il dit ça à l'époque ?

Le Speed Index était la métrique reine avant l'invention des Core Web Vitals. Il capturait mieux que le simple « temps de chargement » l'expérience visuelle réelle, surtout sur mobile où le rendu progressif compte énormément. Un site e-commerce qui affiche les produits en 2 secondes mais termine de charger en 8 secondes offre une meilleure UX qu'un site qui affiche tout d'un coup à 5 secondes.

Le seuil de 5000 ms était probablement un compromis pragmatique entre l'idéal (sites ultra-rapides) et la réalité du web mobile mondial (connexions lentes, JS lourd, images non optimisées). Google a toujours cherché à ne pas pénaliser massivement les sites qui font des efforts raisonnables.

Quelle métrique surveiller réellement aujourd'hui ?

La réponse est sans ambiguïté : concentrez-vous sur les Core Web Vitals. LCP (Largest Contentful Paint) mesure le chargement du plus gros élément visible, INP (Interaction to Next Paint) remplace FID pour évaluer la réactivité, et CLS (Cumulative Layout Shift) pénalise les sauts visuels intempestifs.

Le Speed Index reste une métrique complémentaire utile pour diagnostiquer les problèmes de rendu progressif, mais elle n'est plus un facteur de classement documenté. Si vous devez prioriser vos optimisations, visez un LCP sous 2500 ms et un INP sous 200 ms. Le Speed Index viendra naturellement si vous optimisez correctement le chemin critique de rendu.

Que faire si votre Speed Index dépasse 5000 ms ?

Même si cette métrique n'est probablement plus le critère principal, un Speed Index élevé signale souvent des problèmes structurels de performance qui affectent aussi vos Core Web Vitals. Un Speed Index supérieur à 5000 ms indique généralement un rendu bloqué, un JavaScript lourd exécuté trop tôt, ou des ressources critiques non prioritaires.

Concrètement, auditez votre chemin critique de rendu : identifiez les CSS et JS bloquants, différez ce qui n'est pas nécessaire au-dessus de la ligne de flottaison, et assurez-vous que le contenu principal se charge en priorité. Les mêmes optimisations qui abaissent le Speed Index amélioreront mécaniquement votre LCP.

Comment prioriser entre Speed Index et Core Web Vitals ?

La question ne devrait même pas se poser : priorisez les Core Web Vitals. C'est le seul signal d'expérience de page officiellement documenté et mesuré dans Search Console. Si vous travaillez encore avec des clients ou des outils qui mettent en avant le Speed Index comme métrique principale, recadrez la conversation.

Cela dit, si vous optimisez correctement pour le LCP, vous améliorerez de facto votre Speed Index. Les deux métriques partagent beaucoup de leviers communs : compression d'images, lazy loading intelligent, élimination des render-blocking resources, priorisation des ressources critiques. La différence, c'est que le LCP est plus simple à mesurer et à expliquer à un client non technique.

Quelles erreurs éviter en interprétant cette déclaration ?

Ne tombez pas dans le piège de croire qu'un seuil de 5000 ms vous donne de la marge pour relâcher vos efforts. Google a depuis considérablement durci ses exigences avec les Core Web Vitals. Un site qui se contente de frôler les 5000 ms de Speed Index aura probablement un LCP catastrophique (au-delà de 4 secondes), ce qui le placera dans la zone rouge.

Autre erreur classique : optimiser pour PageSpeed Insights sans vérifier les données terrain (CrUX). Le Speed Index est mesuré en labo sur Lighthouse, mais Google classe votre site selon les expériences utilisateurs réelles collectées via Chrome User Experience Report. Un site peut scorer 90/100 en labo et être pénalisé si 75% de ses visiteurs réels subissent un LCP supérieur à 4 secondes.

• Auditez vos Core Web Vitals dans Search Console (données terrain réelles)
• Visez un LCP sous 2500 ms et un INP sous 200 ms comme priorité absolue
• Utilisez le Speed Index comme métrique de diagnostic complémentaire, pas comme objectif principal
• Optimisez le chemin critique de rendu : différez JS/CSS non critiques, compressez images, utilisez un CDN
• Testez sur des connexions mobiles réelles (3G/4G), pas seulement en WiFi ou fibre optique
• Surveillez les régressions après chaque déploiement avec un monitoring continu (WebPageTest, SpeedCurve, Lighthouse CI)