Google PageSpeed Insights : analyser les performances

Qu'est-ce que Google PageSpeed Insights ?

Google PageSpeed Insights (PSI) est un outil gratuit proposé par Google qui analyse les performances d'une page web et fournit des recommandations concrètes pour les améliorer. Il est accessible directement à l'adresse pagespeed.web.dev et ne nécessite aucune installation.

PSI ne se limite pas à une simple mesure de vitesse. Il évalue la qualité de l'expérience utilisateur en se basant sur deux sources de données complémentaires :

• Données de terrain (CrUX) — données réelles collectées par Chrome sur les vrais utilisateurs du site. Elles reflètent les conditions réseau et matérielles réelles.
• Données de laboratoire (Lighthouse) — mesures effectuées dans un environnement simulé et contrôlé, utiles pour diagnostiquer les problèmes.

Lien direct avec le SEO et les Core Web Vitals

Depuis 2021, Google intègre les Core Web Vitals dans son algorithme de classement. Ces métriques mesurent des aspects perceptibles par l'utilisateur : vitesse de chargement, réactivité et stabilité visuelle. Un bon score PageSpeed est donc un levier SEO direct, en plus d'être un facteur de conversion.

Les métriques clés à connaître

PageSpeed Insights mesure six métriques principales. Trois d'entre elles constituent les Core Web Vitals officiels de Google (LCP, INP, CLS). Les trois autres (FCP, TTFB, TBT) sont des métriques de diagnostic complémentaires.

LCP — Largest Contentful Paint

Mesure le temps nécessaire pour afficher le plus grand élément visible dans la fenêtre : image hero, bloc de texte principal, vidéo. C'est l'indicateur de "vitesse perçue" le plus important.

INP — Interaction to Next Paint (remplace FID)

Mesure la réactivité globale aux interactions utilisateur (clic, saisie clavier, tap). Contrairement au FID qui ne mesurait que la première interaction, l'INP mesure toutes les interactions de la session et retient la pire.

CLS — Cumulative Layout Shift

