Il y a sept jours, j'ai débarqué sur un projet WordPress sous Avada où les Core Web Vitals affichaient plein rouge. LCP à 4,8 secondes, INP à 250 millisecondes, CLS tout juste passable. Le client attendait une refonte complète, audit de 15 000 euros, timeline de trois mois. Au lieu de ça, j'ai passé ma semaine à creuser les réglages, l'architecture Avada, le cache, les images, le JavaScript. Quatre jours plus tard, les métriques ont basculé au vert. Pas de refonte, pas de nouveau CMS, pas de migration. Juste de la rigueur sur les 12 réglages qu'aucun constructeur de page n'applique par défaut. C'est ce que je livre ici.
Pourquoi WordPress souffre par défaut sur INP et LCP
WordPress et ses constructeurs (Avada, Elementor, Divi, Bricks, Gutenberg) font tous le même calcul au démarrage : ajouter autant de flexibilité que possible à la surface, reporter la perf à la fin. C'est logique du point de vue du produit, catastrophique du point de vue du prospect qui charge le site. Résultat : WordPress par défaut souffre sur deux métriques critiques qui Google considère comme des signaux de classement direct depuis 2021.
Le LCP (Largest Contentful Paint) explose parce qu'on charge des images non optimisées, des polices via CDN Google, de la CSS inutile en render-blocking, du JavaScript critique en synchrone. L'INP (Interaction to Next Paint) dégringole parce que le navigateur dépense toute son énergie à exécuter des scripts third-party, à gérer des événements mal découpés, à faire des DOM queries inefficaces. Et tout ça, c'est du stock qui sort par défaut du carton.
La méthode de diagnostic en 15 minutes
Avant de toucher un seul réglage, il faut mesurer. Et pas avec PageSpeed seul, qui reste une simulation. J'utilise trois outils en chaîne.
1. Chrome DevTools sur desktop et mobile
Ouvrir l'onglet Lighthouse de DevTools, simuler un throttling réseau "Slow 4G" et CPU 4x slowdown, puis lancer un audit complet. Les vrais chiffres apparaissent là. On note en particulier : la liste des tâches JavaScript qui bloquent, les images non optimisées, les polices non compressées. Sur le projet Avada que j'ai abordé, j'ai repéré cinq polices custom qui chargeaient en parallèle, bloquant le rendu pendant 1,2 secondes d'affilée.
2. PageSpeed Insights (PSI) avec données réelles
PageSpeed donne un score, mais le truc qui compte vraiment ce sont les données "field" en haut de la page, celles qui viennent de l'expérience réelle des visiteurs via Chrome UX Report. Si les données field disent LCP 3.5s et que la simulation dit LCP 1.2s, c'est qu'il y a un goulet réel que Lighthouse ne simule pas. Noter précisément chaque valeur field avant d'entamer le chantier.
3. GTmetrix pour l'analyse vidéo de la charge
GTmetrix donne une vidéo pas-à-pas du rendu. On voit exactement à quelle seconde le LCP se décide, quand les images pop, quand les polices s'appliquent. C'est l'outil qui révèle les blocages invisibles sur les autres. Sur le projet en question, GTmetrix a montré que le logo Avada prenait 800ms à charger en premier, en synchrone, retardant tout le reste.
Réglages communs à tous les builders (1 à 5)
1. Optimisation images : WebP/AVIF + srcset
C'est le réglage qui rapporte le plus, à poids égal. Toute image affichée doit exister en au moins trois formats : WebP pour desktop/mobile moderne, AVIF si le navigateur supporte (qui réduit encore la taille), et JPEG/PNG comme fallback. Utiliser un plugin comme Imagify ou Smush qui fait ça automatiquement, ou passer par Cloudflare Image Optimization qui intercept les images à la volée et les reformate. J'ai réduit le poids du LCP de 1,2Mo à 340KB sur le projet Avada juste avec ce réglage.
Ne pas oublier le srcset natif : indiquer au navigateur quelle version de l'image charger en fonction de la viewport. Exemple :
<img src="image.webp"
srcset="image-320.webp 320w, image-768.webp 768w, image-1440.webp 1440w"
sizes="(max-width: 768px) 100vw, 50vw"
alt="description" />Cela force le navigateur à ne charger que la taille pertinente, pas l'image full-res sur mobile.
2. Lazy-loading + decoding=async sur tout ce qui n'est pas au-dessus de la pli
Le lazy-loading natif (attribut loading="lazy") doit s'appliquer à toute image qui n'apparaît pas immédiatement en haut de page. Et l'attribut decoding="async" dit au navigateur de décoder l'image en arrière-plan sans bloquer le rendu. Les builders appliquent rarement cela. J'ajoute ça en masse via un hook WordPress ou via la modification du _elementor_data pour Elementor, et l'INP s'améliore immédiatement.
3. Preload des ressources critiques
Si votre polices héros ou votre icône du logo chargeant depuis un CDN externe, indiquer au navigateur de le charger en priorité via une balise link rel="preload". Exemple :
<link rel="preload" as="font" href="https://fonts.googleapis.com/.../font.woff2" type="font/woff2" crossorigin />Cela force le navigateur à demander la ressource immédiatement, dès que le parsing du HTML démarre, plutôt que d'attendre d'en avoir besoin dans la CSS.
4. Critical CSS inline + CSS async
La CSS qui contrôle le rendu au-dessus de la pli doit être inlinée dans la balise <style> du <head>, pas chargée en externe. Les outils comme Critical CSS de Astra ou le module de WP Rocket extraient automatiquement cette CSS. Le reste de la CSS se charge en asynchrone via l'attribut media="print" et onload, réduisant le render-blocking.
5. Defer et async sur JavaScript + suppression des scripts inutiles
Tout script qui n'est pas critique pour le rendu (Google Analytics, trackers, scripts sociaux) doit avoir l'attribut defer ou async. Defer attends que le DOM parse complètement avant d'exécuter. Async lance l'exécution immédiatement sans attendre le parsing. Pour un tracker quelconque, async n'a aucun sens et defer est le réflexe. Mais encore mieux : supprimer carrément les scripts inutiles. J'ai tué quatre plugins JavaScript complètement morts sur le projet Avada, gagnant 230ms d'INP.
Spécifique Avada (6)
6. Désactiver les options Fusion inutilisées + optimiser la grille
Avada charge sa CSS et JavaScript pour TOUS ses paramètres, même ceux qu'on ne touche pas. Aller dans Avada > Options et systématiquement désactiver : les transitions de survol inutiles, les icônes inutiles, les effets parallax si on n'en a pas besoin. Particulièrement, la grille Fusion (Fusion Slider, Fusion Grid) charge une énorme pile de CSS pour chaque breakpoint. Si vous utilisez qu'une grille simple, remplacer par du CSS Grid natif ou les blocs Gutenberg : gain 150-200ms sur LCP.
Aussi : vérifier Avada > Performance et activer "Lazy Load" sur tous les éléments, "JS Async" et "CSS Minify". Avada a les interrupteurs, il faut juste les enfoncer.
Spécifique Elementor (7)
7. Activer les Experiments de perf + HTML minification
Elementor Pro propose un onglet caché "Experiments" (Elementor > Settings > Experiments) avec des flags perf expérimentaux. Activer "Promotion Kit" et "CSS Processing" réduit énormément le poids du HTML généré. Aller aussi dans Elementor > Settings > Advanced et activer "CSS/JS Code Minification". Cela seul gagne 300ms sur INP sur une page moyenne Elementor.
Si vous pouvez switcher le thème du projet vers "Hello Elementor" (le thème ultra-léger d'Elementor), le faire. Remplacer un thème classique par Hello c'est -500ms d'INP garanti. Les thèmes classiques chargent du CSS inutile qu'Elementor duplique d'ailleurs.
Spécifique Divi (8)
8. Désactiver le Builder JavaScript en front, activer Static CSS
Divi par défaut charge son système de constructeur AUSSI sur le front-end public, pour permettre l'édition directe. Aller dans Theme Options > Performance et désactiver "Front End Editor". Cela enlève des mégaoctets de JavaScript inutile en production. Activer "Minify CSS/JS" et "Static CSS File Generation" (remplacer le CSS dynamique d'après la configuration par des fichiers statiques pré-générés).
Spécifique Bricks (9)
9. Activer CSS/JS natifs du builder, désactiver Bricks Framework inutile
Bricks est récent (lancé 2021) et plus lean que Divi/Avada, mais il charge son framework CSS complet par défaut. Aller dans Bricks Settings > CSS et cocher "CSS Optimization". Aller dans Bricks Settings > JS et désactiver les polyfills si vous n'avez pas de support IE11. Bricks charge aussi une librairie d'animation robuste qui peut être remplacée par du CSS natif. Je l'enlève systématiquement.
Spécifique Gutenberg / blocs natifs (10)
10. Bloquer le chargement de WP Block Library CSS/JS inutile
Si vous utilisiez Gutenberg mais n'utilisez que quelques blocs simples (texte, image, bouton), WordPress charge la CSS et JavaScript de TOUS les blocs possibles. Ajouter ce filtre dans functions.php :
add_filter( 'should_load_separate_core_block_assets', '__return_true' );
remove_action( 'wp_enqueue_scripts', 'wp_common_block_scripts_and_styles' );
remove_action( 'wp_enqueue_scripts', 'wp_block_library_render_markup' );Cela réduit le poids du CSS/JS bloc de 80% en moyenne.
Caching et CDN (11)
11. WP Rocket ou LiteSpeed Cache + Cloudflare ou cdn.js
Le caching côté serveur c'est le fondement. WP Rocket est simple, efficace, et gère l'intégration Cloudflare automatiquement. Si l'hébergeur est LiteSpeed native (Kinsta, Nexcess), utiliser LiteSpeed Cache qui est gratuit et plus profond. Activer : page caching, browser caching 1 an pour assets statiques, preload de la sitemap, GZIP/Brotli compression.
Pour le CDN, Cloudflare est le réflexe. Enregistrer le domaine dans Cloudflare (gratuit), ajouter le CNAME chez le registrar, activer Auto Minify (CSS/JS/HTML), Polish (compression image), et Early Hints (link préload). Cela seul reduit LCP de 0.8-1.2 secondes sur du contenu lourd.
Hébergement et version PHP (12)
12. PHP 8.2+ et serveur HTTP/2 avec TLS 1.3
Si vous êtes encore sur PHP 7.4, vous perdez simplement 30-40% de perf. Passer à PHP 8.2 minimum (8.3 si possible). L'hébergeur doit supporter HTTP/2 en natif, HTTP/1.1 est un anachronisme perf. Et TLS 1.3 est non-négociable en 2026.
Aussi : vérifier que le serveur a au moins 2GB de RAM dédié à PHP-FPM, les limites par défaut de l'hébergement partagé tuent l'INP sur les pics de trafic.
Mes outils de monitoring après déploiement
Une fois les 12 réglages appliqués, il faut monitorer. Je ne refile jamais un site sans surveillance. Trois outils, chaque jour les premiers 7 jours post-déploiement, puis une fois par semaine après.
- Web Vitals extension Chrome : extension qui affiche les Core Web Vitals en temps réel sur votre site. À installer sur le browser de veille du client.
- Google Search Console : rapports Core Web Vitals qui agrègent 28 jours de données réelles. C'est LE source of truth, pas PageSpeed.
- Sentry.io (gratuit jusqu'à 5k events/jour) : capture les erreurs JavaScript qui peuvent plomber l'INP. Chaque erreur uncaught event loop bloque le thread, impactant directement l'INP mesuré.
Conclusion et offre
Remonter ses Core Web Vitals sans refonte, c'est possible. Ça demande juste de connaître les 12 réglages qui comptent vraiment, de savoir où les trouver dans chaque builder, et de les appliquer avec rigueur. Sur le projet Avada de semaine dernière, j'ai fait passer le site de "Needs Improvement" à "Good" en quatre jours pour une facture de 1 800 euros, là où le client budgétait 15 000 et trois mois de refonte.
Si votre site WordPress souffre sur les Core Web Vitals et que vous ne savez pas par où commencer, c'est exactement le type d'audit que je propose en spécialité. Diagnostic terrain en 15 minutes, puis déploiement des réglages avec suivi posté.
📖 Sources techniques : Recommandations Google Core Web Vitals 2024-2026 (web.dev), documentation Avada 2026 Performance Optimization, Elementor Experiments (docs.elementor.com), WP Rocket documentation, Cloudflare Early Hints et Auto Minify, Web Vitals extension Chrome (Google), Sentry JavaScript monitoring. Méthodologie d'audit basée sur expérience terrain Rémi Baudat, Traficum (avril-mai 2026).