PageSpeed Insights : Optimiser la vitesse de votre site pour le SEO

Les Core Web Vitals sont trois métriques qui mesurent l'expérience utilisateur réelle. Elles constituent un facteur de classement Google depuis 2021 et sont evaluees à partir des données de terrain collectées par le Chrome User Experience Report.

Le LCP (Largest Contentful Paint) mesure le temps de chargement perçu : c'est le moment où le plus grand élément visible (image hero, bloc de texte principal) s'affiche à l'écran. Les causes fréquentes d'un mauvais LCP sont les images non optimisées, un temps de réponse serveur lent (TTFB élevé) et le chargement tardif des polices web.

L'INP (Interaction to Next Paint) a remplace le FID en mars 2024. Il mesure la réactivité globale de la page en evaluant la latence de toutes les interactions utilisateur (clics, pressions, saisies clavier), pas seulement la première. Un mauvais INP est généralement cause par du JavaScript lourd qui bloque le thread principal du navigateur.

Le CLS (Cumulative Layout Shift) mesure la stabilité visuelle : les décalages inattendus de contenu pendant le chargement. Les causes typiques sont les images sans dimensions définies, les publicites dynamiques et les polices web qui provoquent un flash de texte invisible (FOIT).

La section "Diagnostics" de PSI fournit des recommandations concrètes classees par impact potentiel. Chaque recommandation indique le gain estime en millisecondes. Commencez toujours par les éléments à fort impact pour maximiser vos gains avec un effort minimal.

Les problèmes les plus fréquents identifiés par PSI sont :

• "Eliminate render-blocking resources" : fichiers CSS et JavaScript qui bloquent le rendu initial de la page. Le navigateur doit télécharger et parser ces fichiers avant d'afficher quoi que ce soit. Differez le chargement des scripts non critiques avec les attributs async ou defer
• "Serve images in next-gen formats" : utiliser WebP ou AVIF au lieu de JPEG/PNG. Ces formats modernes offrent une compression supérieure a qualité égale, reduisant significativement le poids des images
• "Reduce unused JavaScript" : code JS charge mais non utilisé sur la page courante. Ce problème est fréquent avec les librairies lourdes importees en entier alors que seules quelques fonctions sont utilisées
• "Properly size images" : images affichees à une taille inférieure à leur taille native. Charger une image de 2000px pour l'afficher dans un conteneur de 400px gaspille de la bande passante

PSI identifié aussi les problèmes de performance serveur via le TTFB (Time to First Byte). Un TTFB supérieur a 600ms indique un problème côté serveur : hébergement insuffisant, absence de cache ou requêtes base de données trop lentes. C'est souvent le premier goulot d'etranglement a résoudre.

La section "Arborescence" montre la taille de chaque ressource chargee et le temps passe à les traiter. Utilisez-la pour identifier les scripts tiers (analytics, chat, publicites) qui alourdissent votre page. Un site bien optimisé ne devrait pas charger plus de 200 Ko de JavaScript au total pour la page initiale.

Les images sont souvent le premier levier d'optimisation. Sur un site moyen, elles représentent 50 à 70% du poids total de la page. Trois actions ont le plus d'impact pour réduire ce poids et améliorer votre score de performance.

Premierement, utilisez des formats modernes. WebP offre une réduction de 25 à 30% par rapport au JPEG a qualité égale, et AVIF va encore plus loin avec 40 à 50% de réduction. Ces formats sont désormais supportes par tous les navigateurs modernes.

Deuxiemement, dimensionnez vos images correctement. Ne chargez pas une image de 2000 pixels de large pour l'afficher dans un conteneur de 400 pixels. Utilisez l'attribut srcset et l'élément picture pour servir la bonne taille selon le viewport. Avec Next.js, le composant next/image géré automatiquement le redimensionnement, la conversion en WebP et la génération du srcset.

Troisiemement, implementez le lazy loading pour les images situees en dessous de la ligne de flottaison. L'attribut loading="lazy" sur les balises img est supporte par tous les navigateurs modernes et differe le chargement des images hors viewport.