Mesure la stabilité visuelle de la page. Un CLS élevé signifie que des éléments bougent de manière inattendue pendant le chargement (ex. : une publicité qui s'insère et pousse le contenu vers le bas).

FCP — First Contentful Paint

Mesure le temps avant que le premier contenu (texte, image) soit rendu. C'est un indicateur de démarrage de chargement, utile pour détecter les blocages early.

TTFB — Time to First Byte

Mesure le délai entre la requête HTTP et la réception du premier octet de la réponse serveur. Un TTFB élevé pointe vers un problème serveur, DNS, ou absence de cache.

TBT — Total Blocking Time

Mesure la durée totale pendant laquelle le thread principal du navigateur est bloqué (par du JavaScript long), empêchant les interactions utilisateur. Corrélé fortement avec le INP.

Utiliser PageSpeed Insights étape par étape

Voici comment tirer le maximum de l'outil, même en tant que débutant.

Étape 1 — Accéder à l'outil

Rendez-vous sur pagespeed.web.dev. Saisissez l'URL complète de la page à analyser (par exemple https://mon-site.com/ma-page) puis cliquez sur Analyser. L'analyse dure entre 15 et 30 secondes.

Étape 2 — Comparer mobile vs desktop

PSI propose deux onglets : Mobile et Ordinateur. Le score mobile est presque toujours plus bas, car Google simule un réseau 4G lent et un appareil d'entrée de gamme. C'est pourtant ce score qui compte le plus pour le SEO, Google appliquant le Mobile First Indexing.

Étape 3 — Comprendre le score global (0–100)

Le score affiché en haut de page est un score de performance Lighthouse, calculé à partir d'une pondération des métriques :

• LCP — 25 %
• TBT — 30 %
• CLS — 15 %
• FCP — 10 %
• Speed Index — 10 %
• Time to Interactive — 10 %

Un score entre 90 et 100 est considéré bon (vert), entre 50 et 89 nécessite des améliorations (orange), en dessous de 50 est mauvais (rouge).

Étape 4 — Lire les opportunités et diagnostics

L'interface est organisée en trois catégories principales :

• Opportunités — actions concrètes avec gain estimé en secondes (ex. : "Réduire les ressources inutilisées : gain estimé 2,5 s").
• Diagnostics — points d'amélioration sans gain chiffré direct mais importants pour la robustesse.
• Audits réussis — ce qui est déjà correctement fait, à ne pas casser.

Les optimisations les plus impactantes

Voici les six leviers d'optimisation qui génèrent les gains les plus significatifs sur le score PageSpeed.

1. Optimiser les images

Les images représentent en moyenne 50 % à 70 % du poids d'une page web. C'est le levier n°1 à activer :

• Utiliser le format WebP (30–50 % plus léger que JPEG/PNG) ou AVIF pour les navigateurs modernes.
• Activer le lazy loading natif (loading="lazy") sur toutes les images hors du viewport initial.
• Toujours définir les attributs width et height pour éviter le CLS (le navigateur réserve l'espace avant le chargement).
• Utiliser srcset pour servir des images adaptées à la résolution de l'écran.
• Compresser avec des outils comme Squoosh, TinyPNG ou ImageMagick.

2. Minifier CSS et JavaScript

Supprimer les espaces, commentaires et caractères inutiles dans les fichiers CSS et JS réduit leur taille et accélère leur téléchargement et leur parsing. Utilisez des bundlers comme Webpack, Vite ou esbuild pour automatiser cette étape en production.

3. Réduire le render-blocking

Un script ou feuille de style "render-blocking" bloque l'affichage de la page le temps de son chargement et de son traitement. Chaque milliseconde compte sur le LCP et le FCP.

• Ajouter defer ou async sur tous les scripts non-critiques.
• Charger les CSS non-critiques de manière asynchrone (technique media="print" + swap).
• Inliner le CSS critique (above-the-fold) dans le <head>.

4. Utiliser le cache navigateur

En configurant des en-têtes HTTP Cache-Control et Expires, vous indiquez au navigateur combien de temps il peut conserver une ressource localement sans la re-télécharger. Les ressources statiques (images, CSS, JS) peuvent être mises en cache pour 1 an minimum.

5. Activer la compression Gzip / Brotli

La compression côté serveur réduit la taille des fichiers texte (HTML, CSS, JS) de 60 % à 80 % avant leur envoi au navigateur. Brotli est plus efficace que Gzip mais nécessite HTTPS. Les deux sont supportés par Apache, Nginx et la plupart des CDN.

6. CDN et HTTP/2

Un CDN (Content Delivery Network) distribue vos ressources statiques depuis des serveurs géographiquement proches de vos utilisateurs, réduisant drastiquement la latence. HTTP/2 permet le multiplexage des requêtes (plusieurs ressources en parallèle sur une seule connexion) et est activé automatiquement sur la plupart des hébergements modernes.

Exemples de code concrets

Voici des exemples directement applicables dans vos projets, avec explications commentées.

Balise <img> optimisée (lazy loading, srcset, dimensions)

Une balise image correctement configurée impacte positivement le LCP, le CLS et le score global :

<!-- Image optimisée : toutes les bonnes pratiques PSI réunies -->
<picture>
  <!-- Format AVIF pour les navigateurs qui le supportent (le plus léger) -->
  <source
    type="image/avif"
    srcset="hero-400.avif 400w,
            hero-800.avif 800w,
            hero-1200.avif 1200w"
    sizes="(max-width: 576px) 100vw,
           (max-width: 992px) 50vw,
           800px"
  >
  <!-- Format WebP en fallback pour les navigateurs modernes -->
  <source
    type="image/webp"
    srcset="hero-400.webp 400w,
            hero-800.webp 800w,
            hero-1200.webp 1200w"
    sizes="(max-width: 576px) 100vw,
           (max-width: 992px) 50vw,
           800px"
  >
  <!-- Fallback JPEG pour les anciens navigateurs -->
  <img
    src="hero-800.jpg"
    alt="Description précise de l'image pour l'accessibilité"
    width="800"
    height="420"
    loading="lazy"
    decoding="async"
  >
</picture>

<!-- Image LCP (au-dessus du fold) : ne PAS lazy-loader ! -->
<img
  src="hero-principale.webp"
  alt="Bannière principale du site"
  width="1200"
  height="630"
  loading="eager"
  fetchpriority="high"
>
<!-- fetchpriority="high" indique au navigateur de prioriser
     cette ressource dans la file de téléchargement -->

Configuration .htaccess — cache + compression

À placer dans le fichier .htaccess à la racine de votre site Apache :

# ============================================================
# Activation de la compression Gzip (mod_deflate)
# Réduit la taille des fichiers texte de 60 à 80 %
# ============================================================
<IfModule mod_deflate.c>
    # Compresser les types MIME textuels
    AddOutputFilterByType DEFLATE text/html
    AddOutputFilterByType DEFLATE text/css
    AddOutputFilterByType DEFLATE text/javascript
    AddOutputFilterByType DEFLATE application/javascript
    AddOutputFilterByType DEFLATE application/json
    AddOutputFilterByType DEFLATE application/xml
    AddOutputFilterByType DEFLATE image/svg+xml
    AddOutputFilterByType DEFLATE font/woff2

    # Ne pas compresser les ressources déjà compressées
    SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|webp|avif|zip|gz)$ no-gzip dont-vary
</IfModule>

# ============================================================
# Cache navigateur (Expires headers)
# Indique combien de temps le navigateur peut conserver
# chaque type de ressource sans la re-télécharger
# ============================================================
<IfModule mod_expires.c>
    ExpiresActive On

    # Images : cache 1 an (ressources rarement modifiées)
    ExpiresByType image/jpeg          "access plus 1 year"
    ExpiresByType image/png           "access plus 1 year"
    ExpiresByType image/webp          "access plus 1 year"
    ExpiresByType image/avif          "access plus 1 year"
    ExpiresByType image/gif           "access plus 1 year"
    ExpiresByType image/svg+xml       "access plus 1 year"

    # Polices : cache 1 an
    ExpiresByType font/woff2          "access plus 1 year"
    ExpiresByType font/woff           "access plus 1 year"

    # CSS et JS : cache 1 mois
    # Utilisez un hash dans le nom de fichier pour invalider le cache
    # ex: styles.a1b2c3.css
    ExpiresByType text/css            "access plus 1 month"
    ExpiresByType application/javascript "access plus 1 month"

    # HTML : pas de cache long (contenu dynamique)
    ExpiresByType text/html           "access plus 1 hour"
</IfModule>

# ============================================================
# En-têtes Cache-Control complémentaires
# ============================================================
<IfModule mod_headers.c>
    # Activer le revalidation pour CSS/JS versionnés
    <FilesMatch "\.(css|js)$">
        Header set Cache-Control "public, max-age=2592000, stale-while-revalidate=86400"
    </FilesMatch>

    # Ressources immuables (avec hash dans le nom)
    <FilesMatch "\.[a-f0-9]{8,}\.(css|js)$">
        Header set Cache-Control "public, max-age=31536000, immutable"
    </FilesMatch>
</IfModule>

Defer et async sur les scripts

La différence entre defer et async est fondamentale pour éviter le render-blocking :

<!-- =====================================================
     SCRIPTS RENDER-BLOCKING (à éviter absolument)
     Le navigateur stoppe le parsing HTML jusqu'à la fin
     du téléchargement et de l'exécution du script.
===================================================== -->
<!-- ❌ MAUVAIS : bloque le rendu -->
<script src="analytics.js"></script>

<!-- =====================================================
     DEFER : téléchargement en parallèle du parsing HTML,
     exécution après que le DOM est prêt.
     Ordre d'exécution respecté entre scripts defer.
     ✅ Recommandé pour les scripts qui dépendent du DOM.
===================================================== -->
<script src="app.js" defer></script>
<script src="components.js" defer></script>
<!-- app.js s'exécute toujours avant components.js -->

<!-- =====================================================
     ASYNC : téléchargement en parallèle du parsing HTML,
     exécution dès que le fichier est disponible.
     Ordre d'exécution non garanti entre scripts async.
     ✅ Recommandé pour les scripts indépendants (analytics,
     trackers, widgets tiers).
===================================================== -->
<script src="https://www.googletagmanager.com/gtag/js" async></script>

Preload de la police principale

Le preload des polices évite le FOUT (Flash of Unstyled Text) et améliore le LCP en priorisant le chargement des ressources critiques :

<!-- Dans le <head>, AVANT la balise <link rel="stylesheet"> -->

<!-- Preload de la police principale (woff2 uniquement : format moderne et compact) -->
<link
  rel="preload"
  href="/fonts/manrope-variable.woff2"
  as="font"
  type="font/woff2"
  crossorigin="anonymous"
>
<!-- crossorigin="anonymous" est OBLIGATOIRE pour les polices,
     même si elles sont hébergées sur votre propre domaine -->

<!-- Preconnect au CDN de polices (Google Fonts) pour réduire la latence DNS -->
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

<!-- Preload de l'image LCP (si connue à l'avance) -->
<link
  rel="preload"
  href="/assets/images/hero.webp"
  as="image"
  type="image/webp"
