Administration WordPress lente, site public rapide : trouver la bonne cause

Un site public rapide peut masquer une administration lente

L’accueil s’ouvre vite, mais passer d’un écran WordPress à l’autre prend plusieurs secondes. Une liste d’articles, une page de réglages ou l’éditeur peut demander un travail différent de celui du site public. Une page publique mise en cache peut même être servie sans recalculer toute sa réponse, alors que l’administration exécute des traitements propres au compte connecté.

Le résultat recherché est une navigation administrative utilisable, avec les données et les fonctions attendues. Il faut déterminer si l’attente vient de la réponse du serveur, d’une requête secondaire ou du navigateur après réception. Ajouter un cache HTML à l’administration n’est pas une solution : ses pages contiennent des informations et des actions propres à l’utilisateur.

Les contrôles de départ demandent votre accès habituel à wp-admin. Certains réglages ou essais d’extension nécessitent ensuite un administrateur, voire un superadministrateur en multisite. Sur un hébergement géré, utilisez les accès effectivement fournis ; l’absence d’accès au serveur ne doit pas vous empêcher de relever l’écran et la requête qui attendent.

Délimiter l’écran, le compte et le moment du ralentissement

Notez l’adresse de l’écran lent et ce qui déclenche l’attente : ouverture, recherche, changement de page, frappe ou enregistrement. Comparez une liste native comme Articles, Tous les articles, une page de réglages et le tableau de bord d’accueil. Un écran ajouté par une extension peut avoir sa propre charge et ses propres appels externes.

Gardez la date, l’heure avec fuseau, le navigateur et le compte utilisé. Deux comptes de rôles différents ne voient pas nécessairement les mêmes données. Évitez de créer un administrateur supplémentaire pour ce seul diagnostic. Si un collègue autorisé constate le même défaut, comparez seulement les observations utiles, sans partager les identifiants.

Commencez avec une ouverture de lecture. Ne multipliez pas les clics sur Enregistrer ou Mettre à jour : une action peut avoir réussi pendant que sa réponse tarde. Avant une comparaison qui change le fonctionnement, préparez une copie avec sauvegarde des fichiers et de la base, et neutralisez les paiements, courriels et synchronisations sortantes. Les modifications publiques ne doivent pas servir de chronomètre.

Lire la requête qui attend dans le navigateur

Dans Chrome, Réseau distingue le document de l’écran et les échanges Fetch/XHR qui peuvent le compléter. Les outils doivent être ouverts pendant la capture. Les adresses, paramètres et réponses d’administration peuvent contenir des informations privées : conservez les captures dans un espace adapté et ne transmettez pas de cookies ou de jetons.

Le résultat attendu est une requête identifiée, avec son statut et la phase dominante. Si le document arrive rapidement mais que l’interface reste figée, cherchez aussi une requête secondaire ou du travail JavaScript. Une longue attente du premier octet n’est pas, à elle seule, une mesure pure de PHP. Pour terminer, arrêtez la capture et fermez les outils.

1. Ouvrez F12, Réseau, puis un écran de lecture lent. Gardez la limitation réseau désactivée pour ce premier relevé.
2. Sélectionnez le document correspondant à l’administration. Dans En-têtes, notez son statut ; dans Chronologie, comparez connexion, attente et réception.
3. Regardez ensuite les requêtes Fetch/XHR qui durent longtemps ou reviennent souvent. Notez leur chemin et le moment où elles se produisent.
4. Recommencez une ouverture dans les mêmes conditions. N’utilisez pas les fonctions de modification ou de renvoi d’une requête administrative pour la tester.

Approche 1 : réduire une liste administrative trop longue

Ce parcours convient lorsqu’une liste native est lente et qu’elle affiche beaucoup d’éléments à la fois. Il demande seulement l’accès à cette liste et à ses options d’écran. Le nombre d’éléments est généralement une préférence de l’utilisateur pour cet écran ; une extension peut toutefois imposer son propre comportement.

