Un back office WordPress lent vient, dans neuf cas sur dix, de l’une de ces quatre causes : des requêtes admin-ajax.php déclenchées en rafale par l’API Heartbeat, un plugin qui exécute des requêtes SQL lourdes à chaque chargement, une table wp_options gonflée par les données en autoload, ou une version de PHP obsolète avec une limite mémoire trop basse. La bonne nouvelle : chacune de ces causes se diagnostique en quelques minutes avec les bons outils, et se corrige sans toucher au front de votre site. Cet article suit un arbre de diagnostic par symptôme : lenteur générale, page précise qui rame, ou pics ponctuels. Suivez la branche qui correspond à votre situation.

Diagnostic express : situez votre symptôme en cinq minutes

Avant de toucher quoi que ce soit, qualifiez le problème. Connectez-vous (si besoin, relisez comment accéder à wp-admin) et répondez à trois questions :

  • Tout l’admin est-il lent, tout le temps ? Tableau de bord, liste des articles, réglages : chaque page met plus de 3 secondes. Direction la branche A : cause structurelle (base de données, PHP, cache objet, hébergement).
  • Une seule page rame-t-elle ? L’éditeur, la liste des commandes WooCommerce, la médiathèque. Branche B : un plugin ou un écran précis est en cause.
  • La lenteur est-elle ponctuelle ? Des blocages de quelques secondes, aléatoires, puis tout redevient normal. Branche C : Heartbeat, WP-Cron, appels externes ou DNS.

Installez ensuite deux outils gratuits : le plugin Query Monitor (visible uniquement pour les admins, aucun impact visiteur) et, si vous avez un accès SSH, lancez un audit WP Doctor qui vérifie en une commande l’autoload, le cron et l’état de la base.

Branche A : tout l’admin WordPress est lent, en permanence

Quand chaque page du tableau de bord est lente, le problème est structurel : il se situe dans ce que WordPress charge à chaque requête. Ouvrez une page de l’admin avec Query Monitor actif et relevez trois chiffres : temps de génération, nombre de requêtes SQL, mémoire consommée. Repères sains : moins de 1,5 seconde, moins de 100 requêtes, moins de 80 Mo. Au-delà, parcourez les sections suivantes dans l’ordre — de la cause la plus fréquente à la plus rare — et ne modifiez qu’une chose à la fois pour savoir ce qui a réellement fonctionné.

Heartbeat et admin-ajax.php : le suspect numéro un

Ouvrez l’onglet Réseau des outils de développement de votre navigateur (F12) sur une page de l’admin. Si vous voyez des requêtes admin-ajax.php partir toutes les 15 secondes, c’est l’API Heartbeat : elle gère l’autosauvegarde et le verrouillage d’édition, mais sur un hébergement mutualisé elle peut saturer les processus PHP à elle seule, surtout avec plusieurs onglets d’admin ouverts. On ne la désactive pas complètement (vous perdriez l’autosauvegarde), on l’espace. Ajoutez ceci dans le fichier functions.php de votre thème enfant ou dans un mu-plugin :

// Espacer les battements de l'API Heartbeat (15 s par défaut)
add_filter( 'heartbeat_settings', function( $settings ) {
    $settings['interval'] = 60; // en secondes
    return $settings;
} );

Le retour arrière est trivial : supprimez ces lignes et Heartbeat reprend son rythme par défaut. Si des requêtes admin-ajax.php partent en continu sans lien avec Heartbeat, notez le paramètre action de la requête : il désigne presque toujours le plugin fautif.

Plugins lourds : identifiez le coupable avec Query Monitor

Dans Query Monitor, ouvrez la section « Requêtes par composant ». Vous obtenez le temps SQL consommé par chaque plugin sur la page courante. Un plugin qui dépasse 0,5 seconde à lui seul mérite une enquête. Les récidivistes classiques : plugins de statistiques qui écrivent en base à chaque hit, constructeurs de popups, plugins de sécurité mal réglés qui journalisent tout, extensions de sauvegarde qui tournent en pleine journée, et modules « related posts » qui recalculent en boucle.

Pour confirmer sans casser la production : dupliquez le site en préproduction, puis désactivez les plugins par moitiés successives (dichotomie). En quatre itérations maximum, vous tenez le coupable. Cherchez ensuite une alternative plus légère ou un réglage moins gourmand avant de le supprimer définitivement.

Base de données gonflée : autoload, transients et révisions

À chaque page de l’admin, WordPress charge en mémoire toutes les options marquées « autoload » de la table wp_options. Sur un site sain, cela pèse moins de 1 Mo. Sur un site qui a vu passer des dizaines de plugins, on trouve couramment 5 à 20 Mo rechargés à chaque clic. Mesurez d’abord :

