WP-Cron (wp-cron.php) : le désactiver et configurer un cron système | Optimisation des performances WordPress
Dans WordPress, les tâches Cron sont une fonction qui exécute automatiquement des tâches planifiées à une heure ou une date précise. Elles passent par le fichier wp-cron.php, que WordPress appelle à chaque chargement de page pour traiter les tâches planifiées. Cette méthode est simple, mais sur les sites à fort trafic elle peut dégrader les performances.
Ⅰ. Le fonctionnement de WP-Cron et ses problèmes de performances
Au lieu du système Cron traditionnel des serveurs Linux, WordPress propose sa propre fonction Cron, WP-Cron. WP-Cron passe par le fichier wp-cron.php : ⓐ à chaque visite du site, il vérifie s'il y a des tâches planifiées et les exécute, et ⓑ des extensions comme Rank Math et WP Rocket exécutent leurs propres tâches périodiques planifiées.
À l'inverse, sur les sites à fort trafic, wp-cron.php peut être appelé beaucoup trop souvent et surcharger le serveur. En particulier, quand plusieurs utilisateurs se connectent en même temps, des tâches cron en double s'exécutent, ce qui peut entraîner une hausse de l'utilisation du CPU, des réponses plus lentes, un chargement des pages plus lent et d'autres problèmes du même genre.
Ces limites structurelles de WP-Cron peuvent dégrader les performances de WordPress et, surtout sur les sites exigeants en performances, les boutiques en ligne et les portails d'actualité provoquer de graves goulots d'étranglement.
🔄 Fonctionnement et structure de WP-Cron
Ⅱ. Optimiser les performances de WordPress
Il existe de nombreuses façons d'optimiser les performances de WordPress. Après avoir optimisé le cache, le frontend et la base de données, on peut encore gagner grâce aux réglages de WP-Cron.
Les événements planifiés sont vérifiés à chaque chargement d'une page WordPress et, avec les tâches périodiques des extensions, il faut utiliser plus efficacement un WP-Cron peu efficace.
1️⃣ Tester WP-Cron
En vérifiant les tâches cron avec WP-CLI, on voit le Cron actif s'exécuter. On constate que des extensions comme Rank Math et WP Rocket exécutent leurs tâches planifiées chaque jour ou toutes les quelques minutes.
2️⃣ Configurer WP-Cron
WP-Cron est un planificateur virtuel qui gère les tâches planifiées de WordPress ; wp-cron.php s'exécute lors des visites. Mais l'exécution liée au trafic est instable et les appels excessifs peuvent charger le serveur : on le complète donc généralement par un cron système.
Au besoin, on recommande de définir DISABLE_WP_CRON dans wp-config.php pour désactiver WP-Cron, puis de l'exécuter régulièrement avec un cron Linux.
|
Catégorie |
Désactiver WP-Cron + exécuter uniquement le cron système |
|---|---|
|
Réglages |
Désactiver WP-Cron et exécuter wp-cron.php depuis le cron système |
|
Avantages |
Pas d'exécutions en double, exécution précise à heure fixe et faible charge serveur |
|
Inconvénients |
Certaines fonctions d'extensions peuvent s'arrêter, et une erreur de réglage risque de faire sauter des tâches |
|
Recommandé · Situation |
Adapté aux sites à fort trafic avec beaucoup de tâches planifiées |
La méthode ① a toutefois un inconvénient : elle désactive le préchargement (PreLoad) des extensions de cache comme WP Rocket, qui génère le cache chaque minute avant l'arrivée des visiteurs.
⚙️ Modifier le fichier wp-config.php
Vous pouvez le configurer en désactivant WP_CRON.
# Désactiver WP_CRON
define( 'DISABLE_WP_CRON', true );Pendant l'exécution de WP-Cron, WP_CRON_LOCK_TIMEOUT sert de [verrou temporel] qui bloque les autres tentatives d'exécution.
# 5 minutes = 300, toutes les 60 minutes = 3600
define('WP_CRON_LOCK_TIMEOUT', 300);Pour ces raisons, plutôt que de seulement désactiver WP-Cron dans le fichier wp-config.php, je recommande de le désactiver puis d'ajouter une tâche System Cron ; le serveur que je gère actuellement est d'ailleurs configuré ainsi.
⚙️ Activer un cron système sur un serveur Linux [base]
Vous pouvez l'activer par domaine.
# Exécuter toutes les 5 minutes
*/5 * * * * curl -s https://example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1
# Exécuter toutes les 30 minutes
*/30 * * * * curl -s https://example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1
# Exécuter toutes les heures
0 * * * * curl -s https://example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1
# Exécuter une fois par jour
0 3 * * * curl -s https://example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1Les quatre lignes ci-dessus sont des exemples par intervalle à ajouter à la crontab : à chaque heure fixée, curl appelle l'adresse [wp-cron.php], si bien que les tâches planifiées s'exécutent même sans visiteurs.
# Si le serveur est un serveur local
*/5 * * * * php /path/to/wordpress/wp-cron.php > /dev/null 2>&1
# Exécuter toutes les 30 minutes
*/30 * * * * php /path/to/wordpress/wp-cron.php > /dev/null 2>&1
# Exécuter toutes les heures
0 * * * * php /path/to/wordpress/wp-cron.php > /dev/null 2>&1
# Exécuter une fois par jour
0 3 * * * php /path/to/wordpress/wp-cron.php > /dev/null 2>&1Si WP-CLI est installé, vous pouvez ne définir qu'une ligne avec l'intervalle voulu. ▼
# Exécuter toutes les 5 minutes
*/5 * * * * cd /sites/example.com/files/ && flock -n ~/.wp_cron.lock /usr/local/bin/wp cron event run --due-now --quiet
# Exécuter toutes les 30 minutes
*/30 * * * * cd /sites/example.com/files/ && flock -n ~/.wp_cron.lock /usr/local/bin/wp cron event run --due-now --quiet
# Exécuter toutes les heures
0 * * * * cd /sites/example.com/files/ && flock -n ~/.wp_cron.lock /usr/local/bin/wp cron event run --due-now --quiet
# Exécuter une fois par jour
0 3 * * * cd /sites/example.com/files/ && flock -n ~/.wp_cron.lock /usr/local/bin/wp cron event run --due-now --quietAvec ce réglage, WP-CLI exécute sur le serveur uniquement les tâches planifiées arrivées à échéance grâce à l'option [--due-now], et [flock -n] saute une nouvelle exécution tant que la précédente n'est pas terminée.
⚙️ WP-CLI et cron système toutes les minutes, et éviter les tâches cron en double
Par défaut, WP_CRON ignore (saute) simplement les tâches quand la charge est forte et les relance plus tard. Désactivez le WP-Cron par défaut et réglez les tâches planifiées pour conserver un verrou de 5 minutes, afin que le cron système et WP-Cron ne s'exécutent pas en même temps.
define('DISABLE_WP_CRON', true); // désactive l'exécution automatique de WP-Cron
define('WP_CRON_LOCK_TIMEOUT', 300); // pas d'attente → ignoré ; conserve un verrou de 5 minutes pendant l'exécution d'une tâche planifiée
/* That's all, stop editing! Happy publishing. */Ajoutez l'option flock -n au cron système pour que, côté cron système, l'exécution se termine immédiatement.
# Réglage wp cron : flock -n → pas d'attente → arrêt immédiat
*/1 * * * * cd /sites/example.com/files/ && flock -n ~/.wp_cron.lock /usr/local/bin/wp cron event run --due-now --quietLe résultat de cette combinaison :
- L'exécution automatique interne de WP est désactivée → les tâches planifiées s'exécutent quel que soit le nombre de visiteurs
- Le cron système tente une exécution chaque minute → les tâches planifiées s'exécutent s'il y en a
- Une fois verrouillé, rien ne se relance pendant 5 minutes → évite les exécutions en double (en pratique, avec flock -n, WP_CRON_LOCK_TIMEOUT n'est pas vraiment nécessaire.)
Avec la prévention des doublons, le déroulement réel est le suivant :
- 08:00 → le cron système appelle wp-cron.php
- La tâche planifiée A s'exécute → verrou de 5 minutes posé
- 08:01 → le cron système appelle à nouveau
- La tâche A est verrouillée → pas d'exécution
- 08:02–08:04 → idem
- 08:05 → verrou levé → la tâche planifiée suivante s'exécute s'il y en a une
Au lieu que WordPress exécute les tâches automatiquement, c'est le système qui s'en charge. Et WP_CRON_LOCK_TIMEOUT sert de garde-fou supplémentaire contre les exécutions en double.
|
Catégorie |
WP_CRON_LOCK_TIMEOUT |
flock -n |
|---|---|---|
|
Type de verrou |
Interne à WordPress |
Niveau système |
|
Emplacement du verrou |
En base de données : doing_cron dans wp_options |
Fichier système : ~/.wp_cron.lock |
|
Attente ? |
❌ N'attend pas → saute |
❌ N'attend pas → s'arrête aussitôt |
|
Prévention des doublons |
✅ Évite les exécutions en double |
✅ Évite les exécutions en double |
Une fois terminé, vous pouvez vérifier avec une commande WP-CLI que le cron fonctionne toujours comme avant.
wp cron event list+-------------------------------------------+---------------------+-----------------------+---------------+
| hook | next_run_gmt | next_run_relative | recurrence |
+-------------------------------------------+---------------------+-----------------------+---------------+
| rocket_saas_pending_jobs | 2026-10-17 12:00:57 | now | 1 minute |
| action_scheduler_run_queue | 2026-10-17 12:00:57 | now | 1 minute |
| action_scheduler_run_queue_rucss | 2026-10-17 12:00:58 | now | 1 minute |
| rocket_saas_on_submit_jobs | 2026-10-17 12:00:58 | now | 1 minute |
| rocket_preload_process_pending | 2026-10-17 12:00:59 | now | 1 minute |
| rocket_purge_time_event | 2026-10-17 12:16:59 | 15 minutes 8 seconds | 1 hour |
| wp_privacy_delete_old_export_files | 2026-10-17 12:28:46 | 26 minutes 55 seconds | 1 hour |
| wp_update_user_counts | 2026-10-17 20:15:52 | 8 hours 14 minutes | 12 hours |
| rocket_preload_revert_old_failed_rows | 2026-10-17 20:17:59 | 8 hours 16 minutes | 12 hours |
| wp_version_check | 2026-10-17 20:28:34 | 8 hours 26 minutes | 12 hours |
| wp_update_plugins | 2026-10-17 20:58:34 | 8 hours 56 minutes | 12 hours |
| wp_update_themes | 2026-10-17 21:28:34 | 9 hours 26 minutes | 12 hours |
| recovery_mode_clean_expired_keys | 2026-10-18 07:28:46 | 19 hours 26 minutes | 1 day |
| wp_privacy_personal_data_cleanup_requests | 2026-10-18 07:28:46 | 19 hours 26 minutes | 1 day |
| wp_scheduled_delete | 2026-10-18 08:15:52 | 20 hours 14 minutes | 1 day |
| delete_expired_transients | 2026-10-18 08:15:52 | 20 hours 14 minutes | 1 day |
| wp_scheduled_auto_draft_delete | 2026-10-18 08:15:54 | 20 hours 14 minutes | 1 day |
| wp_delete_temp_updater_backups | 2026-10-18 08:16:17 | 20 hours 14 minutes | 1 week |
| rocket_update_dynamic_lists | 2026-10-18 08:16:57 | 20 hours 15 minutes | 1 week |
| rocket_saas_clean_rows_time_event | 2026-10-18 08:16:57 | 20 hours 15 minutes | 1 week |
| rocket_performance_hints_cleanup | 2026-10-18 08:16:58 | 20 hours 15 minutes | 1 day |
| rocket_preload_clean_rows_time_event | 2026-10-18 08:26:57 | 20 hours 25 minutes | 1 week |
| rocket_database_optimization_time_event | 2026-10-18 09:34:25 | 21 hours 32 minutes | 1 day |
| wp_site_health_scheduled_check | 2026-10-19 07:28:46 | 1 day 19 hours | 1 week |
| rocket_remove_saas_failed_jobs | 2026-10-19 08:16:58 | 1 day 20 hours | 3 days |
+-------------------------------------------+---------------------+-----------------------+---------------+La sortie affiche les noms des hooks enregistrés, l'heure de la prochaine exécution et la récurrence ; les tâches dont la colonne [next_run_relative] indique [now] sont traitées dès la prochaine exécution du cron.
Ⅲ. Quand les tâches planifiées de WP-Cron ne s'exécutent pas
On croit facilement qu'une tâche s'exécute d'elle-même à l'heure prévue, mais WP-Cron vérifie le travail à faire à l'arrivée d'une requête de page, pas à une heure donnée. Une tâche planifiée pour 14 h s'exécute à la première requête de 17 h si aucune n'arrive avant.
Quand l'exécution prend du retard, les articles planifiés s'affichent comme [Planification manquée](Missed schedule) dans la liste des articles. Dans [Améliorations recommandées] de l'onglet État de [Outils › Santé du site] apparaît [Un évènement planifié a échoué]. Les tâches enregistrées par les extensions, comme le préchargement du cache, attendent pour la même raison.
Les tâches planifiées s'exécutent dans [wp-cron.php] après une requête de page, la vérification du travail à faire et une requête de bouclage ; si l'un de ces maillons se rompt, elles ne s'exécutent pas, même une fois l'heure passée.
1️⃣ Quand il n'y a pas de visites ou que le cache de page répond
WP-Cron ne vérifie le travail à faire que lors des requêtes qui exécutent WordPress : aux heures sans visites, les tâches en retard s'accumulent. Même avec des visites, le résultat est le même si un fichier de cache de page répond, car WordPress ne s'exécute pas.
Sur un WordPress avec le cache de page de WP Rocket activé, l'ouverture de la page d'accueil mise en cache n'a enregistré aucun appel à [wp-cron.php]. En ouvrant une URL non mise en cache, un appel a été enregistré dans la même seconde et les cinq tâches en retard se sont exécutées.
Pour voir les tâches en retard, filtrez la liste WP-CLI sur les lignes dont [next_run_relative] vaut [now].
wp cron event list --next_run_relative=now --fields=hook,next_run_gmt,next_run_relative+----------------------------------+---------------------+-------------------+
| hook | next_run_gmt | next_run_relative |
+----------------------------------+---------------------+-------------------+
| rocket_saas_pending_jobs | 2026-10-17 14:49:57 | now |
| action_scheduler_run_queue | 2026-10-17 14:49:57 | now |
| action_scheduler_run_queue_rucss | 2026-10-17 14:49:58 | now |
| rocket_saas_on_submit_jobs | 2026-10-17 14:49:58 | now |
| rocket_preload_process_pending | 2026-10-17 14:49:59 | now |
+----------------------------------+---------------------+-------------------+[now] désigne une tâche dont l'heure prévue est déjà passée. Cette commande de liste charge elle aussi WordPress : s'il y a des tâches en retard, elle appelle [wp-cron.php] au moment où elle se termine. Relancez aussitôt la même commande, et les tâches que vous veniez de voir ont disparu de la liste.
Pour traiter les tâches en retard avant de corriger la cause, exécutez tout de suite avec WP-CLI uniquement celles qui sont échues.
wp cron event run --due-nowExecuted the cron event 'rocket_saas_pending_jobs' in 0.005s.
Executed the cron event 'action_scheduler_run_queue' in 0.006s.
Executed the cron event 'action_scheduler_run_queue_rucss' in 0.006s.
Executed the cron event 'rocket_saas_on_submit_jobs' in 0.005s.
Executed the cron event 'rocket_preload_process_pending' in 0.007s.
Success: Executed a total of 5 cron events.Cette commande exécute les tâches sur le serveur sans requête HTTP ; pour les traiter à intervalles fixes indépendamment des visites, enregistrez la même commande dans le cron système.
2️⃣ Quand seul DISABLE_WP_CRON est activé et qu'il n'y a pas de cron système
Avec [DISABLE_WP_CRON] à true, WP-Cron ne vérifie plus le travail à faire, même quand des requêtes de page arrivent. La documentation officielle indique elle aussi de s'inscrire d'abord au planificateur de tâches du système, puis d'ajouter cette constante ; ajouter la constante seule, sans inscription, ne laisse plus rien pour exécuter les tâches planifiées.
Avec la constante en place, un article planifié un peu plus d'une minute plus tard est resté [Planifié] une fois l'heure passée, et la colonne de date de la liste des articles affichait [Planification manquée]. Pendant ce temps, aucun appel à [wp-cron.php] n'a été enregistré.
Vous pouvez vérifier si la constante est active avec [wp cron test].
wp cron testError: The DISABLE_WP_CRON constant is set to true. WP-Cron spawning is disabled.Si cette erreur apparaît, vérifiez si le cron système contient une ligne qui appelle [wp-cron.php] ou exécute [wp cron event run]. Si la crontab du compte du site est vide, voici ce qui s'affiche.
crontab -lno crontab for exampleS'il n'y a pas de ligne, enregistrez un cron système ; si votre environnement ne le permet pas, supprimez la ligne [DISABLE_WP_CRON] pour réutiliser WP-Cron.
3️⃣ Quand la requête de bouclage du serveur est bloquée
Quand il y a du travail, WP-Cron fait envoyer par le serveur une requête vers [wp-cron.php] à l'adresse de son propre site pour exécuter les tâches : c'est la requête de bouclage. Si une règle de sécurité bloque [wp-cron.php], la requête de bouclage revient en 403 et les tâches ne s'exécutent pas.
Sur un serveur en configuration Nginx + Apache, restreindre [wp-cron.php] pour qu'il ne s'ouvre que depuis 127.0.0.1 a bloqué la requête de bouclage en 403. En effet, la requête que le serveur envoie à son propre domaine arrive par l'IP publique, et [wp cron test] renvoie le même code d'état.
wp cron testError: WP-Cron spawn returned HTTP status code: 403 ForbiddenAvec des tâches en retard de plus de cinq minutes, l'écran [Santé du site] affichait ensemble, dans [Améliorations recommandées], l'avertissement de bouclage et l'évènement planifié en échec.
Une fois la règle supprimée, [wp cron test] a de nouveau réussi. Si vous devez garder la règle, exécutez les tâches avec WP-CLI depuis le cron système. Une exécution WP-CLI ne passe pas par une requête HTTP : les tâches en retard ont été traitées même avec la même règle en place.
🔢 FAQ & contenus recommandés
ℹ️ Mention d'affiliation
Le contenu de ce site contient des liens d'affiliation. Lorsqu'un visiteur achète un produit ou un service via l'un de ces liens, le site perçoit une commission du vendeur. Le montant payé par l'acheteur(il baisse lors des promotions ↓), lui, n'augmente pas. Les prix, remises et stocks indiqués correspondent à la date de rédaction et peuvent différer ; vérifiez-les donc auprès du vendeur avant d'acheter. Les produits sont choisis et évalués selon nos propres critères, et les commissions n'influencent ni l'ordre de présentation ni le contenu des évaluations.