L’essai consiste à revenir, par exemple, de cent lignes à vingt. Ces nombres ne garantissent aucun gain universel. Le changement ne supprime pas les articles : il répartit leur consultation sur davantage de pages. Il ne modifie pas non plus le nombre d’articles présenté aux visiteurs dans les réglages de lecture du site.

1. Ouvrez Articles, Tous les articles. En haut de l’écran, dépliez Options de l’écran, ou Screen Options.
2. Notez la valeur actuelle du nombre d’éléments par page. Si elle est élevée, remplacez-la par une valeur raisonnable pour votre travail, par exemple vingt, puis cliquez sur Appliquer.
3. Rechargez la liste et comparez plusieurs ouvertures. Vérifiez que la pagination permet toujours d’atteindre les autres articles.
4. Si la lenteur ne change pas ou si le réglage ne convient pas, remettez la valeur initiale et appliquez-la. Si le nombre est ignoré, faites vérifier le composant qui personnalise la liste plutôt que de modifier la base au hasard.

Utiliser les filtres pour retrouver le contenu sans opération globale

Pour retrouver un article, utilisez le statut, la date, la catégorie ou la recherche de la liste plutôt qu’un affichage de centaines de lignes. Dans Articles, Tous les articles, choisissez le filtre voulu puis Filtrer, ou saisissez le titre dans la recherche et lancez-la. Pour revenir à la vue générale, retirez ces critères et sélectionnez Tous.

Le résultat attendu est un ensemble de résultats plus maniable. Cela ne garantit pas que chaque recherche sera plus rapide : une recherche sur un grand volume ou un tri ajouté par une extension peut être coûteux. Comparez une ouverture de liste standard et le filtre précis qui ralentit afin de conserver cette distinction dans le diagnostic.

N’utilisez pas les actions groupées pour tester la vitesse. Une suppression, une modification de statut ou une mise à jour de nombreux contenus peut produire un travail supplémentaire et changer les données. Masquer une colonne ou un widget ne prouve pas non plus que son calcul s’arrête : certains composants préparent encore leurs données. Gardez les préférences d’affichage utiles, mais mesurez le résultat au lieu d’attribuer automatiquement un gain à leur disparition visuelle.

Comparer une session de travail avec moins d’onglets

Plusieurs onglets d’administration peuvent chacun effectuer des échanges et des traitements. Pour une comparaison simple, conservez un seul écran de lecture ouvert après avoir sauvegardé votre travail. Fermez les onglets inutilisés, sans interrompre un import, une mise à jour ou un traitement encore en cours. Attendez la confirmation d’une sauvegarde ; fermez ensuite les copies d’éditeur dont vous n’avez plus besoin.

Le résultat attendu est de savoir si le défaut dépend de l’accumulation d’onglets. Si l’attente demeure avec un seul écran, ne concluez pas que le nombre d’onglets était la cause. Vous pouvez rouvrir les écrans nécessaires après l’essai ; leur fermeture n’est pas un réglage permanent du site.

Une fenêtre privée permet aussi de comparer une session distincte avec votre propre compte. Elle change les cookies et certaines conditions de navigation ; elle ne rend pas le serveur plus puissant. Les extensions du navigateur autorisées dans ce mode peuvent encore agir. Si le problème reste limité à un navigateur, comparez un autre navigateur déjà disponible ou un profil maîtrisé avant de changer des extensions WordPress pour tout le monde.

Distinguer AJAX, Heartbeat et appels d’extension

Le chemin admin-ajax.php ne désigne pas une seule fonction. Des extensions et le cœur peuvent l’utiliser pour des actions différentes. Dans Réseau, sélectionnez une requête lente, puis examinez ses données de formulaire ou sa charge utile afin de relever le champ action lorsqu’il est présent. Gardez les autres valeurs privées et ne rejouez pas la requête pour la comparer.

