Google PageSpeed Insights : le guide complet pour améliorer les performances de votre site

La vitesse de chargement d’un site web n’est plus seulement une question de confort utilisateur : c’est un signal de classement Google officiel depuis mai 2021. Si votre site est lent, vous perdez du trafic organique, des conversions et de la crédibilité, souvent sans le savoir.

Google PageSpeed Insights est l’outil gratuit qui permet de mesurer précisément ces performances et d’identifier ce qui freine votre site. Ce guide vous explique comment l’utiliser, comment interpréter chaque métrique et ce que les résultats révèlent sur votre stack technique.

Cet article est le premier d’une série sur la santé technique de votre site. Une fois vos performances analysées, l’étape suivante est de valider la structure de votre site dans Google Search Console : sitemap, données structurées, erreurs d’indexation et Core Web Vitals terrain.

Pourquoi la performance technique impacte votre référencement Google

Google a officiellement intégré les Core Web Vitals comme facteur de classement en mai 2021, avec le déploiement progressif du “Page Experience Update”. Ce n’est plus une recommandation : c’est un critère de ranking parmi d’autres, au même titre que la pertinence du contenu ou les liens entrants.

Les chiffres qui justifient cet enjeu

Les données issues des études Google et de tiers indépendants sont convergentes :

• 53 % des visites mobiles sont abandonnées si une page met plus de 3 secondes à charger (Google/SOASTA, étude sur 11 millions de sessions mobiles).
• Un délai de 1 seconde supplémentaire au chargement entraîne en moyenne 7 % de conversions en moins (Akamai, 2017, confirmé depuis par plusieurs études secteur e-commerce).
• Les pages qui respectent les seuils Core Web Vitals ont en moyenne 24 % moins de taux d’abandon que celles qui ne les respectent pas (source : Web.dev / Chrome UX Report, 2023).
• Google indique que les résultats avec une bonne expérience page peuvent bénéficier d’un signal positif pour le classement, à contenu équivalent (source : Google Search Central).

Ce que Google mesure concrètement

Le Page Experience Update regroupe plusieurs signaux :

• Les Core Web Vitals (LCP, INP, CLS) : les trois métriques principales de l’expérience utilisateur.
• L’optimisation mobile : le site est-il utilisable confortablement sur un smartphone ?
• Le HTTPS : votre site est-il servi en connexion sécurisée ?
• L’absence d’interstitiels intrusifs : pas de popups qui bloquent le contenu principal sur mobile.

Google précise que ces signaux n’écrasent pas la pertinence du contenu. Un contenu très pertinent sur un site lent sera toujours mieux classé qu’un contenu médiocre sur un site rapide. Mais à contenu équivalent, la performance devient un différenciateur.

Google PageSpeed Insights : présentation de l’outil

PageSpeed Insights (PSI) est un outil gratuit de Google, accessible sans compte. Il analyse une URL précise et produit deux types de données :

• Données terrain (Field Data / CrUX) : mesures réelles collectées par Chrome sur les 28 derniers jours, issues du Chrome User Experience Report. Elles reflètent l’expérience réelle de vos visiteurs.
• Données de laboratoire (Lab Data) : simulation réalisée par Lighthouse dans un environnement contrôlé (réseau, appareil simulés). Utiles pour le diagnostic et la comparaison, mais ne reflètent pas forcément l’expérience réelle.

Pour utiliser l’outil : rendez-vous sur pagespeed.web.dev, entrez l’URL de votre page d’accueil (ou de toute page stratégique) et cliquez sur “Analyser”.

Conseil : analysez toujours votre page d’accueil, mais aussi vos pages les plus visitées. Les performances peuvent varier significativement d’une page à l’autre selon les images, scripts et fonctionnalités présentes.

Les sections du rapport décryptées

Le score de performance (0 à 100)

Le score global visible en haut du rapport est un score composite calculé par Lighthouse. Il agrège plusieurs métriques avec des pondérations différentes :

Métrique	Pondération
Largest Contentful Paint (LCP)	25 %
Total Blocking Time (TBT)	30 %
Cumulative Layout Shift (CLS)	25 %
First Contentful Paint (FCP)	10 %
Speed Index	10 %

Les seuils de couleur sont :

• Vert (90-100) : bonne performance
• Orange (50-89) : à améliorer
• Rouge (0-49) : mauvaise performance

Les Core Web Vitals

Ce sont les trois métriques que Google utilise comme signal de classement. Elles mesurent l’expérience réelle de vos utilisateurs.

Documentation officielle de Google

LCP — Largest Contentful Paint (Affichage du plus grand élément)

Le LCP mesure le temps d’affichage de l’élément visible le plus grand de la page : souvent une image hero, un bloc de texte principal ou une bannière. Il représente la perception qu’a l’utilisateur du “moment où la page est chargée”.

• Bon : inférieur à 2,5 secondes
• À améliorer : entre 2,5 et 4 secondes
• Mauvais : supérieur à 4 secondes

Causes fréquentes d’un LCP dégradé : images non compressées, serveur lent (TTFB élevé), ressources bloquantes en CSS ou JS, polices web chargées sans préchargement.