-- Poids total des options chargées à chaque page (autoload)
SELECT ROUND(SUM(LENGTH(option_value))/1024/1024, 2) AS taille_mo,
       COUNT(*) AS nb_options
FROM wp_options
WHERE autoload IN ('yes', 'on');

-- Les 20 options autoload les plus lourdes
SELECT option_name, ROUND(LENGTH(option_value)/1024, 1) AS taille_ko
FROM wp_options
WHERE autoload IN ('yes', 'on')
ORDER BY LENGTH(option_value) DESC
LIMIT 20;

Au-delà de 1 Mo d’autoload, il faut nettoyer. Règle absolue avant toute manipulation : exportez la base. C’est votre rollback ; sans lui, une erreur de requête est irréversible. Avec les commandes WP-CLI, l’ensemble tient en quatre lignes :

# 1. Sauvegarde AVANT toute manipulation (c'est votre rollback)
wp db export backup-avant-optimisation-$(date +%F).sql

# 2. Purger les transients (données temporaires souvent orphelines)
wp transient delete --expired
wp transient delete --all

# 3. Supprimer les révisions accumulées
wp post delete $(wp post list --post_type=revision --format=ids) --force

# 4. Optimiser les tables
wp db optimize

# En cas de problème, restauration immédiate :
# wp db import backup-avant-optimisation-AAAA-MM-JJ.sql

Les transients supprimés seront régénérés automatiquement par les plugins qui en ont besoin : la suppression est sans danger fonctionnel. Pour les options autoload orphelines (laissées par des plugins désinstallés), passez-les en autoload = 'no' plutôt que de les supprimer : effet identique sur la performance, réversibilité totale.

PHP obsolète et memory_limit trop bas

Un back office sous PHP 7.4 est mécaniquement 2 à 3 fois plus lent que sous PHP 8.2 ou 8.3, et PHP 7.4 ne reçoit plus aucun correctif de sécurité. Vérifiez votre version dans Outils → Santé du site → Informations, puis suivez notre guide pour mettre à jour PHP proprement, avec test de compatibilité des extensions au préalable. C’est le meilleur ratio effort/gain de tout cet article.

Deuxième vérification : la mémoire allouée. WordPress plafonne par défaut la mémoire de l’admin, et un éditeur Gutenberg ou un WooCommerce à l’étroit multiplie les lenteurs et les erreurs 500 sporadiques. Dans wp-config.php, au-dessus de la ligne « C’est tout, ne touchez plus à rien ! » :

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

// Bonus : limiter les révisions conservées par article
define( 'WP_POST_REVISIONS', 10 );

Ces constantes se retirent aussi vite qu’elles s’ajoutent : le rollback consiste à supprimer les lignes. Vérifiez toutefois que la limite mémoire de votre hébergement (directive memory_limit de PHP) est au moins égale à la valeur demandée, sinon la constante n’aura aucun effet.

Pas de cache objet : installez Redis

Le cache de page ne sert à rien dans l’admin : les pages du back office ne sont jamais mises en cache, et c’est normal. Ce qu’il vous faut, c’est un cache objet persistant : Redis (ou Memcached) mémorise les résultats des requêtes SQL répétitives entre deux chargements. Sur un site avec beaucoup de contenus ou WooCommerce, le gain dans l’admin est spectaculaire, souvent 40 à 60 % de temps de génération en moins.

Concrètement : vérifiez que Redis est disponible chez votre hébergeur (un clic chez la plupart des infogérés, un paquet à installer sur VPS), installez le plugin Redis Object Cache, puis activez la liaison. La commande wp redis enable fait la même chose en SSH. Après activation, pensez à vider le cache WordPress à tous les niveaux pour repartir sur des données propres. Rollback simple : wp redis disable ou désactivation du plugin, le site retombe sur le cache objet non persistant natif.

Branche B : une seule page de l’admin rame

Si le tableau de bord est fluide mais qu’un écran précis met dix secondes à s’afficher, le problème est local.

  • La liste des articles ou des commandes : une colonne personnalisée ajoutée par un plugin exécute une requête par ligne. Réduisez le nombre d’éléments par page (Options de l’écran) : si la page redevient rapide à 5 éléments au lieu de 20, le diagnostic est confirmé. Masquez la colonne fautive.
  • L’éditeur : un page builder qui charge des centaines de scripts, ou des révisions par milliers sur cet article précis. Query Monitor vous montre les deux.
  • La médiathèque : régénération de miniatures à la volée ou bibliothèque énorme sans pagination. Un plugin d’images qui « optimise » en direct à chaque affichage est souvent en cause.
  • Le tableau de bord seul : les widgets de plugins (statistiques, flux distants) font des appels externes. Désactivez-les un à un via Options de l’écran.

Branche C : lenteurs ponctuelles — WP-Cron, DNS et appels externes

