Ajax est une technologie web basée sur JavaScript qui vous aide à créer des sites web dynamiques et interactifs. WordPress utilise Ajax pour alimenter un grand nombre des fonctions de base de la zone d’administration, telles que la sauvegarde automatique des articles, la gestion des sessions utilisateur et les notifications.
Par défaut, WordPress dirige tous les appels Ajax via le fichier admin-ajax.php situé dans le répertoire /wp-admin du site.
De nombreuses requêtes Ajax simultanées peuvent entraîner une forte utilisation d’admin-ajax.php, ce qui a pour conséquence de ralentir considérablement le serveur et le site web. C’est l’un des problèmes les plus courants rencontrés par de nombreux sites WordPress non optimisés. Il se manifeste généralement par un site web lent ou une erreur HTTP 5xx (la plupart du temps des erreurs 504 ou 502).
Dans cet article, vous découvrirez le fichier admin-ajax.php de WordPress, son fonctionnement, ses avantages et ses inconvénients, et comment diagnostiquer et résoudre le problème de la forte utilisation d’admin-ajax.php.
Prêt à partir ? On y va !
Qu’est-ce que le fichier admin-ajax.php ?
Le fichier admin-ajax.php contient tout le code pour le routage des requêtes Ajax sur WordPress. Son but premier est d’établir une connexion entre le client et le serveur en utilisant Ajax. WordPress l’utilise pour actualiser le contenu de la page sans la recharger, le rendant ainsi dynamique et interactive pour les utilisateurs.
Comme le cœur de WordPress utilise déjà Ajax pour alimenter ses diverses fonctions d’administration, vous pouvez utiliser les mêmes fonctions pour utiliser Ajax sur WordPress. Tout ce que vous avez à faire est d’enregistrer une action, de la faire pointer vers le fichier admin-ajax.php de votre site, et de définir comment vous voulez qu’elle retourne la valeur. Vous pouvez la paramétrer pour qu’elle retourne du HTML, du JSON, ou même du XML.
Selon WordPress Trac, le fichier admin-ajax.php est apparu pour la première fois dans WordPress 2.1. Il est également appelé Ajax Admin dans la communauté du développement de WordPress.
Le tableau ci-dessus ne montre que le nombre de requêtes admin-ajax.php, et non leur provenance. C’est un bon moyen pour voir quand les pics se produisent. Vous pouvez le combiner avec d’autres techniques mentionnées dans cet article pour réduire la cause principale.
Vous pouvez également utiliser Chrome DevTools pour voir combien de requêtes sont envoyées vers admin-ajax.php. Vous pouvez également consulter l’onglet Timings de la section Network pour connaître le temps nécessaire au traitement de ces requêtes.
Pour ce qui est de trouver la raison exacte de l’utilisation élevée d’admin-ajax.php, il y a principalement deux causes principales : l’une due à l’interface publique, et l’autre à l’administration. Nous allons discuter de ces deux causes ci-dessous.
Comment déboguer l’utilisation élevée d’admin-ajax.php sur WordPress
Les extensions tierces sont l’une des raisons les plus courantes de l’utilisation élevée d’admin-ajax.php. Généralement, ce problème est constaté sur l’interface publique du site et apparaît fréquemment dans les rapports de test de vitesse.
Mais les extensions ne sont pas les seules coupables ici car les thèmes, le cœur de WordPress, le serveur web, et une attaque DDoS peuvent également être la raison de l’utilisation élevée d’Admin Ajax.
Examinons-les plus en détail.
Comment déterminer l’origine de la forte utilisation d’admin-ajax.php pour les extensions et les thèmes
Ajax est souvent utilisé par les développeurs de WordPress pour créer des extensions et des thèmes dynamiques et interactifs. Parmi les exemples les plus populaires, citons l’ajout de fonctionnalités telles que la recherche en direct, les filtres de produits, le défilement infini, le panier d’achat dynamique et la boîte de dialogue.
Ce n’est pas parce qu’une extension utilise Ajax qu’elle ralentira votre site.
Habituellement, Admin Ajax se charge vers la fin du chargement de la page. Vous pouvez également configurer les requêtes Ajax pour qu’elles se chargent de manière asynchrone, de sorte que cela n’ait que peu ou pas d’effet sur la performance perçue de la page par l’utilisateur.
Comme vous pouvez le voir dans le rapport WebPageTest ci-dessus, admin-ajax.php se charge vers la fin de la file d’attente des requêtes, mais il prend toujours 780 ms. C’est beaucoup de temps pour une seule requête.
Lorsque les développeurs n’implémentent pas correctement Ajax sur WordPress, cela peut conduire à des problèmes de performance drastiques. Le rapport GTmetrix ci-dessus est un parfait exemple d’un tel comportement.
Vous pouvez également utiliser GTmetrix pour creuser dans les données individuelles des publications et des réponses. Vous pouvez utiliser cette fonction pour identifier la cause du problème.
Pour ce faire, allez à l’onglet Waterfall du rapport GTmetrix, puis trouvez et cliquez sur l’élément POST admin-ajax.php. Vous verrez trois onglets pour cette requête : Headers, Post, and Response.
En consultant les onglets Post et Response de la requête, vous trouverez quelques indices pour découvrir les raisons du problème de performance. Pour ce site, vous pouvez voir des indices dans l’onglet Response.
Vous pouvez voir qu’une partie de la réponse a quelque chose à voir avec une balise d’entrée dont l’identifiant est défini sur « fusion-form-nonce-656 ».
Une recherche rapide sur cet indice vous mènera au site web de ThemeFusion, les créateurs du thème Avada. Vous pouvez donc en conclure que la requête provient du thème ou de l’une des extensions qui lui sont associés.
Dans ce cas, vous devez d’abord vous assurer que le thème Avada et toutes ses extensions sont entièrement mis à jour. Si cela ne résout pas le problème, vous pouvez alors essayer de désactiver le thème et voir si cela résout le problème.
Contrairement à la désactivation d’une extension, la désactivation d’un thème n’est pas possible dans la plupart des cas. Par conséquent, essayez d’optimiser le thème pour éliminer les goulots d’étranglement. Vous pouvez également contacter l’équipe de support du thème pour voir si elle peut vous proposer une meilleure solution.
Le test d’un autre site web lent dans GTmetrix a permis de trouver des problèmes similaires avec les extensions Visual Composer page builder et Notification Bar.
Heureusement, si vous ne parvenez pas à résoudre un problème avec l’extension, vous avez la possibilité d’essayer de nombreuses autres extensions. Par exemple, en ce qui concerne les constructeurs de pages, vous pouvez également essayer Beaver Builder ou Elementor.
Comment déterminer l’origine de la forte utilisation d’admin-ajax.php
Il arrive que les données de Post et de Response présentées dans les rapports de test de vitesse ne soient pas aussi claires et simples. Ici, trouver l’origine d’une utilisation élevée d’admin-ajax.php n’est pas aussi facile. Dans ce cas, vous pouvez toujours le faire à l’ancienne.
Désactivez toutes les extensions de votre site, videz le cache de votre site (s’il y en a un), puis refaites un test de vitesse. Si admin-ajax.php est toujours présent, alors le coupable le plus probable est le thème. Mais s’il est introuvable, vous devez alors activer chaque extension une par une et effectuer les tests de vitesse à chaque fois. En procédant par élimination, vous trouverez l’origine du problème.
Conseil : l’utilisation d’un environnement de staging (par exemple, l‘environnement de staging de Kinsta) est un excellent moyen d’effectuer des tests sur votre site sans affecter votre site en production. Une fois que vous avez déterminé la cause et résolu le problème dans l’environnement de staging, vous pouvez effectuer les changements votre site en production.
Diagnostiquer les problèmes de serveur pour l’administration avec admin-ajax.php
La deuxième raison la plus fréquente de l’utilisation élevée de admin-ajax.php est l’API WordPress Heartbeat qui génère des appels Ajax fréquents, ce qui entraîne une forte utilisation du processeur sur le serveur. En général, cela est dû au fait que de nombreux utilisateurs sont connectés au tableau de bord de l’administration de WordPress. Vous ne verrez donc pas cela apparaître dans les tests de vitesse.
Par défaut, l’API Heartbeat interroge le fichier admin-ajax.php toutes les 15 secondes pour enregistrer automatiquement des articles ou des pages. Si vous utilisez un serveur d’hébergement partagé, vous n’avez pas beaucoup de ressources serveur dédiées à votre site. Si vous modifiez un article ou une page et que vous laissez l’onglet ouvert pendant un certain temps, cela peut entraîner un grand nombre de requêtes Ajax pour l’administration.
Par exemple, lorsque vous rédigez ou modifiez des articles, un seul utilisateur peut générer 240 requêtes en une heure !
Cela fait beaucoup de requêtes en arrière-plan avec un seul utilisateur. Imaginez maintenant un site où plusieurs éditeurs sont connectés en même temps. Un tel site peut accumuler rapidement des requêtes Ajax, ce qui génère une forte utilisation du processeur.
C’est ce qu’a découvert DARTDrones en préparant son site WooCommerce à l’augmentation du trafic attendue à la suite de sa participation à l’émission Shark Tank.
Avant d’être présenté à l’émission télévisée, le site de DARTDrones recevait plus de 4 100 appels admin-ajax.php en une journée avec seulement 2 000 visiteurs uniques. C’est un faible ratio de requêtes par rapport au nombre de visiteurs.
Les enquêteurs ont remarqué l’URL référente /wp-admin et ont correctement déterminé la cause profonde. Ces demandes étaient dues aux administrateurs et rédacteurs de DARTDrones qui mettaient fréquemment le site à jour en prévision de l’émission.
WordPress a corrigé en partie ce problème de l’API Heartbeat depuis longtemps. Par exemple, vous pouvez réduire la fréquence des requêtes générées par l’API Heartbeat sur les hébergeurs ayant des ressources limitées. Elle se suspend également après une heure d’inactivité du clavier/souris/touche.
Trafic élevé dû à une attaque DDoS ou à des spams
Le fait de submerger votre site d’une attaque DDoS ou de robots de spam peut également entraîner une utilisation élevée d’admin-ajax.php. Toutefois, une telle attaque ne vise pas nécessairement à augmenter les requêtes Ajax de l’administration. Il s’agit simplement d’un dommage collatéral.
Si votre site fait l’objet d’une attaque DDoS, votre priorité devrait être de le faire passer derrière un CDN/WAF robuste comme Cloudflare ou Sucuri. Chaque plan d’hébergement avec Kinsta comprend l’intégration gratuite de Cloudflare et le CDN de Kinsta, qui peuvent vous aider dans une large mesure à décharger les ressources de votre site web.
Pour en savoir plus sur la manière de protéger vos sites web contre des attaques malveillantes comme celles-ci, vous pouvez vous référer à notre guide détaillé sur la manière de mettre fin à une attaque DDoS.
Résumé
WordPress utilise Ajax dans son API Heartbeat pour mettre en œuvre un grand nombre de ses fonctionnalités de base. Cependant, cela peut entraîner une augmentation des temps de chargement s’il n’est pas utilisé correctement. Cela est généralement dû à une fréquence élevée de requêtes au fichier admin-ajax.php.
Dans cet article, vous avez appris les différentes causes de la forte utilisation d’admin-ajax.php, comment diagnostiquer ce qui est responsable de ce symptôme et comment vous pouvez y remédier. Dans la plupart des cas, le fait de suivre ce guide devrait vous permettre de remettre votre site sur pied et de le faire fonctionner sans problème en un rien de temps.
Toutefois, dans certains cas, la mise à niveau vers un serveur doté de ressources plus importantes est la seule solution viable. Surtout pour les cas d’utilisation exigeants comme les sites de eCommerce et les sites d’adhésion. Si vous gérez un tel site, envisagez de passer à un hébergeur WordPress infogéré qui a l’expérience de ce type de problèmes de performances.
Si vous êtes toujours aux prises avec une utilisation élevée d’admin-ajax.php sur votre site WordPress, faites-nous part de vos réflexions dans les commentaires.
Laisser un commentaire