Beaucoup de développeurs découvrent tard un détail pourtant documenté depuis longtemps : WordPress n’a pas de véritable planificateur de tâches en arrière-plan. Ce que l’on appelle « wp-cron » n’est qu’un script, wp-cron.php, déclenché à la fin du traitement de certaines requêtes de visiteurs, quand une tâche planifiée est en retard. Sur un site à faible trafic, cette approche passe inaperçue. Sur un site à fort trafic, elle peut ajouter une latence perceptible à des visiteurs qui n’ont strictement rien demandé.
C’est ce qui s’est produit sur un site d’annonces immobilières recevant plusieurs dizaines de milliers de visites par jour, où une tâche planifiée toutes les cinq minutes déclenchait, en cascade, une requête HTTP interne supplémentaire sur une portion significative des chargements de page.
Comprendre le mécanisme réel de wp-cron
À chaque chargement de page non mis en cache, WordPress appelle la fonction wp_cron() via un hook attaché à init. Cette fonction vérifie si des tâches planifiées, stockées dans l’option cron, ont dépassé leur heure d’exécution prévue. Si c’est le cas, WordPress déclenche une requête HTTP asynchrone vers wp-cron.php pour exécuter ces tâches, en parallèle de la réponse envoyée au visiteur.
Le problème n’est pas l’exécution des tâches en elle-même, mais le fait que cette vérification et cette requête interne s’ajoutent au temps de traitement de la requête initiale, surtout quand le serveur est déjà sous forte charge et que la requête HTTP interne doit attendre un processus PHP-FPM disponible.
Mesurer l’impact réel avant d’agir
Avant toute modification, l’impact a été mesuré avec l’extension Query Monitor, dont le panneau dédié affiche la liste des tâches planifiées et leur prochaine exécution. En comparant le temps de réponse de pages identiques, certaines déclenchant une vérification de cron en retard et d’autres non, l’écart mesuré tournait autour de 150 millisecondes supplémentaires, un chiffre non négligeable sur un objectif de temps de réponse serveur sous les 200 millisecondes.
Désactiver le déclenchement par visite
La constante DISABLE_WP_CRON, ajoutée dans wp-config.php, empêche WordPress de vérifier et de déclencher les tâches en retard à chaque requête de visiteur :
define( 'DISABLE_WP_CRON', true );Cette constante ne désactive pas le système de planification lui-même : les tâches restent enregistrées dans l’option cron, elles ne sont simplement plus vérifiées ni exécutées via une requête déclenchée par un visiteur.
La remplacer par une tâche système
Sur un serveur où l’équipe gère elle-même l’hébergement, la solution la plus fiable consiste à appeler wp-cron.php à intervalle régulier via une tâche système, indépendamment du trafic réel du site :
* * * * * curl -s https://exemple.fr/wp-cron.php?doing_wp_cron >/dev/null 2>&1Une exécution chaque minute reste largement suffisante pour la plupart des sites, y compris ceux qui planifient des tâches à cinq ou dix minutes d’intervalle : WordPress se charge lui-même de ne déclencher que les tâches réellement en retard. Sur un serveur mutualisé sans accès à la crontab système, l’alternative WP-CLI est équivalente et plus légère qu’un appel HTTP :
* * * * * cd /var/www/exemple.fr && wp cron event run --due-now --quietVérifier que rien ne casse après le changement
Après la bascule, il est indispensable de vérifier que les tâches critiques continuent de s’exécuter : publication d’articles planifiés, purge de transients expirés, envoi de résumés par courriel pour certaines extensions. La commande WP-CLI suivante liste les tâches en attente et leur horaire :
wp cron event listSur ce projet, un oubli initial a laissé la tâche wp_scheduled_delete s’accumuler pendant plusieurs jours sans exécution système en place, avant que la crontab ne soit correctement configurée. Un contrôle a posteriori a permis de le repérer et de le corriger rapidement.
En résumé
Le mécanisme de wp-cron déclenché par visite est un choix de conception pratique pour un hébergement mutualisé sans accès système, mais il devient un frein mesurable dès qu’un site gère son propre serveur et reçoit un trafic conséquent. Désactiver ce déclenchement au profit d’une tâche système planifiée chaque minute retire une charge invisible du chemin critique de chaque visiteur, sans rien perdre en fiabilité d’exécution des tâches.
