Core Web Vitals : passer de 50 à 95 en trois semaines

Il y a peu encore, la performance web était un "nice-to-have" qu'on traitait en fin de projet. Depuis que Google a intégré les Core Web Vitals au signal de classement, et depuis que les études d'Amazon, Walmart, Vodafone montrent toutes la même courbe (chaque 100 ms de latence = 1% de conversion perdue), la performance est devenue un sujet de direction.

Chez Vortex, nous auditons régulièrement des sites qui démarrent autour de 40–55 en mobile sur PageSpeed Insights. En trois semaines, nous les faisons passer à 90+ sans refonte complète. Voici la méthode.

1. Mesurer avant de toucher

La première erreur : optimiser au jugé. Nous commençons systématiquement par poser des métriques stables :

• Lighthouse CI dans la pipeline (échantillonné sur 5 runs, médiane conservée)
• Real User Monitoring (Vercel Analytics, Cloudflare Web Analytics, ou notre pipeline OpenTelemetry)
• Calibrage 4G pour écarter le bruit du wifi de bureau

On ne commit rien sans comparer avant/après sur ces trois canaux. Trop de projets voient Lighthouse grimper de 10 points pendant que le RUM reste à plat — signe qu'on a optimisé un laboratoire, pas la réalité.

2. Le TTFB : tout commence là

Time to First Byte est le plafond de tout le reste. Si votre serveur met 800 ms à répondre, aucun LCP sous les 2,5 s n'est possible. Nos leviers :

• Edge rendering (Vercel Edge, Cloudflare Workers, Netlify Edge) : la requête est traitée à 30 ms du visiteur au lieu de 250 ms
• ISR ou cache stale-while-revalidate pour tout contenu qui change moins d'une fois par minute
• Hydratation différée sur Nuxt 3 (<NuxtLazyHydrate>) pour ne pas bloquer sur du JS non critique

Résultat typique : TTFB passe de 650 ms à 90 ms. La moitié du travail est faite.

3. Le LCP : l'image héro est (presque) toujours coupable

Sur 9 projets sur 10, le LCP est une image. Les réflexes :

• Format moderne systématique (AVIF en priorité, WebP en fallback)
• fetchpriority="high" sur le héro pour que le navigateur le préempte
• preload dans le head avec le bon imagesrcset
• Dimensions explicites pour éviter les CLS en cascade
• Flou progressif (BlurHash ou LQIP) pendant le chargement

Sur un site e-commerce récent, cette seule discipline a fait passer le LCP de 3,8 s à 1,2 s.

4. Le JS : élaguer, différer, découper

Le Total Blocking Time ne se débloque pas en magie. Trois règles :

1. Une seule dépendance à la fois : chaque ajout de lib doit justifier son poids. moment.js → date-fns → Intl natif. lodash entier → imports nominaux. animation framework lourd → CSS + motion-v ciblé.
2. Lazy-loader tout ce qui est below-the-fold. Les composants marketing ne doivent pas charger la logique du dashboard.
3. Tree-shaking vérifié. @nuxt/analyzer ou source-map-explorer révèle toujours des surprises.

Sur un projet Next.js de 450 KB de JS sur la home, nous avons coupé à 180 KB en trois jours. Le FID est passé sous les 50 ms.

5. Les fonts : le détail qui compte

Webfonts via Google Fonts en direct, c'est fini. Nous utilisons :

• font-display: swap pour ne plus bloquer le rendu
• Fonts auto-hébergées avec preload et crossorigin
• Subsets latin uniquement quand la cible est FR/EN
• Fallback métrique via size-adjust pour éviter le CLS sur le swap

Gain visible sur le FCP : 150 à 300 ms.

6. Le CLS : la rigueur

CLS < 0,1 se gagne à la discipline : toutes les images avec width/height, toutes les iframes avec des placeholders réservés, jamais d'injection de contenu au-dessus du header. Banner de cookie ? En bas. Bannière promo ? Hauteur réservée avant même son arrivée.

Le vrai ROI

Sur notre dernier audit client (SaaS B2B, 40 000 sessions/mois) :

Trois semaines, pas de refonte, un ROI calculable sur le trimestre suivant.

La performance, c'est rarement un problème de compétence rare. C'est un problème de discipline mesurée appliquée aux bons leviers, dans le bon ordre.

Vous voulez qu'on audite votre stack ? On livre un rapport chiffré en 48 heures.