Vitesse d’un site web : comment la tester et la corriger

Un site lent se remarque tout de suite : la page reste blanche, la photo arrive en dernier, le bouton bouge au moment de cliquer. Le visiteur n’attend pas, il revient à Google. La vitesse d’un site web se mesure gratuitement et se corrige presque toujours. Il faut juste savoir quel chiffre regarder, et par quoi commencer. Voici la méthode que nous appliquons sur chaque projet à l’agence Resolve (Re:solve).

Comment tester la vitesse de son site

Ouvrez PageSpeed Insights (pagespeed.web.dev), collez l’adresse de votre page d’accueil, et lisez d’abord le bloc du haut, « Découvrez ce que vivent vos utilisateurs réels ». C’est lui qui compte, pas la note sur 100.

Selon la documentation de Google, l’outil combine deux types de données. Les données de terrain viennent du rapport d’expérience utilisateur de Chrome (CrUX) : les mesures faites chez de vrais visiteurs, sur leurs appareils et leurs connexions, sur 28 jours. Les données de laboratoire viennent de Lighthouse, qui simule un chargement sur un téléphone de milieu de gamme en connexion mobile. C’est cette partie qui donne la note de 0 à 100 et la liste des corrections.

Deux pièges : si votre site a peu de visites, Google n’a pas assez de données de terrain et vous ne verrez que le laboratoire, dont la note varie d’un test à l’autre. Et testez plusieurs pages, pas seulement l’accueil : la page de réservation, une fiche produit, un article. Google Search Console (gratuite) classe aussi toutes vos pages par état dans son rapport « Signaux Web essentiels ».

Quels chiffres regarder

Regardez les trois Core Web Vitals et comparez-les aux seuils officiels. Le reste (nombre de requêtes, poids total, note sur 100) aide à comprendre, sans être la mesure.

Selon web.dev, ces seuils sont évalués au 75e percentile : votre page est « bonne » si trois visites sur quatre passent sous le seuil, mobile et ordinateur comptés séparément. Votre propre expérience sur un bon Wi-Fi ne dit donc rien. Ce qui compte, c’est le visiteur sur son téléphone, dans le métro. Chaque mesure est détaillée dans notre guide sur les Core Web Vitals et comment les améliorer.

Pourquoi un site est lent : les causes qui reviennent

Dans la grande majorité des cas, un site lent souffre d’une ou deux causes seulement, toujours les mêmes : des images trop lourdes, trop de scripts, un thème ou un hébergement qui freinent.

Les images

C’est la cause numéro un, surtout sur les sites de restaurants, d’artisans ou de salons, où les photos font le site. Une photo sortie du téléphone pèse plusieurs méga-octets ; affichée en 600 pixels de large, elle devrait peser cinquante fois moins. Trois règles :

• Redimensionnez à la taille d’affichage réelle, avec des versions pour mobile (l’attribut srcset laisse le navigateur choisir).
• Passez en WebP ou AVIF. Selon web.dev, une image WebP est 25 à 35 % plus légère qu’un JPEG de qualité visuelle équivalente.
• Chargez les images hors écran seulement quand on arrive dessus (loading="lazy"), mais jamais la photo d’en-tête : celle-là doit partir en premier, avec fetchpriority="high". Selon web.dev, ce seul réglage a fait gagner 0,7 seconde de LCP dans leurs tests.

Les scripts tiers

Chaque outil ajouté « en un clic » charge son propre code : le chat, la carte, le module d’avis, le pixel publicitaire, le gestionnaire de cookies. Chacun semble léger. Ensemble, ils bloquent le navigateur, et c’est l’INP qui se dégrade : la page est affichée, mais elle ne répond plus quand on tape dans le formulaire. Faites l’inventaire, supprimez ce qui ne sert plus, et chargez le reste après le contenu (attributs defer ou async).

Le thème, les extensions, l’hébergement

Sur WordPress, un constructeur de page et une trentaine d’extensions chargent chacun leur code sur toutes les pages, même celles qui n’en ont pas besoin. Un thème lourd peut à lui seul mettre une page sous la barre du « bon ». Si c’est votre cas, le sujet dépasse l’optimisation : voir notre comparatif WordPress, Webflow, Framer ou code sur mesure.

