# Le tableau de bord wp-admin est très lent

> Une boutique publique rapide et un tableau de bord qui rame n’ont pas les mêmes causes : c’est un autre ensemble de mécanismes qui se joue derrière wp-admin, entre l’API Heartbeat, les options chargées à chaque requête et l’absence de cache objet, indépendamment de ce qui rend le front-end lent ou rapide.

- Source canonique : [https://allaux.fr/wordpress-woocommerce/problemes/admin-wordpress-tres-lent](https://allaux.fr/wordpress-woocommerce/problemes/admin-wordpress-tres-lent)
- Langue : FR
- Dernière mise à jour : 2026-08-03

## Réponse directe

> Ouvrez Outils > Santé du site pour relever la version de PHP et les limites mémoire, puis mesurez le poids des lignes de wp_options dont l’autoload vaut yes : ce bloc est relu à chaque écran de wp-admin. Si le tableau de bord reste lent, espacez les appels de l’API Heartbeat vers admin-ajax.php et purgez les actions planifiées accumulées.

## Comment je procède

1. **Isolation du périmètre** — Je confirme que la lenteur touche bien wp-admin et wc-admin spécifiquement, en comparant avec le temps de chargement du site public au même moment.
2. **Contrôle de l’API Heartbeat** — Je vérifie la fréquence des appels à admin-ajax.php déclenchés par défaut toutes les 15 à 60 secondes sur chaque onglet wp-admin ouvert, et son effet sur un hébergement à nombre de workers PHP-FPM limité.
3. **Audit des options à autoload** — Je mesure le poids des lignes wp_options avec autoload à yes : ces données sont chargées à chaque requête, admin comme front, et s’accumulent au fil des années d’installation d’extensions.
4. **Vérification du cache objet** — Je regarde si un cache objet (Redis ou Memcached) est en place. Sans lui, les écrans WooCommerce comme la liste des commandes ou les rapports relancent des requêtes SQL coûteuses à chaque affichage.
5. **Correction ciblée** — Selon ce qui domine, j’ajuste la fréquence du Heartbeat, je nettoie les options obsolètes, je mets en place un cache objet, ou je réécris une requête spécifique à un écran d’administration trop lourd.

## Ce que je traite régulièrement

- La boutique publique s’affiche vite, mais wp-admin met plusieurs secondes à chaque clic
- La liste des commandes met un temps anormal à s’afficher, surtout après un filtre
- L’écran WooCommerce Analytics tourne en boucle avant d’afficher les chiffres
- Avoir plusieurs onglets wp-admin ouverts ralentit visiblement tout le reste du site
- La lenteur s’aggrave d’année en année sans qu’aucune extension n’ait changé récemment

## Ce qui ralentit spécifiquement l’administration

L’API Heartbeat interroge admin-ajax.php par défaut toutes les 15 à 60 secondes sur chaque onglet wp-admin ouvert, pour l’enregistrement automatique, les notifications ou la vérification de session. Sur un hébergement où le nombre de workers PHP-FPM est limité, quelques onglets ouverts en parallèle suffisent à ralentir visiblement toute l’administration.

Les lignes de wp_options marquées autoload=yes s’accumulent au fil des installations et désinstallations d’extensions au cours des années, et certaines n’en nettoient jamais. Ce jeu d’options est chargé intégralement à chaque requête, admin comme front-end : plus il pèse lourd, plus chaque page ralentit, discrètement mais constamment.

Sans cache objet (Redis ou Memcached), les écrans d’administration WooCommerce, en particulier la liste des commandes et les rapports d’Analytics, relancent des requêtes SQL non triviales à chaque chargement au lieu de réutiliser un résultat déjà calculé. Les écrans de rapports agrègent tout l’historique des commandes : sur un catalogue avec plusieurs années de ventes, ça peut devenir réellement lourd sans index adapté ni couche de cache.

## Réglage serveur, ou requête à réécrire

> Mettre en place un cache objet et nettoyer les options à autoload relève de la configuration serveur. Réécrire la requête d’un écran d’administration précis, devenu trop lourd sur un gros catalogue, relève du développement.

## Autres sujets liés

- **Site WooCommerce lent** — Un site public lent obéit à d’autres causes que wp-admin : cache de pages, images, requêtes front. ([/wordpress-woocommerce/site-lent](/wordpress-woocommerce/site-lent))
- **Contrat de maintenance** — Un suivi régulier évite que les options obsolètes et les extensions inutiles s’accumulent pendant des années. ([/services/maintenance](/services/maintenance))
- **Toutes les interventions WooCommerce** — Les autres pannes et évolutions que je traite sur WooCommerce. ([/wordpress-woocommerce](/wordpress-woocommerce))

## FAQ

### Pourquoi mon site public est rapide mais pas wp-admin ?

Parce que ce sont deux ensembles de mécanismes différents. Le front-end dépend surtout du cache de pages et des images ; l’administration dépend de l’API Heartbeat, des options chargées à chaque requête et du cache objet.

### C’est quoi exactement l’API Heartbeat ?

Un mécanisme WordPress natif qui interroge le serveur à intervalle régulier depuis chaque onglet wp-admin ouvert, pour l’enregistrement automatique et les notifications. Sa fréquence par défaut peut être réduite ou limitée à certains écrans.

### Un cache objet, c’est compliqué à mettre en place ?

Ça dépend de l’hébergement : certains l’activent en un clic, d’autres demandent une installation de Redis ou Memcached au niveau serveur, hors de portée sans accès technique.

### Est-ce que je peux corriger ça moi-même ?

Ajuster le Heartbeat ou activer un cache objet proposé par l’hébergeur est accessible à un généraliste. Diagnostiquer une requête lente propre à un écran WooCommerce précis demande une lecture du code.

### Pourquoi Analytics est-il l’écran le plus lent de tous ?

Parce qu’il agrège l’intégralité de l’historique des commandes à chaque affichage. Sur un catalogue avec plusieurs années de ventes, sans index ni cache adaptés, c’est l’écran le plus coûteux en requêtes SQL.