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.
Comment je procède
-
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.
-
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é.
-
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.
-
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.
-
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.
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.
-
Contrat de maintenance
Un suivi régulier évite que les options obsolètes et les extensions inutiles s’accumulent pendant des années.
-
Toutes les interventions WooCommerce
Les autres pannes et évolutions que je traite sur WooCommerce.
Décrivez votre besoin en 1 minute
Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.