>

Outils complémentaires à PageSpeed Insights

PageSpeed Insights est excellent pour un diagnostic rapide, mais d'autres outils apportent des perspectives complémentaires indispensables pour une optimisation avancée.

Automatiser avec Lighthouse CLI en CI/CD

Lighthouse peut être intégré dans votre pipeline GitHub Actions pour bloquer un déploiement si le score descend en dessous d'un seuil défini :

# Exemple de job GitHub Actions pour auditer les performances
# Déclenché sur chaque Pull Request vers main

name: Lighthouse Performance Audit

on:
  pull_request:
    branches: [main]

jobs:
  lighthouse:
    runs-on: ubuntu-latest
    steps:
      # Checkout du code source
      - uses: actions/checkout@v4

      # Déploiement préview (adapter à votre stack)
      - name: Deploy preview
        run: echo "Déploiement de la préview ici"

      # Audit Lighthouse avec seuils minimum
      - name: Run Lighthouse CI
        uses: treosh/lighthouse-ci-action@v11
        with:
          # URL de la préview à auditer
          urls: |
            https://preview.mon-site.com/
            https://preview.mon-site.com/ma-page-importante/
          # Seuils minimum (échec si en dessous)
          budgetPath: ./lighthouse-budget.json
          uploadArtifacts: true # Sauvegarde les rapports HTML

