Un développeur modifie la couleur d’un bouton sur la page d’accueil d’un site client, enregistre, actualise la page publique : rien ne change. Réflexe immédiat, purger le cache d’Elementor depuis Outils > Régénérer les fichiers CSS. Toujours rien. Le client, lui, voit la même chose depuis son téléphone en 4G, ce qui écarte l’hypothèse d’un cache navigateur local. Ce scénario, banal en apparence, cache en réalité une interaction entre trois systèmes de cache qui fonctionnent indépendamment les uns des autres.
Sur ce projet, le site utilisait Elementor Pro, un objet cache Redis activé côté hébergement pour accélérer les requêtes de base de données, et un plugin de cache de page complet pour servir du HTML statique aux visiteurs non connectés. Chacune de ces couches a sa propre logique de purge, et purger l’une ne purge pas automatiquement les autres.
Symptôme : la modification existe en base, mais ne s’affiche pas
En vérifiant directement dans l’éditeur Elementor, la nouvelle couleur du bouton était bien enregistrée et visible dans l’aperçu d’édition. Le problème ne venait donc ni d’une mauvaise sauvegarde, ni d’une erreur de saisie. La donnée existait correctement en base de données, mais n’atteignait jamais le visiteur final.
Diagnostic couche par couche
La méthode qui a permis d’isoler la cause a consisté à tester chaque couche indépendamment plutôt que de tout purger d’un coup, ce qui aurait masqué l’origine exacte du blocage :
- Vérifier d’abord le cache Elementor lui-même : les fichiers CSS générés dans
wp-content/uploads/elementor/css/doivent être régénérés après toute modification de style, sans quoi l’ancien fichier CSS continue d’être servi même si les données du widget ont changé - Vérifier ensuite le cache objet : si Redis ou Memcached est actif, les requêtes de récupération des metadonnées de la page peuvent renvoyer une version mise en cache tant que la clé correspondante n’a pas expiré ou été invalidée
- Vérifier enfin le cache de page : un plugin comme celui utilisé sur ce projet sert une copie HTML complète de la page, générée avant la modification, tant que sa propre purge n’a pas été déclenchée
Dans ce cas précis, la régénération des fichiers CSS Elementor avait bien fonctionné, mais le cache objet Redis conservait encore l’ancienne version sérialisée des données de la page en base, car son délai d’expiration était réglé sur douze heures. Purger manuellement l’objet cache a résolu le problème immédiatement.
L’ordre de purge qui évite de tourner en rond
Purger dans le bon ordre évite de fausses conclusions. Commencer toujours par Elementor (Outils > Régénérer les fichiers CSS), puis le cache objet si l’hébergeur en propose un tableau de bord dédié, puis enfin le cache de page. Purger le cache de page en premier peut donner l’impression trompeuse que le problème est résolu si une ancienne version du CSS Elementor est encore active, créant une fausse piste.
| Couche de cache | Ce qu’elle conserve | Comment la purger |
|---|---|---|
| Cache Elementor | Fichiers CSS générés par widget | Outils > Régénérer les fichiers CSS |
| Cache objet (Redis/Memcached) | Résultats de requêtes et métadonnées | Tableau de bord hébergeur ou wp cache flush |
| Cache de page tiers | HTML complet de la page rendue | Bouton de purge du plugin concerné |
Prévention pour la suite du projet
- Documenter dans le wiki interne de l’agence l’ordre de purge spécifique à chaque hébergement client, car la configuration varie d’un projet à l’autre
- Configurer, quand c’est possible, une purge automatique en cascade déclenchée à la sauvegarde d’une page Elementor plutôt que de compter sur une intervention manuelle
- Réduire la durée d’expiration du cache objet sur les environnements de recette pour accélérer les cycles de test
Sur un site avec plusieurs couches de cache, ne concluez jamais qu’une modification a échoué avant d’avoir purgé chaque couche séparément et vérifié le résultat entre chaque étape.
En résumé
La génération des fichiers CSS d’Elementor n’est qu’une étape parmi d’autres sur un site correctement optimisé en cache à plusieurs niveaux. Comprendre quelle couche sert quelle donnée évite de perdre du temps à re-modifier un contenu qui était pourtant correct dès la première sauvegarde. La check-list d’ordre de purge, une fois documentée pour un hébergement donné, se réutilise ensuite sur tous les projets similaires.
