Element Caching est une fonctionnalité d’optimisation d’Elementor qui s’attaque à un maillon souvent oublié de la performance : le temps que passe le serveur à générer le HTML de chaque widget avant même d’envoyer la page au navigateur. Sur une page construite avec de nombreux widgets, en particulier des grilles dynamiques qui interrogent la base de données, ce temps de génération peut représenter une part significative du délai de réponse serveur, invisible dans les outils qui ne mesurent que le poids ou le rendu côté navigateur.
Ce billet explique le fonctionnement réel de ce cache, comment le régler widget par widget, et pourquoi il ne faut surtout pas l’activer aveuglément sur du contenu personnalisé.
Ce que fait réellement Element Caching
Contrairement à un cache de page complet (comme celui d’un plugin de cache classique qui stocke la page HTML entière), Element Caching stocke le HTML généré par Elementor pour un widget ou une section précise, après son premier rendu. Lors des visites suivantes, si aucune modification n’a été apportée au widget dans l’éditeur, Elementor réutilise ce HTML déjà généré plutôt que de le recalculer, ce qui évite notamment de relancer les requêtes de base de données associées aux widgets dynamiques comme les grilles d’articles.
Le cache se vide automatiquement à chaque modification du widget concerné dans l’éditeur, et peut aussi être vidé manuellement depuis les réglages avancés d’Elementor si une source de données externe change sans passer par l’éditeur.
Activer le cache par widget
Le réglage se trouve dans l’onglet Avancé de chaque widget, section Cache. Par défaut, Elementor recommande son activation pour les widgets dont le contenu ne change pas selon le visiteur : une grille d’articles de blog, un widget d’image, un widget de texte statique.
// Réglage exposé dans le panneau widget (onglet Avancé) :
// "Cache" -> Oui / Non
// Stocké côté serveur, invalidé à l'enregistrement du widget
Les cas d’incompatibilité à connaître
Le piège principal d’Element Caching concerne les widgets dont le contenu dépend du visiteur ou du contexte de navigation. Un widget affichant « Bonjour {prénom} » via un dynamic tag lié à l’utilisateur connecté, un compteur de produits dans le panier, ou un widget affichant la date et l’heure courantes ne doivent jamais être mis en cache à ce niveau : le premier visiteur à charger la page figerait son propre contenu pour tous les visiteurs suivants, jusqu’à la prochaine invalidation du cache.
Sur un site testé, un widget affichant le nombre d’articles restants en stock avait été mis en cache par erreur lors d’une activation groupée trop rapide : le chiffre affiché est resté bloqué à sa valeur initiale pendant plusieurs jours, jusqu’à ce qu’un client signale une incohérence avec le stock réel.
Mesurer le gain réel
Sur une page d’accueil comportant trois grilles d’articles dynamiques (actualités, produits mis en avant, témoignages tirés d’un type de contenu personnalisé), le temps de réponse serveur mesuré via l’en-tête Server-Timing et l’outil de développement du navigateur est passé de 410 ms à 220 ms après activation du cache sur ces trois widgets, soit une réduction proche de 190 ms. Ce gain porte spécifiquement sur le temps de génération serveur : il n’a aucun effet sur le poids des images ou des scripts déjà chargés côté navigateur, qui relèvent d’autres leviers d’optimisation.
Comment procéder par étapes
- Lister les widgets dynamiques de la page (grilles, boucles, widgets liés à un type de contenu personnalisé) et vérifier qu’aucun ne dépend du visiteur ou de l’heure de consultation.
- Activer le cache widget par widget plutôt que globalement, en testant après chaque activation que le contenu reste correct.
- Mesurer le temps de réponse serveur avant et après, sur la page réelle, pas sur une page de test simplifiée.
- Documenter quels widgets sont en cache, pour qu’une future modification de contenu dynamique pense à vérifier l’invalidation.
Conseil maison : ne jamais activer Element Caching sur un widget sans avoir listé explicitement, en amont, toutes les sources de variation possible de son contenu. Le gain de performance ne vaut jamais le coût d’un contenu obsolète affiché à un client.
En résumé
Element Caching cible un maillon de performance souvent négligé, le temps de génération serveur des widgets, avec un gain mesurable sur les pages riches en contenu dynamique. Ce n’est cependant pas un réglage à activer par réflexe sur l’ensemble d’un site : chaque widget candidat mérite une vérification précise de ce qui pourrait varier dans son contenu avant d’accepter de le figer temporairement en cache.