// lighthouse-budget.json
// Définit les seuils de performance acceptables
[
  {
    "path": "/*",
    "scores": {
      // Score Lighthouse minimum autorisé (0–1)
      "performance": 0.8,    // 80/100 minimum
      "accessibility": 0.9,  // 90/100 minimum
      "best-practices": 0.9,
      "seo": 0.9
    }
  }
]

Chrome DevTools — onglet Coverage

L'onglet Coverage (accessible via Ctrl+Shift+P → "Show Coverage") analyse quel pourcentage de votre CSS et JavaScript est réellement utilisé sur la page. Un taux élevé de code inutilisé (rouge) est un candidat idéal au tree-shaking ou au code-splitting.

Conclusion & checklist pratique

Google PageSpeed Insights est bien plus qu'un simple outil de mesure de vitesse. C'est un audit complet de l'expérience utilisateur, directement relié aux signaux de classement Google. En maîtrisant ses métriques — LCP, INP, CLS, FCP, TTFB, TBT — et en appliquant les optimisations dans le bon ordre de priorité, vous améliorez simultanément votre SEO, votre taux de conversion et la satisfaction de vos utilisateurs.

Commencez toujours par les images et le render-blocking JavaScript : ce sont les deux leviers qui apportent les gains les plus rapides et les plus mesurables. Intégrez ensuite un audit automatique dans votre pipeline CI/CD pour garantir que les performances ne régressent jamais entre deux déploiements.

Checklist finale

• Analyser la page avec PSI sur mobile et desktop.
• Vérifier les Core Web Vitals (LCP, INP, CLS) dans la section "Données de terrain".
• Convertir toutes les images en WebP ou AVIF.
• Ajouter loading="lazy" sur les images hors viewport.
• Définir width et height sur toutes les balises <img>.
• Ajouter defer ou async sur tous les scripts non-critiques.
• Activer la compression Gzip ou Brotli côté serveur.
• Configurer les en-têtes Cache-Control pour les ressources statiques.
• Preloader la police principale et l'image LCP.
• Valider la note d'accessibilité Lighthouse (min. 90/100).
• Intégrer Lighthouse CI dans le pipeline pour éviter les régressions.