Heartbeat est un mécanisme périodique de WordPress qui échange des données avec le serveur. Il participe notamment au renouvellement du verrou d’édition. Sa présence n’est donc pas une anomalie. Un appel long ou trop fréquent demande d’identifier les traitements ajoutés et le contexte, plutôt que de bloquer tout le point d’entrée.

Notez l’action, sa fréquence observée et sa durée avec un seul onglet ouvert. Si elle correspond à un composant reconnu, comparez ce composant sur copie. Ne désactivez pas globalement Heartbeat, les sauvegardes automatiques ou les accès REST pour faire disparaître les requêtes : cela peut dégrader la protection du travail ou d’autres fonctions. Une action de lecture lente et une action d’enregistrement ne doivent pas être traitées comme un même test.

Approche 2 : comparer un composant sur une copie

Ce parcours convient lorsqu’une extension ajoutée récemment ou une requête identifiée correspond au ralentissement. Il demande une copie fonctionnelle et un administrateur. Conservez les versions, la sauvegarde et l’état d’activation. La copie doit garder les mêmes données utiles à l’écran mesuré, avec ses effets externes neutralisés.

L’action comparée doit rester possible. Désactiver l’extension qui fournit une page de gestion supprime aussi cette page ; son absence ne prouve pas qu’elle est réparée. Sur une liste native, une extension qui ajoute un calcul ou un appel peut en revanche être comparée si la liste garde son usage. Ne forcez pas une désactivation bloquée par des dépendances.

1. Sur la copie, ouvrez Extensions, Extensions installées et notez le suspect retenu. Mesurez l’écran de référence avant toute modification.
2. Cliquez sur Désactiver pour cette seule extension, sans choisir Supprimer. Rechargez le même écran avec le même compte et les mêmes critères.
3. Vérifiez le contenu disponible et les fonctions conservées, puis comparez les durées et les requêtes concernées.
4. Réactivez le composant et refaites le contrôle. Si la lenteur revient, gardez les preuves pour son éditeur. Si le résultat est ambigu, restaurez l’état initial avant d’essayer une autre hypothèse.

Query Monitor pour préciser une génération lente

Query Monitor est une extension gratuite de John Blackbourn qui observe les requêtes SQL et les appels HTTP du chargement courant. La version vérifiée est 4.1.1, avec WordPress 6.3 et PHP 7.4 minimum, et des essais déclarés jusqu’à WordPress 7.1.4. Revérifiez cette fiche avant installation. Son rôle est le diagnostic, sans accélération automatique.

Ce parcours facultatif demande une copie et un administrateur, ou un superadministrateur en multisite. Le panneau Admin Screen identifie l’écran courant ; il n’est pas un classement automatique des écrans les plus lents. Le relevé d’un document ne constitue pas non plus l’historique de toutes les requêtes AJAX lancées ensuite.

Le résultat attendu est un composant ou une opération à rapprocher du délai observé. La collecte ajoute elle-même un coût : après le diagnostic, désactivez l’outil et refaites la comparaison utile sans lui.

1. Sur la copie, ouvrez Extensions, Ajouter, recherchez Query Monitor, vérifiez l’auteur, installez puis activez.
2. Ouvrez l’écran lent, puis le menu Query Monitor de la barre d’administration. Examinez Overview pour le temps de génération.
3. Consultez Admin Screen pour identifier le contexte, puis Timeline, Queries by Component et HTTP API Calls selon les événements présents. Conservez les éléments utiles dans un dossier privé.

Relier les requêtes SQL et HTTP au bon écran

Dans les requêtes SQL, examinez les durées et le composant responsable, plutôt que le seul nombre total. Un calcul ajouté à chaque ligne d’une grande liste peut devenir coûteux. Comparez alors le nombre de lignes avec le réglage d’écran déjà décrit, puis remesurez le même contexte. Une requête dupliquée n’autorise pas à supprimer des tables ou des options.

Dans HTTP API Calls, cherchez une attente vers un service externe déclenchée par la génération de l’écran. Un contrôle de licence, un rapport ou un composant d’extension peut attendre une réponse avant que WordPress termine. Ces appels partent du serveur ; ils ne figurent pas nécessairement comme échanges directs dans Réseau du navigateur.

