WordPress backend slow :
pourquoi votre wp-admin rame
L'interface d'administration (wp-admin) met plusieurs secondes à charger chaque page ; l'éditeur d'articles se fige, les enregistrements et le tableau de bord traînent, alors que le site public reste correct côté visiteur.Un wp-admin lent vient presque toujours d'un cumul : PHP obsolète, table wp_options gonflée en autoload, Heartbeat API trop bavard et absence de cache objet. Passez à PHP 8.2/8.3, nettoyez l'autoload sous 1 Mo, espacez le Heartbeat et activez Redis : à eux seuls, PHP + autoload rendent souvent 40 à 60 % de temps.
Pourquoi cette erreur.
Contrairement au site public, le back-office WordPress ne peut pas être mis en cache : chaque page de wp-admin réexécute du PHP, interroge la base de données et charge les scripts de tous les plugins actifs. Le back-office est donc bien plus sensible que le front à un hébergement faible, à une base non optimisée et aux extensions lourdes.
Vous ouvrez wp-admin, et tout traîne : le tableau de bord met des secondes à s’afficher, l’éditeur se fige, chaque « Enregistrer » semble durer une éternité. Pendant ce temps, le site public, lui, tourne correctement.
Un site public rapide et un back-office lent, c’est la signature d’un problème côté serveur ou base de données — presque jamais côté thème.
Cette page va droit au but : les vraies causes d’un backend WordPress qui rame, et les correctifs dans le bon ordre.
Pourquoi le back-office rame quand le site public vole
Front et back n’obéissent pas aux mêmes règles. Le site public se met en cache (une version figée part directement au visiteur), mais le back-office ne peut pas être caché : chaque page d’admin réexécute du PHP, interroge la base de données et recharge les scripts de toutes les extensions. Résultat, il encaisse de plein fouet ce que le front masque : un hébergement faible, une base gonflée, un plugin gourmand. Un front rapide et un back lent pointent presque toujours vers le serveur ou la base — rarement vers le thème.
Rien n’est mémorisé d’un chargement à l’autre
À chaque écran de wp-admin, tout est recalculé à la volée. Aucun cache ne l’accélère comme il le ferait pour le site public.
Les quatre causes principales
PHP obsolète et autoload gonflé
Une version de PHP dépassée (7.x ou antérieure) est la cause la plus fréquente. WordPress recommande PHP 8.3 ou plus récent. Parallèlement, la table wp_options charge à chaque requête toutes ses options marquées « autoload » ; des plugins disparus y laissent souvent des données inutiles. Depuis WordPress 6.6, un autoload au-delà de 800 Ko devient critique. À eux seuls, PHP récent + nettoyage rendent fréquemment 40 à 60 % de temps.
Heartbeat API, WP-Cron et extensions lourdes
WordPress lance un minuteur qui poste vers admin-ajax.php : toutes les 60 secondes sur le tableau de bord, toutes les 15 secondes dans l’éditeur. WP-Cron se déclenche à chaque visite. Puisque l’admin ne se cache pas, une seule extension mal écrite le ralentit à chaque page.
Les correctifs, dans le bon ordre
La séquence qui marche est stable d’un site à l’autre. Évitez d’installer Redis en premier : vous mettriez en cache des données déjà superflues.
1. PHP 8.3 + nettoyage autoload sous 1 Mo
Vérifiez votre version dans Outils › Santé du site, puis basculez en PHP 8.3 (ou plus récent) depuis votre hébergeur. Repérez les options les plus lourdes dans wp_options, supprimez les résidus de plugins disparus, et ramenez l’autoload sous 800 Ko. C’est souvent le geste le plus rentable, applicable en quelques minutes.
2. Heartbeat, WP-Cron et cache objet
Espacez la Heartbeat plutôt que de la couper : elle rend de vrais services (sauvegarde auto, verrou d’édition). Son intervalle est borné entre 15 et 120 secondes via un filtre officiel. Désactivez WP-Cron « au fil des visites » pour le remplacer par une tâche planifiée serveur. Une fois PHP à jour et l’autoload allégé, activez Redis ou Memcached : un cache objet garde en mémoire vive les requêtes SQL répétées, l’un des correctifs les plus efficaces sur un back-office durablement lent.
3. Mesurer avec Query Monitor
Avant de désactiver des plugins au hasard, mesurez : installez Query Monitor pour voir, page par page, quelles requêtes SQL et quelles extensions consomment le temps réel. Un diagnostic chiffré avant/après prouve le gain et sécurise chaque intervention.
Accélérez votre back-office avec Scornidigital
Chez Scornidigital, studio web à Gembloux, on traite ces lenteurs comme un problème d’ingénierie. On mesure d’abord (version PHP, poids de l’autoload, extensions gourmandes, charge serveur et hébergement), puis on applique les correctifs dans le bon ordre. Un back-office réactif change le quotidien de qui publie chaque semaine. Un premier échange est toujours gratuit — demande de devis clair ou retour au panorama WordPress.
Comment la résoudre.
Passer à une version récente de PHP (8.2 ou 8.3)
Un PHP obsolète (7.x, voire plus ancien) est la cause la plus fréquente d'un admin lent. Les versions 8.2 et 8.3 sont nettement plus rapides et mieux optimisées. Vérifiez votre version dans Outils › Santé du site, puis changez-la depuis le panneau de votre hébergeur. Combiné au nettoyage de l'autoload, ce seul geste rend souvent 40 à 60 % de temps.
Nettoyer la table wp_options et son autoload
WordPress charge TOUTES les options « autoload » à chaque requête — chaque page d'admin, chaque appel AJAX, chaque hit d'API REST, chaque tick de cron. Des plugins désinstallés y laissent souvent des données qui restent chargées à vie. Visez un autoload sous 1 Mo (au-delà de 2-3 Mo, l'optimisation devient urgente). Repérez d'abord les options les plus lourdes.
-- Taille totale de l'autoload (WordPress 6.6+ : nouvelles valeurs) SELECT ROUND(SUM(LENGTH(option_value)) / 1024 / 1024, 2) AS autoload_mb FROM wp_options WHERE autoload IN ('yes', 'on', 'auto', 'auto-on'); -- Top 20 des options les plus volumineuses SELECT option_name, LENGTH(option_value) AS size_bytes FROM wp_options WHERE autoload IN ('yes', 'on', 'auto', 'auto-on') ORDER BY size_bytes DESC LIMIT 20;Espacer ou limiter la Heartbeat API
WordPress lance un minuteur JavaScript qui poste vers admin-ajax.php à intervalle régulier : toutes les 60 s sur la plupart des pages d'admin, toutes les 15 s dans l'éditeur (sauvegarde auto, verrou d'article). Chaque battement est une requête non cachable qui mobilise un worker PHP. On peut allonger l'intervalle (borné entre 15 et 120 s par le cœur de WordPress) via le filtre officiel.
// functions.php du thème enfant ou plugin dédié add_filter( 'heartbeat_settings', function ( $settings ) { $settings['interval'] = 60; // secondes (min 15, max 120) return $settings; } );Activer un cache objet persistant (Redis ou Memcached)
L'admin exécute beaucoup de requêtes SQL identiques à chaque chargement. Un cache objet garde leurs résultats en mémoire vive (RAM) et évite de les rejouer. C'est l'un des correctifs les plus efficaces sur un back-office durablement lent. Important : nettoyez d'abord l'autoload, sinon vous ne faites que mettre en cache des données superflues (le cache rejette d'ailleurs les objets de plus de ~900 Ko).
# Via WP-CLI, une fois Redis disponible sur l'hébergement wp plugin install redis-cache --activate wp redis enable wp redis statusDiagnostiquer et alléger les extensions avec Query Monitor
Le back-office ne se cache pas : une extension lourde le ralentit à chaque page. Installez Query Monitor pour voir, page par page, quelles requêtes et quels plugins consomment le temps. Désactivez ce qui n'est pas indispensable, remplacez les extensions gourmandes, et purgez les données mortes (révisions d'articles, transients expirés, tables orphelines) avec un outil comme WP-Optimize.
Reprendre la main sur WP-Cron et l'hébergement
Par défaut, WP-Cron se déclenche à chaque visite : sur un site actif, cela empile des tâches en pleine navigation admin. On le désactive côté PHP pour le remplacer par une tâche planifiée serveur (cron réel). Enfin, un hébergement mutualisé bas de gamme plafonne CPU et mémoire : sur un back-office lourd, un hébergement adapté (VPS, offre gérée) change tout.
// wp-config.php — désactive le cron « au fil des visites » define( 'DISABLE_WP_CRON', true ); // puis planifier côté serveur (exemple, toutes les 5 min) : // */5 * * * * curl -s https://votre-site.be/wp-cron.php?doing_wp_cron > /dev/null 2>&1
Variantes & questions.
Une variante de l'erreur qui n'est pas ici ? Écrivez-nous : on répond en clair, sous 24 h.
Poser votre questionPourquoi mon site public est rapide mais l'admin WordPress est lent ?
Parce que le front et le back n'obéissent pas aux mêmes règles. Le site public peut être servi depuis un cache de pages : une version figée, déjà calculée, part directement au visiteur. Le back-office, lui, ne peut pas être caché : chaque page de wp-admin réexécute du code PHP, interroge la base de données et recharge les scripts de toutes les extensions actives.
Résultat, il est bien plus sensible à un hébergement limité, à une base gonflée et aux plugins lourds. Un site public rapide et un admin lent, c'est même la signature typique d'un problème côté serveur ou base de données, pas côté thème.
Comment savoir si ma table wp_options est trop lourde ?
WordPress charge l'ensemble des options marquées « autoload » à chaque requête, y compris chaque page d'administration. Une requête SQL sur la table wp_options donne la taille totale de cet autoload. En dessous d'1 Mo, c'est sain ; au-delà de 2 à 3 Mo, l'optimisation devient urgente ; à plus de 5 Mo, vous laissez beaucoup de performance sur la table.
La cause la plus fréquente : des extensions désinstallées qui ont laissé des données chargées en permanence. Depuis WordPress 6.6, la colonne autoload accepte de nouvelles valeurs (on, auto, auto-on) : pensez à en tenir compte dans la requête, sinon le calcul est faussé.
Faut-il désactiver complètement la Heartbeat API ?
Rarement. La Heartbeat API rend de vrais services : sauvegarde automatique, verrou d'édition qui évite que deux personnes écrasent le même article, notifications en temps réel. La couper entièrement peut faire perdre du travail.
La bonne approche est de l'espacer plutôt que de la supprimer : allonger son intervalle (le cœur de WordPress le borne entre 15 et 120 secondes) et, éventuellement, la désactiver uniquement là où elle n'apporte rien, comme la liste des articles. Vous gardez l'utile et vous rendez des workers PHP au serveur.
Redis ou Memcached suffit-il à régler un back-office lent ?
Le cache objet est l'un des correctifs les plus efficaces, mais il ne se suffit pas à lui-même. Ajouté avant d'avoir nettoyé la base, il ne fait que mémoriser des données inutiles, et il rejette de toute façon les objets trop volumineux (au-delà d'environ 900 Ko).
La bonne séquence est claire : d'abord PHP à jour et autoload allégé sous 1 Mo, ensuite le cache objet sur une base déjà propre. À ce stade, Redis ou Memcached apporte un gain net et durable, sans masquer un problème de fond.
Scornidigital peut-il auditer et accélérer mon back-office WordPress ?
Oui. On commence par un diagnostic chiffré (version PHP, taille de l'autoload, extensions gourmandes repérées avec Query Monitor, charge serveur), puis on applique les correctifs dans le bon ordre : PHP récent, nettoyage de wp_options, réglage de la Heartbeat, cache objet et, si besoin, changement d'hébergement.
Scornidigital est un studio web basé à Gembloux (province de Namur) qui intervient pour les indépendants et PME de Namur, Bruxelles, Liège et toute la Wallonie. Vous recevez un devis clair sous 24 h.
Bloqué sur ce bug ?
Studio web full-stack à Gembloux. On règle proprement les erreurs coriaces — back-end, proxy, config serveur — sans bidouille qui casse en production.