INP — Interaction to Next Paint (Réactivité aux interactions)

L’INP mesure la réactivité de la page aux interactions de l’utilisateur (clics, saisies clavier, touches tactiles). Il a remplacé le FID (First Input Delay) en mars 2024 car il mesure toutes les interactions pendant la session, pas seulement la première.

• Bon : inférieur à 200 millisecondes
• À améliorer : entre 200 et 500 ms
• Mauvais : supérieur à 500 ms

Causes fréquentes d’un INP dégradé : JavaScript lourd bloquant le thread principal, scripts tiers (analytics, chat, publicités), frameworks JS non optimisés.

CLS — Cumulative Layout Shift (Stabilité visuelle)

Le CLS mesure les décalages visuels inattendus pendant le chargement : des éléments qui sautent parce qu’une image sans dimensions définies se charge, une publicité qui s’insère et pousse le contenu, une police qui remplace une police système en changeant les hauteurs de ligne.

• Bon : inférieur à 0,1
• À améliorer : entre 0,1 et 0,25
• Mauvais : supérieur à 0,25

Un CLS élevé est frustrant pour les utilisateurs et peut provoquer des clics involontaires.

Les autres métriques

FCP — First Contentful Paint (Premier affichage)

Temps avant que le navigateur affiche le premier pixel de contenu (texte, image, SVG). C’est le signal que “quelque chose se passe”. Un FCP rapide réduit la perception d’attente.

• Bon : inférieur à 1,8 secondes
• Mauvais : supérieur à 3 secondes

TTFB — Time to First Byte (Temps de réponse serveur)

Délai entre l’envoi de la requête HTTP et la réception du premier octet de réponse du serveur. Un TTFB élevé indique un problème côté serveur : hébergement sous-dimensionné, base de données lente, absence de cache.

• Bon : inférieur à 800 ms
• Mauvais : supérieur à 1 800 ms

TBT — Total Blocking Time (Temps de blocage total)

Somme des durées pendant lesquelles le thread principal JavaScript est bloqué et ne peut pas répondre aux interactions. Un TBT élevé est souvent la cause d’un mauvais INP.

Speed Index

Mesure la vitesse à laquelle le contenu visible est affiché pendant le chargement. Différent du LCP : il mesure la progression globale de l’affichage, pas seulement le plus grand élément.

Les opportunités et diagnostics

Sous les métriques, PageSpeed Insights liste :

• Opportunités : actions concrètes avec une estimation de gain en secondes. Exemples : compresser les images, éliminer le CSS inutilisé, différer les scripts JS non critiques.
• Diagnostics : problèmes techniques sans estimation de gain direct mais qui impactent les métriques.
• Audits réussis : ce qui fonctionne déjà bien (utile pour comprendre ce qu’on ne doit pas casser).

Score mobile vs score desktop : lequel compte vraiment ?

PageSpeed Insights affiche deux scores distincts : un pour mobile et un pour desktop. La différence peut être spectaculaire : un site peut obtenir 90/100 sur desktop et 45/100 sur mobile.

Le score mobile est le seul qui compte pour votre référencement.

Google utilise le mobile-first indexing depuis septembre 2020 pour l’ensemble des sites web. Concrètement, cela signifie que c’est la version mobile de votre site que Google explore, indexe et utilise pour déterminer votre classement, même pour les recherches effectuées sur desktop.

Pourquoi les scores diffèrent autant

La simulation mobile de Lighthouse applique des contraintes plus sévères :

• Réseau simulé : connexion 4G lente (environ 10 Mbps de débit descendant, 40 ms de latence), contre une connexion câble pour le desktop.
• CPU simulé : processeur ralenti d’un facteur 4 à 6 par rapport au desktop, pour simuler un smartphone milieu de gamme.
• Viewport réduit : affichage en 375px de large, qui peut déclencher des layouts différents, des images différentes, des comportements CSS différents.

Un framework JavaScript lourd sera pénalisé bien plus sévèrement sur mobile : le CPU simulé met beaucoup plus de temps à parser et exécuter le JS, augmentant le TBT et dégradant l’INP.

En pratique : focalisez votre effort d’optimisation sur le score mobile. Si votre score desktop est excellent et votre score mobile médiocre, c’est le score mobile que Google regarde.

Sur mesure vs no-code : un comparatif concret

La stack technique de votre site a un impact direct et massif sur vos performances PageSpeed. Comparer un site développé sur mesure à un site construit sur une plateforme no-code illustre concrètement ce que signifie “maîtriser la performance”.

Le cas Webflow

Webflow est une plateforme no-code populaire pour la création de sites vitrines. Elle génère automatiquement le HTML, CSS et JS sans que l’opérateur ait à écrire de code. Cette abstraction a un coût en performance :

• Webflow charge systématiquement son runtime JavaScript (webflow.js), quel que soit le contenu de la page. Ce fichier pèse plusieurs dizaines de kilooctets et bloque le thread principal.
• Les polices et CSS sont chargés de manière non optimale par défaut, augmentant le FCP.
• Les images peuvent être redimensionnées côté serveur, mais la compression et le format (WebP, AVIF) dépendent de la configuration manuelle.
• Le CLS est souvent dégradé à cause du chargement asynchrone des polices Webflow.