Le temps que met le serveur à renvoyer la première réponse (TTFB, « time to first byte ») se voit aussi dans PageSpeed. S’il dépasse régulièrement une seconde, changez d’offre, ajoutez un cache de page, ou placez un CDN (un réseau de serveurs proches du visiteur) devant votre site.

Dans quel ordre corriger

Commencez par ce qui est visible en haut de l’écran, sur mobile, puis descendez.

1. La photo d’en-tête : taille réelle, WebP, priorité haute, jamais en chargement différé.
2. Les scripts : supprimez, puis différez. Mesurez l’INP avant et après.
3. Les dimensions réservées : une largeur et une hauteur sur chaque image, vidéo et bandeau, pour que rien ne saute (CLS).
4. Le serveur : cache et CDN si le TTFB est lent.
5. Le reste : les autres images, les pages secondaires, les polices (la règle font-display: swap affiche une police de secours en attendant la vôtre, selon la documentation MDN).

Après chaque étape, relancez PageSpeed. Les données de terrain mettent jusqu’à 28 jours à refléter le changement : jugez l’effet immédiat sur le laboratoire, l’effet réel un mois plus tard. Un site pensé mobile d’abord évite la plupart de ces chantiers, comme nous l’expliquons dans notre guide sur le site mobile first.

La vitesse et Google : ce qu’il faut savoir

Oui, Google utilise les Core Web Vitals dans ses systèmes de classement. Non, un bon score ne fait pas monter une page à lui seul. La documentation Google Search Central le dit : un bon résultat dans les rapports « ne garantit pas que vos pages se classent en tête », et chercher un score parfait seulement pour le SEO « n’est peut-être pas le meilleur usage de votre temps ».

Notre lecture : la vitesse est un prérequis, pas un levier. Un site lent perd des visiteurs avant même qu’ils lisent, et c’est cela qui coûte. Un site rapide laisse le contenu, les liens et la fiche locale faire leur travail. Si vous ne savez pas où en est le vôtre, notre analyse gratuite en ligne note la vitesse avec le SEO, le GEO, le design et la confiance, et liste les corrections.

Notre avis

Nous voyons passer beaucoup de sites notés 95 sur ordinateur et 40 sur mobile. Le propriétaire a testé depuis son bureau. Ses clients, eux, arrivent depuis Google Maps, sur un téléphone, souvent en 4G faible. C’est ce chiffre-là qu’il faut regarder.

Deuxième conviction : la vitesse ne se « rajoute » pas à la fin avec une extension d’optimisation. Ces outils compressent, mettent en cache et retardent les scripts, et ils aident. Mais ils ne corrigent ni un thème trop lourd, ni dix modules tiers, ni un hébergement bas de gamme.

Enfin, la vitesse est une habitude. Un site rapide à la mise en ligne redevient lent après six mois d’extensions et de photos non redimensionnées. Un test par trimestre suffit.

Ce que fait l’agence Resolve

Sur chaque site que nous créons ou refondons, la vitesse est traitée dès la conception : images aux bonnes tailles et formats, scripts tiers limités au nécessaire, dimensions réservées pour chaque bloc, hébergement choisi pour le temps de réponse. Nous mesurons sur mobile, avant et après la mise en ligne. Pour un site existant, notre audit offert commence par un relevé des Core Web Vitals de vos pages principales et des causes réelles, dans l’ordre d’impact. Pour une première photo, notre guide sur l’audit SEO gratuit en 5 minutes explique comment la faire vous-même.

Questions fréquentes

Quelle est une bonne vitesse pour un site web ?

Prenez les seuils de Google : LCP à 2,5 secondes ou moins, INP à 200 millisecondes ou moins, CLS à 0,1 ou moins, pour trois visites sur quatre, sur mobile. Un « temps de chargement total » n’a pas de seuil officiel.

Pourquoi mon site est rapide sur mon ordinateur et lent dans PageSpeed ?

Parce que PageSpeed simule un téléphone de milieu de gamme en connexion mobile, et que ses données de terrain reflètent vos vrais visiteurs, pas votre Wi-Fi. Un site est jugé sur ce que vit la majorité.

Une extension de cache suffit-elle à rendre un site WordPress rapide ?

Elle aide, surtout pour le temps de réponse du serveur et la compression. Elle ne remplace ni des images à la bonne taille, ni un tri dans les extensions et le thème. Si le mobile reste sous la barre du « bon » après, le problème est ailleurs.