Test de vitesse de page : trouvez ce qui ralentit votre site

La vitesse est la partie du SEO que vos visiteurs ressentent directement. Un serveur lent, une grosse image d’en-tête ou une pile de scripts bloquants retardent le moment où les gens voient votre contenu, et chaque seconde de plus leur donne une raison de retourner aux résultats de recherche.

Ce test de vitesse de page mesure ce qui se passe côté serveur et dans le HTML : temps jusqu’au premier octet, temps de téléchargement, taille du HTML et compression, version de HTTP, nombre et poids des scripts, des feuilles de style et des images, ressources bloquant le rendu, en-têtes de cache et formats d’image. Quand Google dispose de données terrain pour l’URL, il affiche aussi LCP, INP et CLS issus de PageSpeed Insights.

Comment tester la vitesse d’une page

1. Saisissez l’URL de la page

   Testez les pages qui comptent le plus, comme vos principales pages d’atterrissage et vos modèles de fiches produit, pas seulement la page d’accueil.

2. Lisez les deux types de données

   Les mesures du serveur et du poids de la page viennent de notre requête ; les Core Web Vitals viennent d’utilisateurs réels de Chrome lorsqu’ils sont disponibles.

3. Corrigez d’abord le plus coûteux

   Commencez par un TTFB lent, des images surdimensionnées et des fichiers bloquant le rendu, puis retestez la même URL.

Les seuils des Core Web Vitals

Les Core Web Vitals de Google mesurent le chargement, la réactivité et la stabilité visuelle pour de vrais utilisateurs de Chrome, évalués au 75e centile des chargements de page :

Métrique	Bon	À améliorer	Mauvais
LCP (Largest Contentful Paint)	≤ 2,5 s	2,5–4 s	> 4 s
INP (Interaction to Next Paint)	≤ 200 ms	200–500 ms	> 500 ms
CLS (Cumulative Layout Shift)	≤ 0,1	0,1–0,25	> 0,25

L’INP a remplacé le First Input Delay en mars 2024. Les données terrain proviennent du Chrome UX Report sur une fenêtre glissante de 28 jours : les améliorations mettent donc des semaines à apparaître, et les pages peu visitées peuvent n’avoir aucune donnée. Notre guide des Core Web Vitals détaille chaque métrique.

Interpréter les mesures côté serveur

• TTFB : le délai avant l’arrivée du premier octet de HTML. web.dev suggère 0,8 s ou moins comme objectif approximatif. Tout le reste, LCP compris, en dépend ; la mise en cache des pages et un CDN sont les remèdes habituels.
• Compression : le HTML, le CSS et le JavaScript doivent être servis avec Brotli ou gzip.
• Version de HTTP : HTTP/2 ou HTTP/3 permet au navigateur de récupérer de nombreux fichiers sur une seule connexion.
• Requêtes et poids : chaque script et chaque feuille de style coûtent du temps de téléchargement et de traitement ; les images représentent généralement le plus gros des octets.
• Ressources bloquant le rendu : les feuilles de style et les scripts synchrones du head qui doivent être chargés avant que quoi que ce soit ne s’affiche.
• Cache : les fichiers statiques sans longue durée de cache sont retéléchargés à chaque visite.
• Formats d’image : WebP et AVIF sont généralement bien plus légers que JPEG ou PNG à qualité comparable.

Les correctifs qui font bouger LCP, INP et CLS

Chargez l’image principale en priorité et ne la chargez jamais en différé ; donnez des dimensions à chaque image pour qu’elle ne puisse pas décaler la mise en page :

<img src="/img/hero.avif" width="1200" height="630"
     fetchpriority="high" alt="Fresh sourdough loaves">
<img src="/img/team.webp" width="600" height="400"
     loading="lazy" alt="Our bakery team">
<script src="/js/app.js" defer></script>

L’attribut defer empêche les scripts de bloquer le premier affichage. Pour l’INP, raccourcissez les longues tâches du thread principal : supprimez les balises tierces inutilisées, découpez les gestionnaires d’événements lourds et rendez la main au navigateur entre deux blocs de travail. Pour le CLS, réservez l’espace des publicités, des contenus intégrés et des bandeaux de cookies avec des dimensions fixes ou aspect-ratio.

Mettre en cache les fichiers statiques

Les fichiers dont le nom change à chaque version, comme app.3f9a1c.js, peuvent être mis en cache pendant un an. Sur Nginx :

location ~* \.(css|js|woff2|avif|webp|jpg|png|svg)$ {
    add_header Cache-Control "public, max-age=31536000, immutable";
}

Sur Apache, la même valeur se place dans un bloc <FilesMatch> avec Header set Cache-Control. Ne le faites que pour des noms de fichiers empreints d’un hash : un simple style.css mis en cache pendant un an signifie que les visiteurs qui reviennent gardent l’ancien design après votre modification. Vérifiez le résultat avec le vérificateur d’en-têtes HTTP.

Conseils pour une page plus rapide

• Corrigez les modèles, pas les URL une à une : accélérer le modèle de fiche produit accélère d’un coup toutes les pages produit.
• Redimensionnez les images avant de les mettre en ligne ; une photo de 4 000 pixels affichée dans un emplacement de 600 pixels gaspille la plupart de ses octets.
• Passez en revue les balises tierces tous les quelques mois ; widgets de chat, cartes de chaleur et pixels oubliés coûtent souvent plus cher que votre propre code.
• Hébergez vous-même les polices critiques en WOFF2 et ne préchargez que les un ou deux fichiers utilisés au-dessus de la ligne de flottaison.
• Retestez après chaque modification plutôt qu’après dix, pour savoir quel correctif a réellement aidé.

Limites à garder en tête

Notre test récupère la page depuis notre serveur, sans exécuter JavaScript ni afficher la page : il mesure donc la réponse du serveur, le poids des fichiers et la structure du HTML plutôt que des temps d’affichage en laboratoire. Les Core Web Vitals n’apparaissent que si PageSpeed Insights dispose de données d’utilisateurs réels pour la page. Pour une analyse complète en laboratoire dans un vrai navigateur, utilisez Lighthouse dans les outils de développement de Chrome ou PageSpeed Insights, et contrôlez les problèmes d’affichage mobile avec le test de compatibilité mobile.

Dernière mise à jour le 30 oct. 2026 par l’équipe Yes SEO.