WebSentinel atteint 98/100 sur Google PageSpeed Insights : décryptage de nos Core Web Vitals

Un chiffre que peu d'agences web osent afficher publiquement

Nous allons vous montrer quelque chose que la plupart des agences web évitent soigneusement : les performances réelles de leur propre site.

Voici les scores de websentinel.fr mesurés sur Google PageSpeed Insights en février 2026 :

• Performance : 98/100
• Accessibilité : 100/100
• Bonnes pratiques : 100/100
• SEO : 100/100

Et surtout, les métriques qui comptent vraiment :

Métrique	Score	Seuil Google "Bon"
First Contentful Paint (FCP)	1,2 s	< 1,8 s ✅
Largest Contentful Paint (LCP)	2,3 s	< 2,5 s ✅
Total Blocking Time (TBT)	20 ms	< 200 ms ✅
Cumulative Layout Shift (CLS)	0	< 0,1 ✅
Speed Index	1,6 s	< 3,4 s ✅

Ces résultats ne sortent pas de nulle part. Ils sont le fruit d'une démarche d'optimisation technique rigoureuse et continue. Dans cet article, nous allons décrypter ce que signifient ces métriques, pourquoi elles comptent pour votre SEO, et comment nous les avons atteintes.

Pourquoi ces métriques comptent (vraiment) pour votre référencement

Depuis mai 2021, Google intègre les Core Web Vitals dans son algorithme de classement. Ce n'est pas une option : c'est un signal de ranking officiel, au même titre que les backlinks ou la qualité du contenu.

Les Core Web Vitals mesurent trois dimensions fondamentales de l'expérience utilisateur :

