Étape 1 : Mesurez avant d'optimiser
Faites passer votre site dans PageSpeed Insights (pagespeed.web.dev) et notez quatre chiffres : LCP (Largest Contentful Paint, le temps jusqu'à l'apparition du contenu principal), INP (Interaction to Next Paint, réactivité), CLS (Cumulative Layout Shift, stabilité visuelle) et le poids total de la page. Seuils des Core Web Vitals de Google : LCP en dessous de 2,5 s, INP en dessous de 200 ms, CLS en dessous de 0,1. Ils affectent directement votre positionnement depuis 2021. En dessous de ces seuils, c'est « bon » ; entre les seuils et 4 s/500 ms/0,25, c'est « à améliorer » ; pire, c'est « médiocre ». Tout l'objectif de l'optimisation de la vitesse de WordPress est de faire passer ces trois chiffres dans la zone verte. Ne vous fiez pas aux scores de GTmetrix ni à d'autres notations agrégées : ils ne correspondent pas aux signaux réels de Google.
Étape 2 : Vérifiez que votre hébergement n'est pas le goulot d'étranglement
Vérifiez le TTFB (Time To First Byte) depuis la géographie de votre audience avec WebPageTest. Si le TTFB dépasse 1 seconde, votre hébergement est le goulot d'étranglement : aucune optimisation du front-end ne le corrigera. Coupables fréquents : hébergement mutualisé bon marché avec des serveurs surchargés, hébergement sur un continent différent de celui de votre audience, absence d'opcache PHP (toute version de PHP 7+ devrait l'avoir activé par défaut). La solution la moins chère consiste à passer à un hébergement plus rapide au même niveau de plan. Pour moins de 50 000 visites/mois, Hostinger Business avec LiteSpeed Cache produit un TTFB inférieur à 400 ms. Pour davantage de trafic, Kinsta ou WP Engine sur le niveau premium de Google Cloud produisent un TTFB inférieur à 300 ms de façon constante. Changer d'hébergement demande plus de travail qu'installer un plugin, mais l'amélioration est souvent spectaculaire.
Étape 3 : Le cache de page est le plus grand gain isolé
Par défaut, WordPress génère chaque page depuis PHP + MySQL à chaque requête. Le cache de page stocke le HTML généré et le sert directement aux visiteurs suivants : généralement 10 à 20 fois plus rapide. Sur les hébergements basés sur LiteSpeed (Hostinger, la plupart de Bluehost, A2 Turbo, NameHero), installez LiteSpeed Cache (gratuit) : il s'intègre au cache au niveau serveur. Sur les hébergements Apache/Nginx, installez WP Rocket (59 $/an) : c'est le plugin de cache de la plus haute qualité et il vaut son prix. Les alternatives gratuites (W3 Total Cache, WP Super Cache) fonctionnent mais demandent plus de configuration. Après avoir activé le cache de page, refaites un test dans PageSpeed Insights : vous devriez voir le TTFB chuter nettement.
Étape 4 : L'optimisation des images vient en deuxième
Les images représentent souvent 60 à 80 % du poids d'une page WordPress. Deux gains à capter : (1) Compression : chaque image doit être compressée avant l'envoi. Utilisez notre Compresseur d'images ou installez ShortPixel/Smush pour compresser automatiquement à l'envoi. Objectif : images d'en-tête en dessous de 200 Ko, images de contenu en dessous de 100 Ko. (2) Formats modernes : servez du WebP (ou de l'AVIF) plutôt que du JPG/PNG. Le WebP est 25 à 35 % plus léger à qualité égale. ShortPixel et Smush Pro convertissent automatiquement ; en alternative, l'optimisation d'images de Cloudflare réécrit les images à la volée. (3) Chargement différé : les images sous la ligne de flottaison ne devraient se charger qu'au défilement jusqu'à elles. WordPress 5.5+ ajoute loading='lazy' automatiquement ; vérifiez que cela fonctionne en consultant le code source. (4) Attributs de largeur : définissez toujours une largeur/hauteur explicite sur les images pour éviter le CLS.
Étape 5 : Minification CSS/JS et audit des bundles
La plupart des plugins de cache (WP Rocket, LiteSpeed Cache) incluent la minification CSS/JS : activez-la. Le plus grand gain consiste à différer ou supprimer les scripts non utilisés. Lancez Chrome DevTools → onglet Coverage sur votre page d'accueil ; il indique quels octets de CSS et de JS sont réellement utilisés. Résultats typiques : 50 à 80 % du CSS n'est pas utilisé, 30 à 60 % du JS n'est pas utilisé. Solutions : (a) utilisez un thème plus léger (GeneratePress ou Kadence envoient moins de 30 Ko de CSS), (b) désactivez les plugins non utilisés (souvent à l'origine des scripts inutiles), (c) utilisez un plugin comme Asset CleanUp pour désactiver les scripts sur les pages qui n'en ont pas besoin (p. ex. Contact Form 7 se charge partout par défaut, même si vous ne l'utilisez que sur /contact).
Étape 6 : Audit des plugins : trouvez les lents
Chaque plugin actif de WordPress s'exécute à chaque chargement de page, ajoutant potentiellement des requêtes, du JavaScript et du CSS. La plupart des sites lents ont plus de 30 à 50 plugins actifs, dont la moitié ne servent plus. Utilisez Query Monitor (gratuit) pour voir quels plugins effectuent le plus de requêtes à la base de données. Utilisez le niveau gratuit de New Relic ou l'APM de Kinsta pour voir quelles fonctions de plugins prennent le plus de temps. Principaux fautifs historiques : Jetpack (fait beaucoup de choses, toutes à chaque requête), plugins de sauvegarde gonflés s'exécutant pendant les pics de trafic, plugins de partage social qui chargent leur CSS/JS même sur les pages sans boutons de partage, plugins de sécurité qui effectuent des analyses de fichiers en temps réel. Désactivez un plugin, refaites un test de performance et décidez si la fonctionnalité valait le coût.
Étape 7 : Optimisation de la base de données
WordPress accumule des déchets dans la base de données au fil du temps : révisions d'articles, transients expirés, commentaires indésirables, métadonnées orphelines. Installez WP-Optimize (gratuit) et lancez une fois un nettoyage de la base de données. Maintenance mensuelle raisonnable : supprimez les révisions de plus de 60 jours (conservez les récentes par sécurité), les transients expirés, la file de spam. Pour les sites à fort trafic, le plus grand gain sur la base de données est le cache d'objets : Redis ou Memcached stockent en mémoire les résultats de requêtes MySQL coûteuses, évitant le travail répété. La plupart des hébergements WordPress infogérés incluent Redis dans leurs niveaux supérieurs ; sur l'hébergement mutualisé de base, ce n'est pas disponible.
Étape 8 : CDN pour les audiences mondiales
Un CDN (réseau de distribution de contenu) met en cache vos ressources statiques (images, CSS, JS) dans des emplacements edge proches de vos visiteurs. Pour une audience uniquement américaine hébergée aux États-Unis, un CDN apporte une amélioration modeste. Pour une audience mondiale, un CDN est essentiel : il réduit la latence des ressources de 200-500 ms à 20-50 ms. Le niveau gratuit de Cloudflare couvre la plupart des besoins ; BunnyCDN à 0,01-0,05 $/Go est une mise à niveau payante aux performances excellentes. Pour les images en particulier, Cloudflare Images ou Bunny Image Optimizer peuvent redimensionner et convertir les formats à la volée.
Étape 9 : Mesurez à nouveau et itérez
Après chaque changement important, relancez PageSpeed Insights. L'objectif est le progrès incrémental : la plupart des sites ne passent pas de « médiocre » à « bon » en un seul changement. Après une passe d'optimisation complète, résultats typiques : une boutique WooCommerce sur hébergement mutualisé passe d'un LCP de 4 à 6 s à un LCP de 1,5 à 2,5 s. Un blog de contenu sur hébergement infogéré passe d'un LCP de 2 à 3 s à un LCP de 0,8 à 1,5 s. Si vous restez au-dessus de 3 s de LCP après tout ce qui précède, le goulot d'étranglement est probablement votre thème : passez à un thème plus léger (GeneratePress, Kadence ou Astra) avant de poursuivre l'optimisation.