Skip to content

Optimiser le LCP sur WordPress : 5 leviers concrets

Louis Louis Performance
WordPress
4 min

Le LCP (Largest Contentful Paint) mesure le temps que met le plus gros élément visible (image hero, bloc de texte principal, vidéo) à s’afficher dans la fenêtre. Cible : moins de 2,5 secondes au 75ᵉ percentile des visiteurs réels. Sur WordPress non optimisé, c’est presque toujours la métrique la plus rouge.

Voici les cinq leviers que nous appliquons systématiquement chez Rankea, par ordre d’impact décroissant. Les trois premiers sont rentables sur la quasi-totalité des sites ; les deux derniers exigent un audit pour valider qu’ils s’appliquent à votre cas.

1. Précharger l’image hero et lui donner la priorité

L’image hero est l’élément LCP par défaut sur 80 % des fiches articles. Deux balises suffisent pour gagner 400 à 900 ms.

  • <link rel="preload" as="image" href="..." imagesrcset="..." imagesizes="..."> dans le <head>
  • fetchpriority="high" sur le <img> correspondant
  • loading="eager" (inverse du lazy par défaut depuis WordPress 5.5)

Le navigateur démarre le téléchargement avant même de parser le DOM. Sur fibre, l’image est souvent décodée avant le render — gain quasi gratuit.

2. Servir l’image au format WebP ou AVIF

Une JPEG de 250 KB devient une WebP de 90 KB ou une AVIF de 50 KB pour une qualité visuelle identique. Sur une connexion 4G, ça représente entre 200 et 500 ms de moins sur le LCP.

WordPress 6.5+ génère automatiquement des WebP quand on uploade une image (configurable via le filtre wp_image_editor_output_format). Pour AVIF, il faut un plugin comme Modern Image Formats ou un service côté serveur (Cloudflare Polish, Bunny Optimizer).

Le format compte plus que la taille de l’image. Une AVIF 1600px pèse moins qu’une JPEG 800px optimisée.

3. Auto-héberger les fonts critiques

Google Fonts via CDN coûte entre 200 et 400 ms sur le LCP : DNS lookup, TLS handshake, fetch CSS, fetch font, parsing. Auto-hébergées, vos fonts partent en parallèle de l’image hero, depuis le même domaine que le HTML.

  • Téléchargez les WOFF2 nécessaires (regular + bold du H1, weights utiles uniquement)
  • Stockez-les dans themes/votre-thème/resources/assets/fonts/
  • Déclarez-les en @font-face avec font-display: swap
  • Précharchez la fonte du H1 via <link rel="preload" as="font" type="font/woff2" crossorigin>

Vous économiserez aussi un appel fonts.gstatic.com qui pollue Network DevTools.

4. Activer un cache de pages serveur

Sans cache, chaque visite déclenche : démarrage PHP, chargement des plugins, requêtes WordPress, rendu Gutenberg. Sur mutualisé, ça représente 400 à 1 200 ms de TTFB. Tout ce temps est perdu avant même que le navigateur reçoive le premier octet — donc avant tout LCP optimisable côté front.

Trois familles d’outils :

  • Plugin de cache (WP Rocket, LiteSpeed Cache, W3 Total Cache) : génère des fichiers HTML statiques servis sans toucher PHP
  • Reverse proxy (Varnish, NGINX FastCGI cache) : intercepte les requêtes au niveau serveur web, encore plus rapide
  • Edge cache (Cloudflare APO, Bunny CDN) : sert les pages depuis le PoP le plus proche du visiteur

Cible TTFB après cache : moins de 200 ms. C’est souvent l’optimisation au plus gros ratio gain/effort.

5. Désactiver les plugins inutiles au runtime

Chaque plugin actif ajoute en moyenne 80 ms au TTFB. Un site qui a 47 plugins actifs en démarre 47 à chaque hit, même si seulement 3 sont réellement utilisés sur la page courante.

Audit en 3 étapes :

  1. Lister les plugins actifs et leur usage réel sur les pages publiques (Query Monitor donne une vue par page)
  2. Désinstaller ceux qui ne servent que pour des features admin (analytics côté admin, backups, etc. peuvent souvent passer en cron côté serveur)
  3. Pour ceux qui restent, utiliser un plugin comme Asset CleanUp pour conditionnellement désactiver leurs CSS/JS sur les pages où ils ne sont pas utilisés

Mesurer avant et après

PageSpeed Insights donne une mesure laboratoire utile pour spotcheck, mais Google classe sur les données réelles d’utilisateurs (RUM) agrégées dans Chrome User Experience Report (CrUX). Comptez 14 jours d’agrégation pour voir l’effet d’une optimisation.

Pour suivre le LCP en continu, déployez web-vitals.js (5 KB) qui pousse les métriques vers votre stack analytics. C’est ce qui sépare une optimisation à l’aveugle d’une démarche outillée.

Besoin d’un audit LCP sur votre site WordPress ? Contactez-nous pour une analyse gratuite en 48 heures.