La plupart des tests de performances WordPress sont réalisés à un moment où le site est peu sollicité. Ils montrent comment une page se charge lorsque le site n’effectue pratiquement aucune autre tâche en arrière-plan.
Les sites en production fonctionnent rarement ainsi.
Un site WordPress actif peut accueillir des visiteurs tandis que des tâches cron s’exécutent, que des importations de produits sont en cours, que des sauvegardes sont effectuées, que des commandes sont synchronisées, que des extensions exécutent des tâches planifiées et que des mises à jour sont déployées dans le système. Les visiteurs ne voient pas ces opérations se dérouler, mais ils peuvent en ressentir les effets lorsque les pages se chargent lentement, que les formulaires sont saccadés, que les résultats de recherche s’affichent avec du retard ou que le processus de paiement prend plus de temps que d’habitude.
C’est pourquoi les problèmes de performances peuvent sembler aléatoires. Une page peut afficher de bons résultats lors d’un test le matin, puis ralentir quelques heures plus tard, même si rien n’a visiblement changé sur l’interface utilisateur.
Dans cet article, nous examinons comment les tâches cron, les importations, les sauvegardes et autres processus en arrière-plan affectent les performances de WordPress, comment repérer les signes avant-coureurs, et pourquoi l’hébergement joue un rôle si important pour maintenir la stabilité de l’expérience utilisateur pendant que le travail s’effectue en coulisses.
Pourquoi les sites WordPress ralentissent-ils lors d’activités en arrière-plan ?
Les tâches en arrière-plan s’exécutent peut-être à l’abri des regards, mais elles utilisent tout de même les ressources du serveur. Les tâches cron, les importations, les sauvegardes et les tâches des plugins peuvent toutes consommer des ressources PHP, exécuter des requêtes de base de données et utiliser de la mémoire, du CPU et des E/S disque pendant que les visiteurs utilisent le site.
C’est ce chevauchement qui est à l’origine des problèmes de performances. Un visiteur qui charge une page, envoie un formulaire, recherche des produits, se connecte à son compte ou passe une commande peut avoir besoin des mêmes ressources qu’une tâche en arrière-plan.
La mise en cache peut alléger quelque peu la charge. Si une page est déjà mise en cache, le serveur peut souvent la servir rapidement sans avoir à relancer WordPress depuis le début. Mais les requêtes dynamiques fonctionnent différemment. Les pages de commande, les tableaux de bord des comptes, les écrans d’administration, les portails d’adhésion, les résultats de recherche et les envois de formulaires nécessitent souvent une exécution en temps réel de PHP et des opérations sur la base de données. Lorsque des tâches en arrière-plan utilisent ces ressources, ce sont généralement ces parties du site qui ralentissent en premier.
C’est pourquoi les boutiques en ligne, les sites d’adhésion, les plateformes LMS, les éditeurs et les sites à fort trafic en subissent plus souvent les conséquences. Ils traitent les commandes, mettent à jour les fiches utilisateurs, gèrent les abonnements, publient du contenu, synchronisent les stocks, envoient des notifications et accompagnent les utilisateurs connectés tout au long de la journée.
De nombreux tests de performances ne tiennent pas compte de ces facteurs. Un site peut afficher de bonnes performances lorsqu’il est inactif, puis rencontrer des difficultés lorsque l’activité normale de production s’intensifie. Les performances réelles de WordPress dépendent de la capacité du site à gérer simultanément le trafic côté client et les tâches en arrière-plan.
Tâches d’arrière-plan courantes qui affectent les performances
L’activité en arrière-plan de WordPress provient de plusieurs sources. Certaines tâches émanent du cœur de WordPress. D’autres proviennent des extensions, des thèmes, des outils de commerce électronique, des intégrations marketing ou de l’environnement d’hébergement.
En soi, bon nombre de ces tâches sont normales et nécessaires. Le problème survient lorsqu’elles s’exécutent trop souvent, durent trop longtemps ou empiètent sur l’activité des visiteurs.
Voici quelques exemples courants :
- Évènements WP-Cron : WordPress et les extensions utilisent des tâches planifiées pour la publication, le nettoyage, la vérification des mises à jour, les notifications et d’autres tâches récurrentes.
- Importations de produits ou de contenu : les importations volumineuses peuvent mettre à jour des articles, des produits, des images, des catégories, des étiquettes, des champs personnalisés et des métadonnées.
- Mises à jour de la base de données : les extensions peuvent créer, modifier ou nettoyer des tables de la base de données lors de mises à jour ou de maintenances planifiées.
- Mises à jour des extensions et des thèmes : les mises à jour peuvent entraîner des modifications de fichiers, des migrations de base de données, le vidage du cache et des vérifications après mise à jour.
- Sauvegardes complètes du site ou de la base de données : les tâches de sauvegarde peuvent analyser des fichiers, exporter des tables de base de données, compresser des archives et transférer des données vers un espace de stockage.
- Traitement des commandes WooCommerce : les commandes peuvent déclencher l’envoi d’e-mails, des mises à jour des stocks, des changements d’état de commande, des calculs de taxes, des workflows d’expédition et des activités CRM.
- Renouvellements d’abonnements : les sites d’adhésion et d’abonnement traitent souvent des paiements récurrents, des modifications d’accès, des notifications de paiement échoué et des mises à jour de compte.
- Synchronisations des stocks : les boutiques en ligne peuvent synchroniser la disponibilité des produits entre les entrepôts, les systèmes de point de vente, les places de marché ou les flux des fournisseurs.
- Synchronisations CRM ou de marketing par e-mail : les envois de formulaires, les achats, les mises à jour des utilisateurs et les modifications de listes peuvent déclencher des transferts de données vers des plateformes tierces.
- Indexation de recherche : les extensions de recherche et de filtrage peuvent reconstruire des index, permettant ainsi aux visiteurs de rechercher des produits, des articles, des documents ou des annonces.
- Traitement des images : les téléversements et les importations peuvent déclencher la génération de miniatures, la compression, la conversion de format et la mise à jour des métadonnées.
- Publication planifiée : les éditeurs peuvent mettre en file d’attente des articles, des pages de destination, des lancements de produits ou du contenu de campagne afin qu’ils soient mis en ligne à des moments précis.
- Tâches de nettoyage des extensions : les extensions peuvent supprimer les données transitoires expirées, les anciennes sessions, les journaux, les révisions, les paniers abandonnés ou les fichiers temporaires.
Les importations et les synchronisations méritent une attention particulière, car elles peuvent générer une charge de travail importante sans paraître spectaculaires de l’extérieur. Une importation de produits, par exemple, peut impliquer des milliers d’écritures dans la base de données, des téléversements d’images, la génération de miniatures, des mises à jour de taxonomie, des modifications de métadonnées et le vidage du cache. Une synchronisation peut ressembler à un petit processus en arrière-plan, mais si elle s’exécute toutes les quelques minutes, elle peut solliciter la base de données tout au long de la journée.
L’impact dépend de la manière dont la tâche s’exécute. Une petite tâche par lots pendant une période creuse peut passer pratiquement inaperçue. Une importation volumineuse pendant les pics de trafic peut ralentir des processus tels que le commande et d’autres parties dynamiques du site. Le moment choisi, la taille du lot, la qualité des plugins, l’état de la base de données et les ressources d’hébergement déterminent tous l’ampleur des perturbations causées par l’activité en arrière-plan.
Pourquoi WP-Cron peut entraîner des pics de performance
WP-Cron aide WordPress à exécuter des tâches planifiées telles que la publication d’articles, la recherche de mises à jour, l’envoi de notifications, la suppression des données temporaires et le déclenchement des workflows des extensions.
Le problème, c’est que WP-Cron ne fonctionne pas par défaut comme un véritable cron de serveur. Au lieu de suivre un calendrier fixe défini par le serveur, il vérifie la présence de tâches en attente lorsqu’un visiteur accède au site. Cela signifie qu’un simple chargement de page peut également déclencher des tâches en arrière-plan.
Sur les sites très fréquentés, cela peut entraîner des pics de performance pendant les périodes de trafic intense. Les visiteurs qui chargent des pages, envoient des formulaires, parcourent des produits ou passent une commande peuvent constater des temps de réponse plus lents tandis que WordPress traite simultanément les tâches planifiées. Cette activité supplémentaire au niveau du PHP et de la base de données affecte le plus les requêtes dynamiques, précisément au moment où le site a besoin de ces ressources pour ses utilisateurs.
Les sites à faible trafic peuvent rencontrer le problème inverse. Si peu de personnes visitent le site, WP-Cron risque de ne pas s’exécuter à temps. Les tâches peuvent s’accumuler, puis être traitées toutes en même temps la prochaine fois qu’un visiteur charge le site. Ce visiteur risque alors de subir un ralentissement, car WordPress a un arriéré de tâches en attente à traiter.
Un véritable cron serveur offre à WordPress un calendrier plus prévisible. Au lieu d’attendre que le trafic des visiteurs déclenche les tâches, le serveur les exécute à des intervalles définis. Cela ne rend pas toutes les tâches en arrière-plan légères, mais cela réduit le risque que les tâches planifiées se déclenchent à des moments aléatoires pendant l’utilisation active du site.
Comment les sauvegardes peuvent affecter les performances de WordPress
Les sauvegardes protègent votre site ; elles sont donc indispensables. Si une mise à jour, une importation, un déploiement ou un problème de sécurité tourne mal, une sauvegarde récente peut vous aider à vous remettre rapidement d’aplomb.
Mais les sauvegardes nécessitent tout de même des ressources pour s’exécuter. L’impact dépend du fonctionnement de la sauvegarde, de la taille du site, de la fréquence des sauvegardes et des autres activités en cours sur le site au même moment.
Les sauvegardes basées sur des extensions peuvent être plus gourmandes en ressources, car elles s’exécutent souvent directement via WordPress. Une extension de sauvegarde peut analyser des fichiers, exporter des tables de base de données, compresser des archives, créer des fichiers temporaires et envoyer les données de sauvegarde vers un stockage distant. Ce processus peut consommer des ressources PHP, des connexions à la base de données, du CPU, de la mémoire et des E/S disque alors que les visiteurs continuent d’utiliser le site.
Les sites de grande envergure sont davantage affectés. Une boutique WooCommerce contenant des années de données de commandes, un éditeur disposant de milliers d’articles ou un site d’adhésion comptant de nombreux utilisateurs peut avoir davantage de fichiers, de tables, de journaux, de sessions et de métadonnées à traiter. Les sites riches en médias peuvent alourdir encore davantage la charge, car l’analyse et la compression des bibliothèques d’images prennent du temps.
Le moment choisi est également important. Une sauvegarde effectuée pendant une période creuse n’aura pratiquement aucun impact sur les visiteurs. La même sauvegarde, réalisée pendant une campagne de promotion, l’importation de produits, un pic d’achats ou une période d’activité administrative intense, peut entrer en concurrence avec le trafic en direct et ralentir les requêtes dynamiques.
Le problème n’est pas que les sauvegardes soient néfastes. C’est que la stratégie de sauvegarde influe sur les performances. Les workflows de sauvegarde au niveau de l’hébergement peuvent réduire le recours à des extensions de sauvegarde lourdes fonctionnant au sein de WordPress, aidant ainsi les équipes à protéger le site sans alourdir excessivement l’expérience utilisateur.
Pourquoi les problèmes de performances en arrière-plan semblent aléatoires
Les problèmes de performances en arrière-plan sont difficiles à détecter, car les symptômes apparaissent avant que la cause ne soit identifiée. Les propriétaires de sites remarquent le ralentissement, mais l’événement cron, l’importation, la sauvegarde ou la synchronisation à l’origine de ce ralentissement s’exécute déjà silencieusement en arrière-plan.
C’est ce décalage qui donne l’impression que ces problèmes sont irréguliers. Rien n’a visiblement changé sur l’interface utilisateur, mais la charge de travail en arrière-plan, elle, a évolué.
Les pages mises en cache continuent souvent de se charger sans problème. C’est généralement au niveau des parties dynamiques du site que l’impact est le plus visible : activité des comptes, workflows d’administration, envois de formulaires et pages nécessitant de nombreuses recherches. Ces requêtes dépendent de ressources PHP et de base de données en temps réel ; elles subissent donc la pression plus rapidement que les pages statiques ou mises en cache.
Parmi les signes courants, on peut citer :
- Des pics de temps de réponse du serveur sans augmentation notable du trafic
- Ralentissement des opérations de commande, de connexion, de recherche ou des actions d’administration
- Des délais d’expiration lors des importations, mises à jour, sauvegardes ou tâches liées aux extensions
- Les visiteurs signalent que le site semble instable
- Des tests de vitesse qui semblent normaux en dehors de la période où le problème se produit
- Des ralentissements qui surviennent à des moments similaires chaque jour ou chaque semaine
Dans de nombreux cas, la page elle-même n’est pas en cause. Le site est en concurrence avec sa propre charge de travail en arrière-plan.
Comment diagnostiquer les problèmes de performances en arrière-plan
Le meilleur point de départ est l’analyse temporelle. Si le site ralentit à certains moments de la journée, au cours de workflows spécifiques ou juste après une activité planifiée, ce schéma peut aider à identifier la cause.
Vérifier les tâches planifiées
Passez en revue les planifications de cron pour voir quelles tâches s’exécutent, à quelle fréquence et si plusieurs tâches se déclenchent simultanément. Une tâche planifiée isolée peut ne pas générer beaucoup de pression, mais plusieurs tâches s’exécutant en même temps peuvent rapidement augmenter la charge sur PHP et la base de données.
Examiner les sauvegardes, les importations et les synchronisations
Examinez les horaires des sauvegardes, les journaux d’importation et les journaux de synchronisation. Si les ralentissements coïncident avec des sauvegardes complètes du site, des exportations de base de données, des mises à jour de flux de produits, des synchronisations d’inventaire, des synchronisations CRM ou des intégrations de marketing par e-mail, il se peut que l’activité en arrière-plan entre en concurrence avec le trafic en temps réel.
Pour les sites WooCommerce, examinez également les actions planifiées. Le traitement des commandes, les renouvellements d’abonnement, les nouvelles tentatives de paiement, les e-mails, les webhooks et les mises à jour des stocks peuvent tous générer une charge de travail en arrière-plan. Un arriéré d’actions en attente ou ayant échoué peut indiquer que certaines tâches ne s’exécutent pas correctement.
Comparer les périodes de faible trafic aux pics de trafic
Mettez en correspondance les baisses de performances avec les tendances de trafic. Si les temps de réponse augmentent fortement lors d’un pic de trafic, le site a peut-être besoin de plus de capacité ou d’une mise en cache plus performante. Si les temps de réponse augmentent fortement alors que le trafic reste normal, l’activité en arrière-plan devient une cause plus probable.
Examiner les données du serveur et de l’application
Vérifiez l’utilisation des threads PHP pour voir si des requêtes dynamiques sont mises en file d’attente. Passez en revue les requêtes de base de données lentes, les journaux d’erreurs, les délais d’expiration, les problèmes de mémoire, les requêtes externes ayant échoué et les avertissements répétés des extensions.
Les données APM permettent de relier ces indices entre eux. Elles aident les équipes à identifier les transactions PHP lentes, les requêtes de base de données, les requêtes HTTP externes et les processus s’exécutant depuis longtemps pendant la période où le problème s’est produit. Au lieu de deviner quelle tâche a causé le ralentissement, elles peuvent voir où le site a consommé du temps et des ressources.
Critères à prendre en compte pour l’hébergement de sites WordPress gourmands en tâches d’arrière-plan
L’hébergement influe sur la capacité de WordPress à gérer simultanément le trafic en frontend et les tâches en arrière-plan. Même un site bien conçu peut rencontrer des difficultés si l’environnement d’hébergement ne dispose pas d’une capacité suffisante pour une activité de production réelle.
Pour les sites comportant fréquemment des tâches cron, des importations, des sauvegardes, des synchronisations ou des activités de commerce électronique, recherchez un hébergement qui inclut :
- L’isolation des ressources : les tâches en arrière-plan ne doivent pas dépendre d’un environnement mutualisé surchargé ni affecter facilement les autres sites.
- Une capacité PHP suffisante : si les tâches en arrière-plan consomment trop de capacité PHP, les requêtes dynamiques s’accumulent dans la file d’attente et les visiteurs doivent patienter.
- Prise en charge réelle des tâches cron sur le serveur : les tâches planifiées doivent s’exécuter selon un calendrier prévisible, plutôt que de dépendre du trafic des visiteurs pour se déclencher.
- Mise en cache performante : la mise en cache des pages, la prise en charge du CDN et la mise en cache en périphérie peuvent réduire le nombre de requêtes nécessitant des ressources PHP et de base de données.
- Prise en charge des performances de la base de données : les importations, les commandes, l’indexation des recherches, les renouvellements d’abonnement et les tâches de nettoyage dépendent tous de la bonne santé de la base de données.
- Workflows de sauvegarde fiables : les sauvegardes doivent protéger le site sans obliger chaque tâche de sauvegarde à passer par WordPress lui-même.
- Visibilité sur les performances : les outils d’analyse, les données d’utilisation de PHP, les données de cache, les codes de réponse, les journaux et les outils APM aident les équipes à comprendre ce qui s’est passé lors d’un ralentissement.
- Prise en charge spécifique à WordPress : les problèmes de performances en arrière-plan peuvent concerner le comportement des tâches cron, les plugins, les limites PHP, les requêtes de base de données, les règles de mise en cache, les appels d’API externes ou les actions planifiées de WooCommerce.
Ces fonctionnalités sont particulièrement importantes pour les sites qui dépendent d’éléments tels que les commandes, les connexions, les importations, les renouvellements, les synchronisations, les workflows de publication ou l’activité administrative. Plus un site dépend de ces charges de travail, plus il a besoin d’un hébergement conçu pour gérer simultanément les tâches frontend et backend.
Comment Kinsta garantit la réactivité de WordPress pendant les tâches en arrière-plan
Kinsta offre aux sites WordPress un environnement d’hébergement conçu pour une activité de production réelle, et non pas uniquement pour de simples tests de vitesse en conditions contrôlées.
Chaque site WordPress s’exécute dans son propre conteneur logiciel isolé, doté des ressources nécessaires à son fonctionnement, notamment Linux, NGINX, PHP et MySQL. Cette séparation rend l’utilisation des ressources plus prévisible lorsque des tâches planifiées, des importations, des sauvegardes ou des synchronisations s’exécutent en parallèle du trafic en direct.
Kinsta offre également aux équipes un meilleur contrôle sur les performances PHP. Les requêtes dynamiques telles que le paiement, la connexion, la recherche, les workflows d’administration, les importations et les activités liées à l’adhésion reposent toutes sur PHP. Dans MyKinsta, les équipes peuvent examiner et ajuster les réglages de performances PHP pour chaque site, afin que l’environnement soit mieux adapté à la charge de travail.
La mise en cache contribue également à réduire la charge. Kinsta utilise le cache FastCGI de NGINX pour la mise en cache des pages, ce qui permet aux pages pouvant être mises en cache de se charger sans utiliser de threads PHP. Cela permet de conserver davantage de capacité PHP disponible pour les requêtes dynamiques qui en ont besoin.
Pour les tâches planifiées, Kinsta prend en charge les tâches cron au niveau du serveur. Cela offre aux équipes un moyen plus prévisible d’exécuter des tâches en arrière-plan, plutôt que de dépendre uniquement des évènements WP-Cron déclenchés par les visites sur le site.
Kinsta offre également aux équipes une meilleure visibilité sur les problèmes de performances. MyKinsta Analytics affiche l’utilisation des ressources, les données de performances, les codes de réponse, le comportement du cache, l’utilisation du CDN et les tendances de trafic. Kinsta APM va plus loin en fournissant des données sur les processus PHP, les requêtes MySQL, les appels HTTP externes et les transactions lentes, ce qui facilite le suivi des baisses de performances liées à l’activité en arrière-plan.
En matière de sauvegardes, Kinsta propose des sauvegardes WordPress quotidiennes automatiques ainsi que des sauvegardes générées par le système, avec des points de restauration disponibles dans MyKinsta. Cela réduit la nécessité de recourir à des extensions de sauvegarde lourdes fonctionnant au sein de WordPress pour assurer une protection de routine.
Ensemble, ces fonctionnalités permettent à WordPress de rester réactif tandis que le site fonctionne en arrière-plan. Les tâches Cron continuent de s’exécuter, les importations sont toujours traitées et les sauvegardes restent essentielles. Mais les équipes bénéficient d’un meilleur contrôle, d’une meilleure visibilité et d’un environnement d’hébergement conçu pour gérer les charges de travail en arrière-plan tout en préservant l’expérience des visiteurs.
Préservez la rapidité de WordPress pendant que votre site fonctionne en arrière-plan
Votre site WordPress doit rester réactif pendant les activités de production réelles, et pas seulement lorsqu’il est inactif.
L’hébergement WordPress de Kinsta offre aux équipes l’infrastructure, la mise en cache, les contrôles de performances PHP, les sauvegardes, la prise en charge des tâches Cron et la visibilité dont elles ont besoin pour assurer le bon fonctionnement des sites très fréquentés.
Joel est un développeur d'interfaces publiques qui travaille chez Kinsta en tant que rédacteur technique. Il est un enseignant passionné par l'open source et a écrit plus de 200 articles techniques, principalement autour de JavaScript et de ses frameworks.
