Un widget affichant « Plus que 2 en stock » alors que l’article venait d’être réapprovisionné une heure plus tôt : ce décalage, signalé par l’équipe commerciale, a mis quatre heures à se résorber de lui-même avant l’investigation. Le site combinait Element Caching, la fonctionnalité native d’Elementor qui met en cache le rendu de certains widgets, et WP Rocket, un plugin de cache de page complet, activés en parallèle sans coordination explicite entre les deux.
Element Caching conserve le HTML déjà rendu d’un widget pendant une durée configurable, pour éviter de recalculer un rendu coûteux à chaque affichage. WP Rocket, de son côté, met en cache la page complète générée par WordPress. Sur le papier, les deux mécanismes semblent complémentaires ; en pratique, ils ignorent chacun les invalidations de l’autre.
Reproduire le symptôme
Le widget en cause affichait une information de stock issue d’une requête à une API tierce de gestion d’inventaire, mise à jour par un webhook externe qui invalidait un transient WordPress dédié dès qu’un changement de stock survenait. Element Caching, réglé sur une durée de trois heures pour ce widget, continuait pourtant d’afficher l’ancienne valeur bien après l’invalidation du transient, car son propre cache HTML ignorait complètement cette invalidation.
Le mécanisme du conflit
Element Caching stocke le rendu final du widget dans les métadonnées de la page, avec sa propre durée d’expiration, indépendante du contenu réellement affiché. Le webhook externe invalidait bien le transient source de la donnée de stock, mais rien ne déclenchait la purge du cache Element Caching correspondant : le widget continuait de restituer un rendu HTML figé jusqu’à l’expiration naturelle de sa propre durée de cache.
WP Rocket, en parallèle, mettait en cache la page HTML complète générée par WordPress, y compris ce rendu déjà périmé produit par Element Caching. Résultat : même après l’expiration du cache Element Caching, la page continuait de servir une version encore plus ancienne tant que le cache de page WP Rocket n’était pas lui-même purgé.
Le correctif appliqué
Étape 1 : exclure le widget concerné d’Element Caching
Plutôt que de désactiver Element Caching globalement, ce qui aurait annulé ses bénéfices sur les widgets réellement statiques du site, seul le widget de stock a été retiré du mécanisme, via le réglage disponible directement dans le panneau du widget concerné.
Étape 2 : déclencher une purge ciblée à chaque invalidation
add_action('stock_invalide', function ($produit_id) {
delete_transient('stock_' . $produit_id);
if (function_exists('rocket_clean_post')) {
$article_id = get_post_meta($produit_id, 'article_lie', true);
if ($article_id) {
rocket_clean_post($article_id);
}
}
});
La fonction rocket_clean_post(), exposée par WP Rocket, permet de purger le cache de page d’un article précis sans vider l’ensemble du cache du site, ce qui évite l’effet de bord d’une purge globale à chaque changement de stock, potentiellement très fréquent.
Prévention pour la suite
- Ne jamais activer Element Caching sur un widget dont le contenu dépend d’une source externe fréquemment mise à jour
- Coupler chaque invalidation de donnée dynamique à une purge ciblée du cache de page, pas une purge globale systématique
- Documenter, widget par widget, lequel utilise Element Caching et pourquoi, pour éviter ce type de diagnostic à refaire de zéro
Cet article ne couvre pas les autres réglages de WP Rocket (préchargement, minification, différé de chargement), ni la configuration d’un CDN en amont, deux sujets indépendants de ce conflit précis entre deux mécanismes de cache.
Deux caches valent rarement mieux qu’un sur une même donnée : chacun suppose souvent, à tort, que l’autre gère l’invalidation à sa place.
En résumé
Un contenu figé après activation simultanée d’Element Caching et de WP Rocket ne signale pas un bug de l’un ou de l’autre, mais l’absence de coordination entre deux mécanismes de cache indépendants. La solution durable consiste à exclure du cache de widget tout contenu dépendant d’une source externe et à propager explicitement chaque invalidation vers le cache de page.