Attention : ne jamais appliquer le lazy loading à l'image LCP (hero image), car cela retarderait son chargement et degraderait votre score. Utilisez loading="eager" et fetchpriority="high" pour l'image hero afin de la prioriser dans l'ordre de chargement du navigateur.

Le JavaScript est le principal responsable des problèmes d'INP et de LCP sur les sites modernes. PSI identifié le CSS et JS non utilisé via les audits "Reduce unused CSS" et "Reduce unused JavaScript". Plusieurs stratégies permettent de réduire cette charge.

Le code splitting consiste à découper votre JavaScript en modules charges à la demande. Avec Next.js, le code splitting est automatique par route, mais les imports de librairies lourdes dans les composants partages peuvent annuler ce bénéfice. Utilisez les imports dynamiques (dynamic import) pour les composants lourds visibles uniquement après interaction (modales, carousels, éditeurs).

Le tree shaking éliminé le code mort lors du build, à condition d'utiliser des imports nommes plutôt que des imports par défaut de librairies complètes :

• Bon : import { motion } from 'framer-motion' -- seul le code de motion est inclus dans le bundle final
• Mauvais : import * as FramerMotion from 'framer-motion' -- l'ensemble de la librairie est embarque même si vous n'utilisez qu'une fraction

Pour le CSS, Tailwind CSS est nativement optimisé : le mode JIT ne généré que les classes effectivement utilisées dans votre code. Évitez cependant de charger des feuilles de style tierces complètes (Bootstrap, Material UI) en parallele de Tailwind, cela double le poids CSS sans bénéfice.

Auditez régulièrement vos dépendances avec des outils comme bundle-analyzer pour identifier les modules qui pesent le plus dans votre bundle. Un audit trimestriel permet de détecter les derives avant qu'elles n'impactent significativement la performance.

PSI affiche deux types de données et il est crucial de comprendre la différence pour interpréter correctement les résultats et prioriser vos optimisations.

Les données de terrain ("Données sur le terrain" ou "Field Data") proviennent du Chrome User Experience Report (CrUX). Elles représentent l'expérience réelle des visiteurs Chrome au cours des 28 derniers jours. Ces données sont agregees au 75e percentile, ce qui signifie que 75% de vos visiteurs ont une expérience égale ou meilleure que la valeur affichee. Ce sont ces données que Google utilisé comme facteur de classement.

Les données de laboratoire ("Données de la phase de diagnostic") sont générées par Lighthouse dans un environnement contrôle : un appareil mobile simule (Moto G Power) avec une connexion 4G throttlee. Elles sont reproductibles et détaillées, idéales pour le diagnostic technique, mais ne refletent pas forcement l'expérience réelle de vos visiteurs.

Un écart entre terrain et laboratoire est normal et même fréquent. Voici comment interpréter les différents scenarios :

• Terrain bon + Laboratoire faible : ne paniquez pas. Vos visiteurs réels ont une bonne expérience. Les conditions de test Lighthouse sont plus sévères que la realite de votre audience. Optimisez progressivement mais sans urgence
• Terrain mauvais + Laboratoire bon : situation preoccupante. Vos visiteurs réels souffrent malgré un score de laboratoire correct, probablement parce que votre audience utilisé des appareils où des connexions moins performants que la simulation Lighthouse. Priorite haute
• Terrain mauvais + Laboratoire mauvais : situation critique. Les problèmes de performance sont réels et confirmes. Lancez un plan d'optimisation immediat en commencant par les recommandations a plus fort impact dans le diagnostic PSI
• Terrain bon + Laboratoire bon : situation idéale. Maintenez vos bonnes pratiques et surveillez régulièrement pour éviter les regressions lors des mises à jour du site

Notez que les données de terrain ne sont disponibles que pour les sites avec un volume de trafic suffisant dans le CrUX. Les sites récents ou à faible audience devront s'appuyer exclusivement sur les données de laboratoire en attendant d'accumuler assez de visites Chrome pour générer des données de terrain fiables.