Slow WordPress site sur WordPress - Causes & solutions

Symptômes : comment confirmer le diagnostic

Avant de toucher quoi que ce soit, distingue un vrai problème de performance d'une impression. La perception du visiteur et la métrique technique ne se recoupent pas toujours, et tu dois savoir où se situe le ralentissement : côté serveur (génération de la page) ou côté navigateur (rendu).

Lance d'abord PageSpeed Insights (pagespeed.web.dev) sur ta page d'accueil ET sur une page produit ou article, en mobile. Note les valeurs de terrain (CrUX) si elles existent : ce sont les données de tes vrais utilisateurs, bien plus fiables que le test labo. Voici les seuils de référence pour situer chaque métrique.

• TTFB (temps de réponse serveur) : bon < 200 ms, à surveiller 200-500 ms, mauvais 500-1000 ms et au-delà. Un mutualisé typique tourne entre 500 et 1200 ms ; un VPS correct passe sous 200 ms.
• LCP (Largest Contentful Paint) : bon < 2,5 s, à améliorer 2,5-4 s, mauvais > 4 s. C'est l'élément principal de la page (souvent une image hero).
• INP (Interaction to Next Paint) : bon < 200 ms, à améliorer 200-500 ms, mauvais > 500 ms. Remplace le FID depuis mars 2024 ; il mesure la réactivité aux clics, souvent plombée par du JavaScript.
• CLS (décalage visuel) : bon < 0,1, à améliorer 0,1-0,25, mauvais > 0,25.
• Requêtes HTTP : vise moins de 50 par page. Au-delà de 100, tu as un problème d'assets non groupés.

Impact business immédiat

Un WordPress lent ne dégrade pas que le confort : il attaque directement ton chiffre et ta visibilité, et l'effet est cumulatif.

Concrètement, sur un site lent tu perds des leads entrants (formulaires abandonnés, paniers non validés), tu subis une baisse SEO progressive parce que Google rétrograde les pages aux Core Web Vitals médiocres, et tes campagnes payantes coûtent plus cher au lead puisque le taux de conversion de la landing chute. Pire : le back-office lent ralentit aussi ton équipe, ce qui décale les publications et les mises à jour de stock. Tant que le TTFB reste au-dessus de 500 ms, chaque euro de trafic acheté rend moins.

Causes classées par probabilité

D'après ce qui revient le plus souvent en intervention, voici l'ordre statistique réel des coupables. Inutile d'optimiser les images si ton TTFB serveur est à 900 ms : commence toujours par le haut de cette liste.

