# wp-cron trop sollicité : l’impact caché sur le TTFB de chaque visiteur WordPress

> wp-cron.php se déclenche à chaque visite et alourdit le temps de réponse d'un site à fort trafic. Comment le désactiver proprement et le remplacer par une tâche système.

- Auteur : Clément Hadrot
- Publié le : 2020-10-24
- Mis à jour le : 2020-10-24
- Catégorie : Performance
- URL : https://wpmoderne.dev.wordpress-developpement.fr/performance/wp-cron-trop-sollicite-impact-ttfb/

## L’essentiel

- wp-cron se déclenche par défaut à chaque requête HTTP, pas à intervalle fixe
- DISABLE_WP_CRON coupe ce déclenchement, une tâche système prend le relais
- Un cron système toutes les minutes suffit pour la plupart des sites

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.

> L'essentiel à retenir : wp-cron se déclenche par défaut à chaque requête HTTP, pas à intervalle fixe ; DISABLE_WP_CRON coupe ce déclenchement, une tâche système prend le relais ; Un cron système toutes les minutes suffit pour la plupart des sites

## 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>&1
```

Une 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 --quiet
```

## Vé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 list
```

Sur 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.