1. La vitesse de chargement — LCP (Largest Contentful Paint)
2. La réactivité — TBT (Total Blocking Time, proxy de l'INP)
3. La stabilité visuelle — CLS (Cumulative Layout Shift)

Un site qui performe mal sur ces trois axes sera pénalisé dans les résultats de recherche, même si son contenu est excellent. Google considère qu'une mauvaise expérience technique nuit à l'utilisateur, et son algorithme s'en souvient.

Décryptage métrique par métrique

First Contentful Paint (FCP) — 1,2 s

Le FCP mesure le temps entre le premier octet reçu et l'affichage du premier élément visible à l'écran (texte, image, SVG). C'est la première impression de votre visiteur.

Notre score : 1,2 s — seuil Google "bon" : < 1,8 s.

Pour atteindre ce résultat, nous avons supprimé tous les fichiers CSS externes bloquants en les intégrant directement dans le HTML (technique inlineStylesheets), préchargé les polices critiques avec une balise <link rel="preload">, et servi le site depuis un serveur bare-metal en France pour limiter la latence réseau.

Largest Contentful Paint (LCP) — 2,3 s

Le LCP est la métrique phare des Core Web Vitals. Elle mesure le temps d'affichage du plus grand élément visible de la page — généralement une image hero ou un bloc de texte principal.

Notre score : 2,3 s — seuil Google "bon" : < 2,5 s.

C'est souvent ici que les sites échouent. Une image hero non optimisée, un serveur lent ou une chaîne de redirections inutile peut faire basculer le LCP dans le rouge.

Nos optimisations pour le LCP :

• Image hero servie en format WebP et AVIF, formats de nouvelle génération bien moins lourds que le JPEG
• Attribut fetchpriority="high" pour signaler au navigateur de charger l'image hero en priorité absolue
• Rendu HTML côté serveur avec Astro SSR : pas de JavaScript à exécuter avant d'afficher le contenu
• Suppression des attributs will-change et translateZ superflus qui, contrairement à une idée reçue, peuvent dégrader le LCP en ajoutant des couches GPU inutiles

Total Blocking Time (TBT) — 20 ms

Le TBT mesure la somme de tous les intervalles pendant lesquels le fil principal du navigateur est bloqué plus de 50 ms. Un fil principal bloqué, c'est une page qui ne répond pas aux clics et aux scrolls.

Notre score : 20 ms — seuil Google "bon" : < 200 ms. Soit dix fois sous le seuil.

C'est notre résultat le plus remarquable, car notre site charge pourtant : Google Tag Manager, Google Analytics 4, un pixel Facebook, un script Cal.com, et récupère dynamiquement des avis Google Places en temps réel.

Comment avons-nous maintenu le fil principal libre ?

• requestIdleCallback : les avis Google sont récupérés uniquement pendant les temps morts du navigateur, sans jamais bloquer l'affichage initial
• ResizeObserver au lieu d'offsetWidth : toutes les lectures de propriétés géométriques forcées ont été remplacées par des observateurs asynchrones
• Animations GPU-composited : nos animations CSS utilisent filter: brightness() au lieu de background-position, ce qui délègue le calcul au GPU et libère entièrement le fil principal

Cumulative Layout Shift (CLS) — 0

Le CLS quantifie les décalages visuels inattendus pendant le chargement. Vous connaissez ce phénomène : vous vous apprêtez à cliquer sur un bouton, et au dernier moment une image se charge et décale tout vers le bas.

Notre score : 0 — score parfait (seuil "bon" : < 0,1).

Pour éliminer tout décalage visuel, toutes nos images possèdent des attributs width et height explicites extraits depuis les métadonnées Strapi. Les polices sont préchargées pour éviter le flash de texte non stylisé, et les éléments dynamiques ont des dimensions réservées dès le rendu initial.

La stack technique qui rend ces performances possibles

Astro 5 en mode SSR

Astro est un framework JavaScript dont le principe fondateur est le zéro JavaScript par défaut. Contrairement à React ou Vue qui envoient tout le framework au navigateur pour générer le HTML côté client, Astro génère le HTML côté serveur et n'envoie du JavaScript que pour les composants interactifs qui en ont réellement besoin.

Strapi 5 comme CMS headless

Strapi sert exclusivement d'API de données. Il ne génère pas de HTML. Le frontend Astro interroge Strapi à chaque requête utilisateur et génère le HTML optimal. Cette séparation stricte entre gestion de contenu et affichage frontend — l'architecture headless — est fondamentale pour les performances.

Traefik comme reverse proxy

Notre infrastructure Docker utilise Traefik, qui gère les certificats SSL automatiquement, applique des headers de sécurité HTTP (CSP, HSTS, COOP), compresse les réponses en Brotli, et sert les assets Strapi avec un cache de 365 jours côté navigateur.

Les 5 pièges qui sabotent les Core Web Vitals

Après avoir audité des dizaines de sites clients, voici les erreurs les plus fréquentes.

1. Croire que les plugins de cache règlent tout

WP Rocket, W3 Total Cache, LiteSpeed Cache... Ces plugins peuvent améliorer marginalement un site WordPress, mais ils ne compensent pas une architecture fondamentalement lourde. Un site avec 40 plugins restera lent, quoi qu'il arrive.

2. Les images sans dimensions

Le simple fait d'omettre width et height sur une balise <img> peut provoquer un CLS important. Le navigateur ne sait pas quelle place réserver, et quand l'image se charge, elle pousse tout le contenu vers le bas.

3. Les scripts tiers non différés

Google Analytics, pixels publicitaires, scripts de chat... Chargés en synchrone, ils bloquent le fil principal et font exploser le TBT. La solution : requestIdleCallback, loading="lazy", ou chargement conditionnel après la première interaction utilisateur.

4. Les animations CSS non-composited

Animer background-position, top, left ou width/height force le navigateur à recalculer toute la mise en page à chaque frame. C'est ce qu'on appelle un forced layout reflow, et c'est dévastateur pour les performances. Préférez transform et filter, gérés directement par le GPU.

5. Tester uniquement sur desktop

Un score PageSpeed mesuré sur desktop n'est pas représentatif. Google mesure les Core Web Vitals sur les appareils mobiles réels de vos visiteurs. Testez toujours en mode mobile, avec throttling réseau activé.

Ce que ça signifie concrètement pour votre business

Des Core Web Vitals au vert, c'est :

• Un meilleur classement Google sur vos mots-clés cibles
• Un taux de rebond plus faible : 53 % des visites mobiles sont abandonnées si le chargement dépasse 3 secondes (Google)
• Un meilleur taux de conversion : 100 ms de latence supplémentaire coûtent 1 % de ventes (Amazon)
• Une meilleure expérience utilisateur : votre site reflète le soin que vous apportez à votre métier

Mot de la fin

Atteindre 98/100 sur un site de production avec animations, CMS headless, scripts analytics et avis clients dynamiques n'est pas le fruit du hasard. C'est le résultat de décisions architecturales précises, d'optimisations ciblées, et d'une culture de la performance à chaque étape du développement.

Chez WebSentinel, nous appliquons ces standards à tous les sites que nous créons pour nos clients. Parce qu'un beau site qui charge en 4 secondes, c'est un site qui perd des clients.

Vous souhaitez savoir où se situe votre site actuel ? Nous réalisons des audits de performance gratuits. Contactez-nous pour un diagnostic complet de vos Core Web Vitals.