« Il doit y avoir une tâche cron d’Elementor qui tourne toutes les nuits » : cette hypothèse, entendue régulièrement en diagnostic de performance serveur, mérite d’être vérifiée avant d’être acceptée. Consulter la liste des tâches planifiées d’un site utilisant Elementor, via une commande WP-CLI ou un plugin de gestion de cron, révèle une réalité différente de l’intuition la plus répandue.
Cette clarification n’est pas un détail théorique : elle évite de chercher un coupable planifié là où le problème réel se situe ailleurs, dans un mécanisme déclenché par événement plutôt que par horaire.
Ce que révèle une inspection réelle du cron
La commande WP-CLI suivante liste l’ensemble des tâches planifiées enregistrées sur un site :
wp cron event listSur un site utilisant Elementor et Elementor Pro sans extension tierce additionnelle, cette commande ne révèle généralement aucune tâche portant un nom explicite lié au cœur du plugin. Les tâches présentes proviennent du cœur WordPress lui-même : vérification des mises à jour (wp_version_check), nettoyage des révisions et des corbeilles, vérification des mises à jour de plugins et de thèmes, ou encore des tâches ajoutées par d’autres extensions installées sur le site, comme un plugin de sauvegarde ou de cache.
Alors, comment Elementor régénère-t-il son CSS ?
Le mécanisme le plus souvent confondu avec une tâche planifiée est la régénération des fichiers CSS d’Elementor, stockés dans le dossier wp-content/uploads/elementor/css/. Cette régénération se déclenche par événement, pas par horaire : elle a lieu quand une page est enregistrée dans l’éditeur, quand les réglages globaux changent, ou manuellement via le bouton « Régénérer les fichiers CSS & données » présent dans les outils d’Elementor. Aucune planification horaire ne l’automatise en tâche de fond.
Cette distinction compte particulièrement en diagnostic de performance : un pic de charge CPU observé à un horaire précis et récurrent, chaque nuit à la même heure par exemple, ne peut donc pas raisonnablement être attribué à une régénération CSS d’Elementor, qui ne se produit que suite à une action explicite d’un utilisateur ou d’un script d’import personnalisé.
Les cas où une tâche WP-Cron existe réellement
Certaines extensions complémentaires à l’écosystème Elementor, ou certains widgets personnalisés développés sur mesure, ajoutent bien leurs propres tâches planifiées via wp_schedule_event(). C’est le cas, par exemple, d’un widget d’import automatique de contenu externe, ou d’une extension de sauvegarde de Kits programmée à intervalle régulier. Ces tâches n’appartiennent pas au cœur d’Elementor : elles relèvent du code ajouté spécifiquement pour le projet.
- Vérifier systématiquement
wp cron event listavant de suspecter Elementor d’une tâche planifiée. - Identifier le propriétaire réel de chaque tâche listée : cœur WordPress, extension tierce, ou code sur mesure du projet.
- Rechercher
wp_schedule_eventdans le code du thème et des extensions pour localiser une tâche suspecte.
Un exemple de fausse piste évitée
Sur un projet où un ralentissement récurrent survenait chaque jour à la même heure, l’hypothèse initiale pointait vers une tâche cron d’Elementor. L’inspection via wp cron event list a révélé une tâche de sauvegarde complète du site, planifiée par un plugin de sauvegarde installé bien après Elementor, sans lien avec ce dernier. Corriger l’horaire de cette sauvegarde, en dehors des heures de forte fréquentation, a résolu le problème en quelques minutes, une fois la vraie cause identifiée.
Vérifier avant de supposer : une simple commande WP-CLI évite souvent des heures de diagnostic basées sur une intuition erronée.
En résumé
Elementor, dans son fonctionnement de base, ne repose quasiment pas sur des tâches planifiées : ses opérations les plus lourdes se déclenchent par événement. Prêter au plugin des comportements planifiés qu’il n’exécute pas conduit à des diagnostics erronés, souvent au détriment d’une cause bien plus simple à corriger une fois correctement identifiée.