Conservez le composant, la durée et l’erreur éventuelle, sans publier de jeton ni de données de client. Utilisez ensuite sa documentation ou la comparaison sur copie pour confirmer la piste. Ne retirez pas au hasard le contrôle concerné : le remplacement doit préserver la fonction. Si les requêtes observées sont rapides mais que la génération demeure lente, le coût peut se trouver dans du calcul PHP ou avant l’exécution mesurée.

Quand le navigateur reste occupé après la réponse

Si le document et les requêtes utiles arrivent vite mais que la saisie ou les menus hésitent, le problème peut se situer dans le navigateur. Comparez le même écran dans une session maîtrisée, avec moins d’onglets et sans modification WordPress. Les outils Performance peuvent enregistrer un geste et montrer un traitement JavaScript ou de présentation prolongé.

Un écran qui affiche de nombreuses lignes ou de nombreux blocs peut aussi demander beaucoup de travail après la réponse. Gardez les essais de pagination et la comparaison du composant pertinent. N’ajoutez pas un délai à tous les scripts d’administration pour tenter de les alléger : leur ordre peut être nécessaire à l’éditeur et à ses fonctions.

Si le défaut concerne l’éditeur seul, vérifiez aussi qu’il ne s’agit pas d’une erreur de chargement ou de réponse JSON. Une interface qui ne fonctionne plus n’est pas simplement lente. Conservez les erreurs exactes et poursuivez le diagnostic correspondant. Si vous examinez une frappe ou un menu, utilisez un brouillon de test sur copie plutôt qu’un contenu public en cours de modification.

Comparer les ressources serveur malgré un public rapide

Une réponse publique en cache peut masquer la charge PHP et SQL que l’administration rencontre à chaque navigation. Le temps de génération relevé par une extension de diagnostic ne couvre pas nécessairement toute l’attente avant qu’un processus PHP soit disponible. Un délai de file peut donc rester visible dans Réseau sans apparaître sous la forme d’une requête SQL très lente.

Dans les outils de l’hébergement, rapprochez les heures du ralentissement des limites atteintes, des files de traitements et des tâches planifiées. Les intitulés et les graphiques varient selon l’offre : demandez les valeurs à ces instants plutôt qu’un avis général sur la puissance du serveur. Une moyenne sur toute la journée peut masquer une pointe.

Ne relevez pas au hasard le nombre de processus PHP, la mémoire ou les délais maximaux. Davantage de processus peuvent consommer plus de ressources sans résoudre la cause. Transmettez les écrans lents, les durées, les actions et les comparaisons déjà faites. Si des tâches de fond s’accumulent, examinez leur diagnostic propre ; vider leur file pourrait supprimer un travail nécessaire ou rejouer des actions.

Valider la navigation et les enregistrements utiles

Revenez à l’écran qui servait de référence et comparez plusieurs ouvertures dans les mêmes conditions. Vérifiez la pagination, les filtres, les données visibles et les fonctions nécessaires au compte. Si vous avez utilisé Query Monitor, conservez son relevé puis contrôlez le comportement sans sa collecte.

Pour l’éditeur, vérifiez une sauvegarde sur un brouillon de test dans la copie et attendez sa confirmation. N’enregistrez pas plusieurs fois en réaction à une attente. Examinez ensuite le contenu conservé et les éventuelles erreurs. Une navigation plus fluide ne doit pas s’accompagner de pertes de texte, de validations absentes ou d’un verrou d’édition neutralisé.

Si un changement ne convient pas, restaurez la préférence d’écran, réactivez le composant ou retirez le réglage testé. Évitez une restauration globale de production pour annuler une préférence utilisateur. Gardez la sauvegarde et les détails de l’essai tant que les comptes et écrans concernés n’ont pas été contrôlés.

Prévenir et transmettre un diagnostic exploitable