Des blocages aléatoires de 5 à 30 secondes ? Trois pistes, dans cet ordre.

WP-Cron. Le planificateur de WordPress se déclenche au chargement d’une page : si une tâche lourde (sauvegarde, newsletter, synchronisation) est due, c’est votre requête d’admin qui la paie. Solution durable : confier le travail à un vrai cron serveur toutes les 5 minutes.

// Dans wp-config.php : ne plus lancer le cron au chargement des pages
define( 'DISABLE_WP_CRON', true );

# Puis dans la crontab du serveur (crontab -e) :
*/5 * * * * cd /var/www/monsite && wp cron event run --due-now > /dev/null 2>&1

Attention au rollback ici aussi : si vous ajoutez la constante sans créer le cron serveur, les tâches planifiées ne s’exécuteront plus du tout. Faites les deux dans la foulée, et vérifiez avec wp cron event list que les tâches passent bien.

Appels HTTP externes. Licences, mises à jour, API tierces : quand le serveur distant répond lentement, votre admin gèle jusqu’au timeout. L’onglet « Appels API HTTP » de Query Monitor liste ces requêtes avec leur durée ; un plugin qui interroge un domaine injoignable s’y repère immédiatement.

DNS du serveur. Plus rare mais vicieux : une résolution DNS sortante lente ajoute une à deux secondes à chaque appel externe. Sur VPS, testez avec time curl -sI https://api.wordpress.org ; au-delà de 500 ms répétés, examinez le résolveur dans /etc/resolv.conf.

Hébergement sous-dimensionné : les signes qui ne trompent pas

Si vous avez purgé la base, mis PHP à jour, activé Redis et calmé Heartbeat, mais que l’admin reste poussif, regardez l’infrastructure en face. Les signes d’un hébergement à bout : TTFB supérieur à 800 ms même sur une page vide, erreurs 503 aux heures de pointe, limite de processus PHP simultanés atteinte (la fameuse file d’attente de connexions sur mutualisé LiteSpeed). Un WooCommerce actif ou plusieurs rédacteurs connectés n’ont rien à faire sur un mutualisé d’entrée de gamme, précisément parce que l’admin n’est jamais mis en cache. Avant de migrer, demandez à votre hébergeur les métriques CPU/RAM/processus de votre compte : elles trancheront objectivement.

Thème et page builder : l’admin n’est pas épargné

Le thème charge aussi son code dans l’admin : options de personnalisation, scripts d’éditeur, intégrations. Test rapide en préproduction : basculez sur un thème par défaut (Twenty Twenty-Five) et mesurez. Si l’admin devient fluide, votre thème ou son constructeur de pages est en cause. Les page builders historiques embarquent des couches de compatibilité lourdes dans l’éditeur : mettez-les à jour, désactivez leurs modules inutilisés, et pour un nouveau projet, considérez l’éditeur natif, bien plus léger côté back office.

Plan d’action récapitulatif

  1. Qualifier le symptôme : lenteur générale, page précise, ou pics ponctuels.
  2. Installer Query Monitor et relever temps, requêtes SQL et mémoire.
  3. Espacer Heartbeat et surveiller admin-ajax.php.
  4. Sauvegarder la base, puis purger transients, révisions et autoload.
  5. Passer sur PHP 8.2+ et ajuster WP_MEMORY_LIMIT.
  6. Activer un cache objet Redis.
  7. Basculer WP-Cron sur un cron serveur.
  8. Si rien n’y fait : confronter les métriques serveur et envisager la migration.

FAQ : back office WordPress lent

Pourquoi mon admin WordPress est-il lent alors que le site public est rapide ?

Parce que le site public est servi par le cache de page, qui ne s’applique jamais au back office. L’admin exécute PHP et SQL à chaque clic et révèle les problèmes de fond que le cache masque côté visiteurs.

Puis-je désactiver complètement Heartbeat ?

Déconseillé : vous perdriez l’autosauvegarde des brouillons et le verrouillage d’édition. Espacez plutôt l’intervalle à 60 secondes via le filtre heartbeat_settings : gain quasi identique, sans effet de bord.

La suppression des transients peut-elle casser mon site ?

Non. Les transients sont des données temporaires que chaque plugin sait régénérer à la demande. Au pire, le premier chargement suivant sera un peu plus lent, le temps que les caches se reconstruisent. Exportez tout de même la base avant, par principe.

Combien de plugins est-ce trop ?

Le nombre importe moins que la qualité : 30 plugins bien codés pèsent moins qu’un seul qui exécute 200 requêtes SQL par page. Jugez sur les mesures de Query Monitor, pas sur le compteur d’extensions.

Sources et références

G
WP Admin Lab

Architecte web full-stack. WordPress, performance, data et sécurité. Notes de terrain, tests reproductibles et retours d'expérience.