De 77 à 100/100 : optimiser les Core Web Vitals d'un site, en vanilla
Un bon design ne suffit pas : si une page met quatre secondes à s'afficher sur mobile, Google la déclasse et les visiteurs partent. Voici, étape par étape, comment nous avons fait passer or-web.fr d'un score Google PageSpeed mobile de 77 à un 100/100 parfait — sans framework, en HTML/CSS/JS vanilla.
Le diagnostic
Le rapport était clair : FCP et LCP à 3,8 s sur mobile, là où Google considère « bon » en dessous de 1,8 s (FCP) et 2,5 s (LCP). Le serveur répondait vite (TTFB ≈ 0 ms) : le problème venait du chargement des ressources.
La cause principale : 13 requêtes HTTP bloquantes chargées dès le départ — 7 fichiers CSS et 6 fichiers JavaScript séparés. Chaque fichier était minuscule, mais sur le réseau mobile bridé, c'est le nombre de requêtes qui coûte cher (latence par connexion).
Les leviers actionnés
1. Réduire les requêtes : un build esbuild
Nous avons mis en place une étape de build (esbuild) qui concatène et minifie les 7 CSS en un seul fichier et les 6 JS en un seul autre. Les fichiers sources restent séparés pour le développement. Résultat : 13 requêtes bloquantes ramenées à 2. C'est le plus gros gain réseau.
2. Sortir Google Fonts du chemin critique
Les polices Google bloquaient l'affichage : un aller-retour vers fonts.googleapis.com (~750 ms) puis le téléchargement des fichiers. Nous les avons auto-hébergées (sous-ensemble latin, woff2 variables) et préchargées. Plus aucune requête tierce bloquante.
3. Peindre l'élément LCP immédiatement
L'élément le plus grand de la page (le titre du hero) était animé depuis opacity: 0. Tant que l'animation ne le rendait pas visible, Google ne comptait pas la page comme « affichée » — d'où un retard de ~2,5 s. Nous avons remplacé l'animation par un effet sans opacité : le texte est peint immédiatement.
4. Libérer le thread principal
Un canvas décoratif lançait un calcul de mise en page au démarrage (forced reflow de ~84 ms). Nous l'avons différé après le premier rendu (requestIdleCallback) : le Total Blocking Time tombe à 0 ms.
5. Accessibilité
En parallèle, nous avons corrigé l'accessibilité (attribut inert sur le menu mobile, repère <main>, contrastes conformes AA), faisant passer ce score de 89 à 100.
Le résultat
De 77 à 100 en performance. FCP 3,8 → 1,1 s. LCP 3,8 → 1,7 s. TBT 0 ms. CLS 0.
Et 100/100 également en accessibilité, bonnes pratiques et SEO. Le tout en restant 100 % vanilla : aucun framework, juste un outil de build. Vous pouvez le vérifier vous-même sur PageSpeed Insights.
Ce qu'il faut retenir
- Sur mobile, le nombre de requêtes compte souvent plus que leur poids.
- Les polices tierces sont un frein classique : auto-hébergez et préchargez.
- Une animation d'entrée sur l'élément LCP peut ruiner votre score sans qu'on s'en rende compte.
- Performance, accessibilité et SEO se renforcent mutuellement.
Votre site est lent ou mal classé ? Nous appliquons exactement cette méthode à votre projet. Découvrir notre service SEO & performance ou demander un audit gratuit.