Résultat typique observé sur des sites Webflow en production : score mobile entre 40 et 70, avec un LCP fréquemment au-dessus de 3 secondes sur mobile.

TODO : ajouter un screenshot du rapport PageSpeed d’un site Webflow représentatif (anonymisé ou exemple public) avec les métriques visibles.

Analyse de webflow.com en direct

Pour cette analyse, nous avons pris le site de l’éditeur de webflow qui représente l’état de l’art en terme de site no code. Le résultat est sans appel : performance 33% et core web vitals en échec.

Le cas WordPress

WordPress propulse plus de 40 % des sites web mondiaux. Sa popularité vient de son écosystème riche et de sa prise en main sans code, mais cette flexibilité se paye en performance.

Les causes structurelles d’un mauvais score mobile :

• Chaque page est générée dynamiquement côté serveur (PHP + requêtes base de données), ce qui augmente le TTFB, surtout sur un hébergement mutualisé.
• Les thèmes commerciaux embarquent des frameworks complets (Bootstrap, jQuery, Elementor, WPBakery) même si seule une fraction de ces librairies est réellement utilisée.
• L’accumulation de plugins (SEO, formulaires, sécurité, cache, e-commerce) ajoute autant de couches de JavaScript et de CSS supplémentaires.
• Le CLS est fréquemment dégradé par les constructeurs de page qui chargent leurs styles de manière asynchrone, provoquant des décalages visuels à chaque chargement.

Résultat typique observé sur des sites WordPress avec thème commercial et une dizaine de plugins : score mobile entre 25 et 60, avec un TBT souvent supérieur à 400 ms. Des solutions existent (plugin de cache, CDN, optimisation d’images), mais elles compensent sans corriger : à chaque mise à jour de plugin, la dette de performance se recrée.

Analyse de wordpress.com/fr en direct

Pour cette analyse, nous avons pris le site de l’éditeur de wordpress sensé être une référence où vous pouvez voir un score de 46% en performance et aucun n’atteignant le 100%.

Le cas du site smartbooster.io

Le site de SmartBooster est développé sur mesure avec Astro, un framework statique moderne. L’architecture Astro génère du HTML statique pur avec zéro JavaScript par défaut côté client : le JS n’est chargé que pour les composants qui en ont explicitement besoin (îles d’interactivité).

Conséquences mesurables sur mobile :

• TTFB très bas : le serveur envoie du HTML pré-rendu, sans calcul dynamique.
• TBT à 0 ms : pas de JavaScript bloquant le thread principal au chargement.
• FCP à 1,2 s : le premier contenu visible s’affiche rapidement, sans ressources bloquantes.
• LCP à 1,9 s : les images hero sont préchargées, compressées en WebP, avec des dimensions explicites pour éviter tout décalage.
• CLS à 0,002 : les polices sont chargées avec font-display: swap et les images ont des dimensions déclarées.

Le Lighthouse Treemap illustre ce que “zéro JavaScript par défaut” signifie concrètement : le total de JavaScript transféré sur la page d’accueil est de 5,9 KiB, dont 2,6 KiB pour Plausible Analytics (mesure d’audience) et 2,1 KiB pour le bundle Astro de la page. Aucun framework JS, aucun runtime tiers superflu.

Analyse de www.smartbooster.io en direct

Ce que ce comparatif révèle

La performance n’est pas une question de budget, c’est une question de maîtrise technique. Un développeur qui connaît son métier optimise chaque ressource, choisit le bon outil pour le bon besoin et ne charge pas de code superflu.

Une plateforme no-code optimise pour la facilité de création, pas pour la performance de livraison. Ce n’est pas un défaut intrinsèque : pour un site vitrine simple, une agence no-code peut livrer en quelques jours. Mais si la performance SEO est un enjeu stratégique (et elle l’est souvent), le développement sur mesure permet d’atteindre des scores qu’aucune plateforme générique ne peut garantir par défaut.

Remarque : atteindre un score mobile de 90+ n’est pas automatique en développement sur mesure. C’est le résultat d’un ensemble de bonnes pratiques : choix du framework, optimisation des images, stratégie de chargement des ressources, configuration du serveur, gestion du cache. Un développeur qui ne maîtrise pas ces sujets peut produire un site sur mesure aussi lent qu’un site no-code. La différence, c’est que sur mesure, tout est corrigeable : on n’est pas limité par les contraintes de la plateforme.

Ce que vous devez faire maintenant

1. Testez votre site sur pagespeed.web.dev en mode mobile.
2. Notez vos scores LCP, INP et CLS : ce sont les métriques que Google utilise.
3. Identifiez la première opportunité listée dans le rapport : c’est souvent le gain le plus rapide.
4. Passez à la validation technique : une fois les performances identifiées, vérifiez que votre site est correctement indexé et que vos données structurées sont valides dans Google Search Console.

Si votre score mobile est inférieur à 70 et que vos pages sont stratégiques pour votre acquisition, c’est un sujet à traiter sérieusement. Parlons-en.