• 1. Hébergement sous-dimensionné (mutualisé saturé, pas d'OPcache, PHP ancien) — c'est la cause n°1 d'un TTFB élevé.
• 2. Plugins mal codés ou redondants qui chargent leurs CSS/JS sur toutes les pages, même celles qui n'en ont pas besoin.
• 3. wp_options gonflée : des données autoloaded à plusieurs centaines de Ko chargées à CHAQUE requête. Cause fréquente et quasi invisible.
• 4. Thème page-builder lourd (Elementor, Divi, WPBakery) injectant 800 Ko+ de CSS/JS.
• 5. Absence de cache page et/ou d'object cache (Redis/Memcached).
• 6. Images non optimisées : des fichiers de 2 à 8 Mo livrés bruts au lieu de 100-300 Ko en WebP.
• 7. Base de données non entretenue : révisions d'articles, transients expirés, corbeille — une BDD qui gonfle 5 à 10× en deux ans.
• 8. CSS/JS bloquants le rendu et trop de requêtes HTTP, plus le Heartbeat API (admin-ajax.php?action=heartbeat) qui tape le serveur toutes les 60 s.

Diagnostic : les commandes à lancer

Maintenant on mesure, dans l'ordre, pour localiser le goulot avant de corriger. La règle : isole le TTFB serveur d'abord, puis le front. Étape 1 — mesurer le TTFB brut en ligne de commande, sans cache navigateur ni rendu, pour savoir si le serveur est lent ou si c'est le front.

Étape 2 — Isole le plugin coupable. Active Query Monitor (en prod, sur un compte admin dédié) : il affiche le temps SQL par plugin, les requêtes lentes et les hooks coûteux directement dans la barre d'admin. Si ça ne suffit pas, utilise le plugin officiel Health Check & Troubleshooting : il désactive tous les plugins pour toi seul (sans impacter les visiteurs), puis tu les réactives un par un en mesurant le TTFB à chaque fois. Le coupable se révèle au saut de TTFB.

Étape 3 — Lis le waterfall sur GTmetrix ou WebPageTest : tu vois quelle requête bloque le rendu, quelle image pèse 4 Mo, et le Time to First Byte confirmé. Si le TTFB y est bon mais le LCP mauvais, le problème est front (images/JS), pas serveur.

# time_starttransfer = TTFB ; compare une URL de page vs une URL dynamique (panier)
curl -o /dev/null -s -w "DNS:%{time_namelookup}s  Connect:%{time_connect}s  TTFB:%{time_starttransfer}s  Total:%{time_total}s\n" https://tonsite.fr/

# Force une page non cachée pour voir le vrai temps de génération PHP
curl -o /dev/null -s -w "TTFB:%{time_starttransfer}s\n" "https://tonsite.fr/?nocache=$(date +%s)"

php -v                     # vise PHP 8.2 ou 8.3 ; 7.4 est en fin de vie et ~30-50% plus lent
php -i | grep opcache.enable   # opcache.enable => On attendu
wp cli info                # confirme la version PHP vue par WordPress
wp core version            # version WordPress

-- Poids total des données autoloaded (au-delà de ~1 Mo = problème)
SELECT ROUND(SUM(LENGTH(option_value))/1024/1024, 2) AS autoload_mb
FROM wp_options WHERE autoload = 'yes';

-- Top 20 des plus grosses options autoloaded (souvent des plugins désinstallés)
SELECT option_name, ROUND(LENGTH(option_value)/1024, 1) AS kb
FROM wp_options WHERE autoload = 'yes'
ORDER BY LENGTH(option_value) DESC LIMIT 20;

SELECT post_type, COUNT(*) FROM wp_posts WHERE post_type='revision';
SELECT COUNT(*) FROM wp_options WHERE option_name LIKE '%_transient_%';
SELECT COUNT(*) FROM wp_posts WHERE post_status='trash';

Solutions pas-à-pas

Applique dans l'ordre. Après chaque bloc, re-mesure le TTFB et le LCP : tu sauras quel levier a payé. Fais une sauvegarde BDD avant les requêtes SQL.

1. Monte PHP en 8.2 ou 8.3 depuis le panneau hébergeur et active OPcache. Sur un site qui tournait en 7.4, le gain de TTFB est souvent immédiat (20 à 40 %). Vérifie ensuite que tous tes plugins sont compatibles.
2. Nettoie wp_options. Désactive l'autoload des grosses options orphelines repérées au diagnostic : UPDATE wp_options SET autoload='no' WHERE option_name='nom_repere'; (vérifie que c'est bien un résidu de plugin désinstallé avant). Cible un total autoload sous 1 Mo.
3. Purge la base : WP-Optimize ou WP Sweep, ou en WP-CLI : wp post delete $(wp post list --post_type=revision --format=ids) --force puis wp transient delete --expired. Limite ensuite les révisions (voir bloc wp-config.php).
4. Ajoute les constantes de wp-config.php (bloc ci-dessous) pour brider les révisions, vider la corbeille, augmenter la mémoire et désactiver le Heartbeat hors édition.
5. Mets en place le cache page : WP Rocket, ou LiteSpeed Cache si ton hébergeur tourne sous LiteSpeed (gratuit et redoutable). Sur un site dynamique (WooCommerce), EXCLUS du cache les pages panier, compte et commande pour ne pas servir une session à un autre client.
6. Active un object cache persistant si tu as Redis ou Memcached dispo chez l'hébergeur : plugin Redis Object Cache + define('WP_CACHE', true);. Sur WooCommerce, ça corrige une grosse part du temps serveur en mettant en cache les requêtes répétées.
7. Optimise les images : Imagify ou ShortPixel pour convertir en WebP (≈30 % plus léger que JPEG, jusqu'à 70 % selon la source). WordPress fait le lazy loading nativement depuis la 5.5, donc n'ajoute pas un second plugin de lazy qui entrerait en conflit.
8. Allège le front : Autoptimize ou Perfmatters pour minifier/grouper CSS/JS et différer le JS non critique. Perfmatters permet aussi de désactiver les scripts d'un plugin page par page — c'est le vrai correctif contre les plugins qui se chargent partout.
9. Ajoute la compression et le cache navigateur côté serveur via .htaccess (bloc ci-dessous) si tu es sur Apache. Active HTTP/2 ou HTTP/3 chez l'hébergeur.
10. Branche un CDN (Cloudflare gratuit suffit pour démarrer, ou Bunny.net) pour rapprocher les assets de tes visiteurs et absorber les pics.

define( 'WP_MEMORY_LIMIT', '256M' );   // mémoire front
define( 'WP_MAX_MEMORY_LIMIT', '512M' );// mémoire admin/cron
define( 'WP_POST_REVISIONS', 5 );       // 5 révisions max par contenu
define( 'EMPTY_TRASH_DAYS', 7 );        // vide la corbeille au bout de 7 jours
define( 'WP_CACHE', true );             // active le cache (object cache / plugin)
define( 'AUTOSAVE_INTERVAL', 120 );     // autosave toutes les 2 min au lieu de 60s
define( 'DISABLE_WP_CRON', true );      // remplace par un vrai cron système (voir ci-dessous)

# Une fois DISABLE_WP_CRON activé, ajoute une tâche toutes les 5 minutes :
*/5 * * * * cd /var/www/tonsite && php /var/www/tonsite/wp-cron.php >/dev/null 2>&1

# --- Compression ---
<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/css text/javascript application/javascript application/json image/svg+xml
</IfModule>

# --- Cache navigateur ---
<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType image/webp "access plus 1 year"
  ExpiresByType image/jpeg "access plus 1 year"
  ExpiresByType image/png  "access plus 1 year"
  ExpiresByType text/css   "access plus 1 month"
  ExpiresByType application/javascript "access plus 1 month"
</IfModule>

Spécificités par version

Les leviers ne sont pas identiques selon ta version de WordPress et de PHP. Vérifie ces points avant d'appliquer.

• WordPress < 5.5 : pas de lazy loading natif. Tu DOIS ajouter un plugin de lazy load (ou mieux, mettre à jour). Depuis la 5.5, l'attribut loading="lazy" est ajouté automatiquement aux images — un plugin de lazy en doublon peut casser le LCP de l'image hero (mets ta hero en eager).
• WordPress 6.x : INP est officiellement dans les Core Web Vitals depuis mars 2024 (à la place du FID). Le JavaScript des page-builders et des sliders devient le premier suspect d'un mauvais INP — surveille-le dans Search Console.
• PHP 7.4 vs 8.x : la 7.4 n'est plus maintenue et tourne nettement plus lentement. Passe en 8.2/8.3 pour un gain de TTFB net, mais teste : un plugin vieux utilisant each() ou create_function() lèvera une erreur fatale en PHP 8. Valide en staging d'abord.
• Hébergement LiteSpeed vs Apache/Nginx : sous LiteSpeed, utilise LiteSpeed Cache (cache serveur natif, plus efficace qu'un cache PHP). Sous Apache, les directives .htaccess ci-dessus s'appliquent ; sous Nginx, le .htaccess est ignoré — il faut configurer gzip et expires dans le fichier de conf du serveur.

Cas « lent alors que… » : les régressions

Souvent le site fonctionnait bien et s'est dégradé d'un coup. Le scénario te pointe la cause directement, sans repasser tout le diagnostic.

• Lent alors que tout fonctionnait avant : cherche le dernier changement. Compare les dates dans wp-content/upgrade ou l'historique de mises à jour. Désactive le dernier plugin mis à jour via Health Check et re-mesure. Souvent une MAJ de plugin a réintroduit du JS bloquant.
• Lent alors que j'ai tout mis à jour : une MAJ peut avoir invalidé le cache (purge-le et re-génère), ou un plugin mis à jour a réactivé le Heartbeat. Vérifie aussi qu'une MAJ n'a pas remis l'autoload de grosses options à 'yes'.
• Lent alors que je n'ai que quelques pages : c'est presque toujours le serveur (TTFB) ou wp_options, pas le volume de contenu. Mesure le TTFB en curl ; s'il est à 800 ms sur un site de 5 pages, le problème est l'hébergement ou l'OPcache désactivé.
• Lent alors que tout semble bien configuré : object cache manquant ou plugin de cache qui ne met pas réellement en cache les pages (souvent à cause d'un cookie défini sur toutes les pages, fréquent avec WooCommerce ou un plugin de consentement). Vérifie l'en-tête de réponse : un X-Cache: HIT confirme que le cache sert bien.

Quand appeler un expert

Tu peux traiter 80 % des cas avec ce guide. Appelle un pro quand : le TTFB reste au-dessus de 500 ms malgré PHP 8.3 + OPcache + object cache (problème d'infrastructure ou requêtes custom à profiler), quand un plugin critique métier casse en PHP 8 et bloque la migration, ou quand le site est en WooCommerce avec des temps serveur qui s'effondrent en pic de trafic (il faut alors des index MySQL et une stratégie Redis sur mesure).

Si tu préfères déléguer le diagnostic et la correction sans risquer de casser la prod, l'équipe BugRescue (fondée par Soulaimane Aattar) intervient sur ce type de panne : mesure avant/après documentée, correctif appliqué en staging puis déployé. On t'envoie le rapport TTFB et Core Web Vitals avant/après.

FAQ