Un LCP qui passe de 4 à 2 secondes fait remonter les conversions e-commerce de 8 à 15 % selon le secteur. Un TTFB divisé par 3 avec un CDN sérieux, c’est 200 à 500 ms gagnés sur toute la page. Voici les 20 leviers qui produisent ce type de résultat en 2026, dans l’ordre où je les applique en mission.
Tes images : là où le LCP se joue
Sur la majorité des sites, l’image est l’élément LCP. C’est donc elle qui décide de ton score sur la métrique la plus regardée par Google. Cinq astuces à appliquer dans cet ordre.
1. Identifie ton image LCP avant de toucher à quoi que ce soit
Chrome DevTools > Performance > recharge la page > cherche le marqueur « LCP ». C’est cet élément qu’il faut optimiser, pas les 40 autres images de la page.
2. Passe tes images en AVIF, WebP en fallback
AVIF réduit le poids de 30 à 50 % vs WebP, et de 50 à 70 % vs JPEG. Cloudflare Polish, Cloudinary, Vercel Image Optimization ou Imagify (WordPress) le font automatiquement selon le navigateur.
3. Ajoute fetchpriority="high" sur l’image LCP
Une ligne de code, gain typique de 200 à 500 ms sur les tests en champ. À combiner avec <link rel="preload"> dans le <head> si l’image est chargée en CSS background.
4. Renseigne width et height sur toutes les images
Sans ces attributs, le navigateur ne peut pas réserver l’espace avant chargement. Résultat : layout shift (mauvais CLS) plus retard sur le LCP. Deux Core Web Vitals gagnés avec deux attributs.
5. Lazy loading sur les images below-the-fold, jamais sur la LCP
loading="lazy" accélère les images du bas de page. Appliqué à l’image LCP, il la ralentit. C’est un contresens classique.
Ton JavaScript : la vraie bataille de l’INP
Depuis mars 2024, l’INP a remplacé le FID comme Core Web Vital d’interactivité. C’est aussi la métrique la plus échouée en 2026, surtout sur les stacks React, Next.js, Vue. Quatre astuces qui font la différence.
6. Diffère tout ce qui n’est pas essentiel au premier rendu
Analytics, Tag Manager, chat widgets, pixels publicitaires : defer ou async sur toutes les balises <script> qui ne servent pas à afficher la page. Un tag manager bien configuré fait le tri sans toucher au code.
7. Découpe les long tasks JavaScript
Une long task, c’est un bout de JS qui bloque le thread principal plus de 50 ms. Tant qu’elle tourne, aucune interaction utilisateur n’est traitée. Solutions : scheduler.postTask() pour découper explicitement, un Web Worker pour tout calcul lourd (parsing, tri, filtre).
8. Allège la charge d’hydratation sur les frameworks JS
Sur Next.js, Nuxt, SvelteKit, l’hydratation initiale peut faire exploser l’INP dans les 3 premières secondes après le chargement. La réponse 2026 : envoyer moins de JS au client. React Server Components, îlots interactifs Astro, tout ce qui allège la facture marche.
9. Nettoie les scripts tiers inactifs
Combien de pixels de campagnes finies il y a 6 mois, combien de widgets abandonnés, combien de balises analytics doublonnées ? Chaque script tiers coûte des millisecondes. Le nettoyage régulier est le premier levier gratuit.
Ton CSS et ton rendu
Zone moins spectaculaire, gains réels quand c’est mal fait. Trois astuces.
10. Inline le CSS critique dans le head
Le CSS critique, c’est le style nécessaire pour afficher la partie visible above-the-fold. L’inliner dans le <head> évite un aller-retour réseau et accélère le LCP. Sur WordPress, WP Rocket le fait via l’option « Optimize CSS delivery » en mode « Load CSS asynchronously ».
11. Utilise font-display: swap ou optional
Sans cette propriété, ton texte reste invisible tant que la police web ne charge pas (FOIT). swap affiche immédiatement une police système en attendant. optional va plus loin en gardant la police système si la police web tarde. Zéro layout shift, texte lisible en 0 ms.
12. Précharge tes polices essentielles
Dans le <head> :
<link rel="preload" href="/fonts/ta-font.woff2" as="font" type="font/woff2" crossorigin>Pour tes 2 ou 3 polices utilisées above-the-fold. Le navigateur les charge en parallèle du reste, sans attendre de les découvrir dans le CSS.
Ton serveur, ton réseau, ton TTFB
Le Time To First Byte, c’est ce qui se passe avant que le navigateur commence à rendre quoi que ce soit. Un TTFB au-dessus de 800 ms plombe tout ce qui suit. Quatre astuces.
13. Passe ton site derrière un CDN
Cloudflare (gratuit ou Pro), Fastly, Vercel Edge, Bunny CDN. Un CDN sert tes fichiers statiques depuis un serveur proche du visiteur. Divise le TTFB par 2 à 5 selon ton hébergement d’origine. Chantier de 2 heures qui change tout.
14. Active HTTP/2 ou HTTP/3
Ces protocoles chargent plusieurs ressources en parallèle sur une seule connexion, là où HTTP/1.1 les enchaîne. La plupart des hébergeurs sérieux le proposent en un clic dans le back-office. Vérifie que c’est activé.
15. Utilise un DNS rapide
Un DNS lent ajoute 100 à 300 ms au premier contact avec ton site. Cloudflare DNS (1.1.1.1) ou Google DNS (8.8.8.8), gratuits, gain immédiat.
16. Adapte ton hébergement à ton trafic
Un mutualisé à 5 €/mois convient à 500 visites/jour. À 5 000 visites/jour à l’heure de pointe, il craque : le TTFB monte, les timeouts arrivent, le SEO en souffre. Un VPS ou un hébergement managé (Kinsta, WP Engine, o2switch Cloud) devient rentable dès que ton business en dépend.
Les petits gains cumulés
Trois chantiers moins spectaculaires, mais qui grattent chacun quelques dizaines de millisecondes.
17. Configure le cache navigateur avec des durées raisonnables
Un fichier CSS, JS ou image versionné qui ne change pas peut être mis en cache 1 an chez le visiteur. Configuration standard : header HTTP Cache-Control: max-age=31536000, immutable sur les assets versionnés.
18. Compresse avec Brotli plutôt que Gzip
Brotli compresse 15 à 25 % mieux que Gzip sur les fichiers texte (HTML, CSS, JS). Activé par défaut sur Cloudflare, configurable sur tous les serveurs modernes.
19. content-visibility: auto sur les sections below-the-fold
Cette propriété CSS dit au navigateur : ne rends pas cet élément tant qu’il n’est pas visible. Sur une page longue, ça réduit le rendu initial de 30 à 50 %. À tester section par section, certaines interactions (scroll, ancres) peuvent en souffrir.
L’astuce numéro 20 : arrêter de faire ces 2 choses
La meilleure astuce est peut-être celle qui te fait arrêter deux choses.
La minification agressive du JavaScript. Passer ton JS de 200 Ko à 190 Ko ne change rien à ta performance. Le vrai levier, c’est de charger moins de JavaScript, pas de le compresser plus fort. Une compression Brotli côté serveur suffit largement.
La course au score Lighthouse 100/100. Un site à 100/100 sur Lighthouse peut avoir ses Core Web Vitals en rouge dans la Search Console. Ce qui compte, c’est le field data (les données CrUX de tes vrais visiteurs), pas le lab data (le test Lighthouse simulé sur une machine dédiée).
Impact estimé par zone
Pour t’aider à prioriser, voici l’impact typique observé sur mes missions selon la zone attaquée en premier.
| Zone | Gain typique sur LCP/INP | Effort développeur |
|---|---|---|
| Images LCP (astuces 1 à 5) | -30 à -50 % sur le LCP | Faible (1 à 3 jours) |
| Serveur / CDN (astuces 13 à 16) | -20 à -40 % sur TTFB et LCP | Moyen (2 à 5 jours) |
| JavaScript (astuces 6 à 9) | -30 à -60 % sur INP | Élevé (2 à 4 semaines) |
| CSS / rendu (astuces 10 à 12) | -5 à -15 % sur LCP | Faible (1 à 2 jours) |
L’ordre d’attaque logique : les images d’abord (ROI maximal), le CDN ensuite, le JavaScript en dernier (le plus long).
Comment appliquer ça sur ton site
Sur WordPress. WP Rocket bien configuré, Cloudflare devant le site, Imagify pour la conversion AVIF. Ça couvre 80 % du travail des astuces ci-dessus, en une à deux journées développeur.
Sur React, Next.js, Vue ou site custom. L’INP demande un vrai chantier architectural, pas juste des optimisations de config. Prévois 2 à 4 semaines développeur pour un résultat solide.
Dans les deux cas, mesure avant et après avec la Search Console (rapport « Signaux web essentiels ») et PageSpeed Insights sur tes URLs stratégiques. Le lab data pour déboguer, le field data pour juger.
