Votre client a un site WordPress à 3,8s de LCP et vous ne savez pas par où commencer. Ce guide couvre le protocole dans l’ordre qui compte : hébergement, cache, images, JavaScript. Comptez 2 à 4 heures selon l’état de départ. Un LCP sous 2,5s et un TTFB sous 200ms sont atteignables sur la quasi-totalité des installations WordPress.
Selon les données CrUX du Web Almanac 2025, seulement 44% des sites WordPress mobiles passent les trois Core Web Vitals simultanément. Le LCP médian des sites bien configurés atteint pourtant 1,1s. L’écart entre les deux tiers se joue sur quatre points précis, dans un ordre précis.
Comprendre le vrai goulot d’étranglement avant d’installer un plugin
Avant de toucher à WP Rocket ou à Imagify, ouvrez Chrome DevTools sur la page d’accueil et regardez la cascade réseau. Trois indicateurs lisibles en 30 secondes :
- TTFB (Time to First Byte) : temps de réponse du serveur. Au-dessus de 600ms, le problème vient de l’hébergement, pas du cache WordPress.
- LCP (Largest Contentful Paint) : le plus gros élément visible à l’écran qui finit de charger. Souvent l’image hero ou le H1.
- INP (Interaction to Next Paint) : réactivité aux clics. Au-dessus de 200ms, du JavaScript excessif côté front est en cause.
Le piège classique ici : installer un plugin de cache en premier alors que le TTFB dépasse 900ms. Le cache WordPress ne peut pas compenser un serveur lent. Les données CrUX montrent que seulement 32% des sites WordPress ont un bon TTFB, contre 65% pour Shopify dont l’infrastructure est gérée à la source. Régler l’hébergement avant tout le reste est la condition pour que les optimisations suivantes aient un effet mesurable.
L’hébergement : le levier qui déplace toutes les métriques en même temps
Un hébergement mutualisé bas de gamme génère un p75 TTFB de 900ms à 1400ms. Le même site sur hébergement managé avec cache serveur descend à 120-250ms. Toutes les optimisations suivantes reposent sur cette base.
La différence tient à deux mécanismes. D’abord, le cache full-page côté serveur (Nginx FastCGI Cache ou Varnish) court-circuite l’exécution PHP et la requête MySQL pour chaque visite sur une page déjà mise en cache. Le navigateur reçoit du HTML statique en quelques dizaines de millisecondes. Ensuite, l’isolation des ressources : sur l’hébergement mutualisé, un voisin en pic de trafic ralentit votre TTFB sans que vous puissiez rien faire.
Pour un parc de sites clients, le benchmark HostingStep 2025 sur 34 hébergeurs montre WP Engine à 367ms de TTFB moyen contre 444ms pour Kinsta. Les deux restent loin des 900ms+ du mutualisé. Si la migration est impossible ou hors budget, configurez au minimum le cache full-page au niveau du serveur : WP Super Cache en mode mod_rewrite ou WP Rocket avec le cache serveur activé. C’est insuffisant pour compenser un mauvais TTFB de base mais ça coupe les requêtes PHP répétitives.
Le cache WordPress : ce qui sert vraiment et ce qui ne fait rien
Le cache se décompose en trois couches qui n’ont pas le même impact. Activer la mauvaise couche en premier ne change rien au LCP.
Le cache de page stocke le HTML rendu pour chaque URL et supprime le passage par PHP et la base de données sur les requêtes suivantes. C’est lui qui impacte directement le TTFB et donc le LCP. À activer en mode cache full-page dans WP Rocket (onglet Cache > Activer la mise en cache des pages) ou équivalent.
Le cache objet (Redis ou Memcached) met en cache les requêtes MySQL répétitives en RAM. Utile sur les sites à contenu dynamique élevé ou avec des requêtes ACF complexes. Sans utilité si votre hébergement gère déjà le cache full-page en amont de PHP.
Le cache du navigateur définit la durée de vie des ressources statiques (CSS, JS, images) dans le cache local du visiteur, via les en-têtes HTTP Cache-Control et Expires. WP Rocket le gère automatiquement. Vérifiez dans PageSpeed Insights l’alerte « Serve static assets with an efficient cache policy ».
Le cache ne remplace pas la compression Gzip/Brotli (à activer côté serveur ou via plugin), ne réduit pas le poids des images et ne touche pas à l’INP. Ces trois points se traitent à part, dans les sections suivantes.
Images : le gain le plus rapide sur le LCP
L’optimisation des images déplace le LCP de 0,4 à 1,2 seconde selon le cas de départ.
Convertir en WebP. Le format WebP réduit le poids des images de 25 à 35% sans perte visible à la compression standard. Depuis WordPress 5.8, la conversion native est disponible mais incomplète sur certains thèmes. Imagify, ShortPixel ou Squoosh CLI gèrent la conversion en batch avec fallback automatique pour les navigateurs qui ne supportent pas WebP (cas rare en 2026 : Safari supporte WebP depuis 2020).
Ajouter fetchpriority="high" sur l’image LCP. Depuis WordPress 6.3, le core tente d’insérer cet attribut automatiquement. Il est souvent omis avec Elementor, un block theme custom ou un custom post type avec champ image ACF. Vérifiez dans le code source de la page que votre image hero porte bien fetchpriority="high" et pas loading="lazy". Ces deux attributs sur la même image s’annulent.
Dimensionner au pixel près. WordPress génère des thumbnails automatiques mais si votre thème appelle the_post_thumbnail('full') partout, vous servez une image 2000px dans un conteneur de 800px. Vérifiez les tailles dans functions.php et ajoutez les bonnes via add_image_size() si nécessaire. Puis régénérez via WP-CLI : wp media regenerate --yes.
JavaScript : la cause principale des mauvais scores INP
Elementor ajoute 200 à 450 Ko de JavaScript et CSS même sur les pages qui n’utilisent que 30% de ses widgets. Divi et WPBakery ont des overheads comparables. Ce JavaScript s’exécute sur le thread principal et bloque la réactivité aux interactions.
Pour diagnostiquer : Chrome DevTools, onglet Performance. Enregistrez pendant 5 secondes avec des interactions de clic. Les blocs rouges Long Tasks (au-dessus de 50ms) indiquent les scripts qui bloquent le thread. Notez les sources dans la colonne initiator : ce sont eux à désactiver en priorité.
Trois corrections dans l’ordre. Dans Elementor > Réglages > Éléments, décochez les widgets que vous n’utilisez pas sur ce site. Chaque widget désactivé allège le CSS chargé sur toutes les pages, pas seulement les pages concernées. Dans WP Rocket, activez l’option « Charger le CSS et JS uniquement sur les pages qui en ont besoin » (Load CSS and JS only when necessary), puis inspectez page par page pour vérifier qu’aucun composant ne disparaît. Enfin, passez les scripts non-critiques (Google Tag Manager, widgets de chat, scripts d’analyse tiers) en defer ou async, via WP Rocket ou manuellement dans functions.php avec wp_script_add_data().
CDN et minification : les finitions qui font passer 2,5s à 1,8s
Un CDN (Content Delivery Network) et la minification des ressources grattent les dernières centaines de millisecondes, une fois les quatre points précédents traités.
Le CDN distribue les ressources statiques (images, CSS, JS, polices) depuis des serveurs proches du visiteur. Cloudflare en tier gratuit suffit pour la majorité des sites : DNS proxifié, cache edge automatique pour les ressources statiques, HTTPS sans configuration. Pour les sites à audience internationale, Cloudflare Pro ou un CDN dédié comme BunnyCDN ou KeyCDN apporte un gain mesurable.
La minification CSS/JS supprime les espaces, commentaires et variables non minifiées des fichiers de sortie. WP Rocket le fait nativement. Activez la minification et la combinaison des CSS en tête, puis testez visuellement : la combinaison JS peut casser des dépendances dans des thèmes qui chargent des scripts dans un ordre précis. En cas de régression, désactivez la combinaison JS et gardez seulement la minification.
Pour les polices Google Fonts, hébergez-les en local. Téléchargez les fichiers WOFF2 via google-webfonts-helper.herokuapp.com, placez-les dans /wp-content/themes/votre-theme/fonts/, déclarez-les dans votre feuille de style et ajoutez <link rel="preload"> dans le <head>. Cela supprime une requête DNS externe et une connexion HTTP qui bloquent parfois le rendu initial.
Vérifier que les 2 secondes sont atteintes
Google PageSpeed Insights mesure les Core Web Vitals sur données CrUX (terrain) et en simulation Lighthouse. Les deux chiffres divergent parfois. Fiez-vous aux données terrain si votre site a suffisamment de trafic (seuil CrUX : environ 1 000 pageviews mensuelles sur l’URL).
Pour un audit plus précis, GTmetrix en location Paris ou Amsterdam reflète mieux les performances pour une audience française. Notez le TTFB, le LCP et le poids total de la page. WebPageTest permet des tests en cascade multi-étapes et des comparaisons avant/après sur la même configuration.
- TTFB sous 200ms (GTmetrix, colonne « Wait »)
- LCP sous 2,5s sur mobile (PageSpeed Insights, données terrain)
- INP sous 200ms (Chrome User Experience Report ou CrUX Dashboard)
- CLS sous 0,1 (vérifier les images sans dimensions
width/heightdéfinies dans le HTML) - Aucun Long Task au-dessus de 200ms dans DevTools Performance
Si le LCP reste au-dessus de 2,5s après toutes ces étapes, relancez un audit DevTools en mode mobile throttling (CPU 4x slowdown) pour identifier le dernier goulot. Sur mobile, un rendu bloqué par une police ou un CSS non-critique non différé est souvent la cause résiduelle.
Lancez un test GTmetrix après chaque modification individuelle. C’est le seul moyen d’attribuer le gain à la bonne action.