Conservez une fiche courte avec l’écran, le compte ou le rôle, la date, la requête et les conditions de mesure. Notez la préférence de pagination retenue et la cause confirmée, si elle l’est. Une nouvelle extension peut ajouter un calcul à une liste ou une requête à chaque ouverture ; reprenez le contrôle après les changements importants.

Ne confondez pas un allègement visuel avec un arrêt de traitement et ne désactivez pas les mécanismes de travail WordPress pour supprimer leurs requêtes du rapport. Les outils natifs suffisent aux premières comparaisons ; une collecte facultative doit répondre à une question précise.

Si le problème persiste, fournissez à l’éditeur ou à l’hébergeur l’écran, l’heure et son fuseau, le statut, la durée observée et les comparaisons avant et après. Précisez si le délai précède la réponse, concerne un échange secondaire ou apparaît pendant l’interaction. Ce dossier permet une intervention ciblée sans modifier plusieurs couches du site en même temps.

Comparer la page publique et l’écran réellement lent

Sur la copie WordPress, la liste des articles comporte quarante lignes et une extension synthétique ajoute une colonne qui attend brièvement pour chacune. Le document public arrive en 469 ms en médiane au départ. La réception du document administratif se termine en 941 ms. Son premier octet arrive en 275 ms. Le début et la fin de la réponse donnent ici deux repères différents, car le serveur envoie une partie du document avant de terminer la liste.

Sur votre site, relevez le chemin exact de l’écran lent, le compte utilisé, le filtre, la page de résultats et le nombre de lignes. Ouvrez ensuite une page publique dans une fenêtre déconnectée et mesurez son document. Pour la liste, conservez la même recherche et le même compte d’un essai à l’autre. Si le document administratif arrive rapidement et que l’écran reste bloqué ensuite, passez au contrôle du navigateur et des requêtes de l’interface.

Après chargement d’une page, ce court relevé dans la Console donne deux repères depuis le début de la navigation. Il lit les mesures du document courant. Comparez les valeurs sur plusieurs ouvertures de la même liste.

const navigation = performance.getEntriesByType('navigation')[0];
console.table({
  premier_octet_ms: Math.round(navigation.responseStart),
  dernier_octet_du_document_ms: Math.round(navigation.responseEnd),
});

Mesurer le nombre de lignes avant d’isoler un composant

Dans le banc, Options de l’écran ramène la liste de quarante à dix lignes. La colonne reste présente et le dernier octet arrive en 477 ms au lieu de 941 ms. Le test rétablit ensuite quarante lignes et désactive la seule extension de test dans la copie. La liste retrouve ses quarante résultats sans la colonne de test et la réponse se termine en 309 ms.

Sur la copie, commencez par noter le nombre d’éléments actuel. Réduisez-le dans Options de l’écran et vérifiez que vous pouvez retrouver les autres articles avec la pagination ou le filtre. Pour attribuer le coût à un composant, remettez le nombre initial avant la comparaison avec l’extension désactivée. Si cette extension fournit une fonction nécessaire, vérifiez aussi les dépendances et la fonction qu’elle apporte. La désactivation sert à diagnostiquer le coût dans la copie. Une correction durable peut consister à limiter le travail de la colonne ou à le faire exécuter sur demande.

Vérifier la reprise et les fonctions utiles

Le banc réactive l’extension de test et retrouve quarante cellules de la colonne avec une fin de document à 943 ms en médiane. La page publique garde son repère. Sur votre copie, revenez à l’état de référence si la comparaison supprime une fonction utile. Contrôlez à nouveau le filtre, les éléments accessibles et le trajet vers l’éditeur. Notez si la lenteur revient avec le seul composant réactivé.

Les mesures locales concernent la liste des articles et un délai imposé dans une colonne synthétique. Pour votre site, transmettez l’écran, le filtre, le nombre de lignes et l’état du composant avec les relevés avant et après. Ce sont les points de départ pour comparer le même écran dans les journaux ou dans le profileur autorisé.