# Cache d’un site Elementor livré : WP Rocket ou configuration maison > Réglages Performance d'Elementor, puis cache de page : WP Rocket ou configuration maison, avec les pièges de purge du CSS et une méthode de mesure. - Auteur : WordPress Développement - Publié le : 2026-10-18 - Mis à jour le : 2026-10-09 - Catégorie : Performance - URL : https://www.wpmoderne.fr/performance/cache-site-elementor-wp-rocket-ou-configuration-maison/ ## L’essentiel - Réglez d'abord l'onglet Performance d'Elementor, puis le cache de page - Toute purge du CSS Elementor doit entraîner la purge du cache de page - Mesurez avec un protocole reproductible avant de comparer deux configurations `wp elementor flush-css --regenerate` : cette commande, documentée par Elementor, supprime les fichiers CSS générés pour les pages construites avec l'éditeur puis les recrée immédiatement. Sans l'option `--regenerate`, les fichiers ne sont recréés qu'à la prochaine visite de chaque page. Toute la difficulté du cache d'un site Elementor tient dans cette nuance : si la « prochaine visite » est servie par un cache de page, PHP ne s'exécute pas, et le fichier CSS attendu peut ne jamais revenir. Ce sixième épisode de la série « Livrer un site Elementor en agence » compare deux façons de mettre un site livré en cache, WP Rocket ou une configuration maison, sans revenir sur le choix de l'hébergement, traité dans le quatrième épisode. ## Commencer par les réglages Performance d'Elementor Avant d'ajouter une couche de cache, réglez ce qu'Elementor fait lui-même. Dans les versions récentes, ces options se trouvent dans Elementor, Editor, Settings, onglet **Performance**, créé avec la version 3.22. - **CSS Print Method** : fichier CSS externe (recommandé par Elementor) ou CSS intégré dans chaque page. Le fichier externe se met en cache côté navigateur ; l'intégration évite les fichiers orphelins mais alourdit chaque page HTML, et la FAQ d'Elementor signale qu'elle peut entrer en conflit avec les mécanismes de cache sur les sites complexes. - **Optimized Image Loading** : ajoute `fetchpriority="high"` à l'image identifiée comme élément LCP et le chargement différé aux images situées sous la ligne de flottaison. - **Optimized Gutenberg Loading** : évite de charger les scripts et styles de l'éditeur de blocs qui ne servent pas. - **Element Cache** : met en cache le rendu des éléments, avec une durée d'expiration commune à tout le site, ou désactivé. Chaque élément peut ensuite être forcé en actif ou inactif dans son onglet Avancé ; les conteneurs, sections et colonnes sont mis en cache automatiquement. Elementor rappelle qu'il ne faut jamais l'activer sur un élément contenant des balises dynamiques ou un code court. - **Load Google Fonts Locally** : télécharge les polices utilisées dans `wp-content/uploads/elementor/fonts/`. Depuis la version 3.32.1, l'option est désactivée par défaut, et elle doit être réactivée si vous l'aviez cochée avant cette mise à jour. Ne cherchez plus les anciens interrupteurs « Improved Asset Loading » et « Improved CSS Loading » : le premier est actif par défaut depuis la version 3.15, le second a été intégré au cœur avec la version 3.24. ## Le piège central : un CSS régénéré derrière une page figée > L'essentiel à retenir : Réglez d'abord l'onglet Performance d'Elementor, puis le cache de page ; Toute purge du CSS Elementor doit entraîner la purge du cache de page ; Mesurez avec un protocole reproductible avant de comparer deux configurations Avec la méthode « fichier externe », chaque page Elementor charge un fichier de styles qui lui est propre. Le cache de page, lui, conserve le HTML tel qu'il était au moment de sa création, références aux fichiers CSS comprises. Trois situations produisent alors une page sans mise en forme ou avec une mise en forme périmée : 1. vous cliquez sur **Clear Files & Data** (Elementor, Editor, Tools) après une migration ou une modification des réglages globaux : les fichiers disparaissent, mais les pages en cache continuent de les appeler ; 2. le client modifie le kit global (couleurs, typographies) : le CSS global change, les pages en cache non purgées peuvent continuer d'appeler l'ancienne version ; 3. une couche de cache supplémentaire (serveur ou réseau de diffusion) n'est pas purgée alors que l'extension de cache l'a été. La règle qui en découle est simple : toute purge des fichiers d'Elementor doit déclencher la purge du cache de page, et dans cet ordre. La documentation d'Elementor elle-même, dans sa page consacrée aux modifications qui n'apparaissent pas en ligne, recommande de vider ou de désactiver les couches de cache avant de conclure à un bogue. ## WP Rocket : ce qu'il automatise et ce qu'il coûte [WP Rocket](/go/wp-rocket/) gère le cache de page, le préchargement, le chargement différé, le report de l'exécution JavaScript et la suppression du CSS inutilisé. Sa documentation consacrée à Elementor, mise à jour en avril 2026, décrit précisément son comportement : quand la méthode d'impression du CSS est « fichier externe », le cache est vidé partiellement ou entièrement lorsqu'une page est mise à jour depuis l'éditeur, lorsque le CSS Elementor d'une page change ou lorsque le mode maintenance d'Elementor est modifié. Les fichiers CSS par page d'Elementor sont exclus d'office de la minification, pour éviter des purges trop fréquentes. La même documentation recommande de désactiver, dans l'onglet Performance d'Elementor, Optimized Image Loading, Lazy Load Background Images et Element Cache, ce dernier pouvant afficher un contenu de widget incorrect alors que WP Rocket met déjà en cache la page entière. Elle signale aussi que le report de l'exécution JavaScript peut casser certains modules d'Elementor, que le chargement différé du JavaScript peut casser l'effet « Sticky », et propose des exclusions pour les deux cas. Pour la suppression du CSS inutilisé, le CSS calculé est régénéré automatiquement tous les 30 jours et après modification d'une page. Les licences, relevées en octobre 2026 et affichées en euros sur la page tarifaire officielle, sont annuelles : Single à 49,95 € pour un site, Plus à 99,95 € pour trois sites, Multi à partir de 249,95 € pour cinquante sites (des paliers à cent et cinq cents sites existent). Les taxes peuvent s'ajouter selon le pays. Un point manque à l'automatisme : la documentation ne mentionne pas de purge déclenchée par le bouton Clear Files & Data. Elementor émet pourtant l'action `elementor/core/files/clear_cache` après avoir vidé ses fichiers (présente dans son code source depuis la version 2.1.0), et WP Rocket documente la fonction `rocket_clean_domain()` pour vider tout le cache. Une extension à chargement obligatoire de quelques lignes relie les deux : ``` Un cache que le client ne sait pas vider tout seul finira par lui montrer un site qu'il ne reconnaît pas. ## Mesurer sans inventer de chiffres Ne comparez jamais deux configurations sur une impression ou sur un seul passage d'outil. Voici le protocole que nous appliquons, reproductible par n'importe qui : 1. choisissez trois adresses représentatives : l'accueil, la page Elementor la plus lourde, une page avec formulaire ; 2. déconnectez-vous et vérifiez que la page est bien servie depuis le cache (pour WP Rocket, la dernière ligne du code source contient un commentaire avec la mention `cached@` suivie d'un horodatage) ; 3. mesurez le temps jusqu'au premier octet onze fois et retenez la médiane, cache froid puis cache chaud ; 4. mesurez les indicateurs de rendu dans un outil de laboratoire avec un bridage réseau et processeur identique, cinq passages, médiane ; 5. ne changez qu'un réglage entre deux séries et notez les versions d'Elementor, de l'extension et de PHP. ``` for i in $(seq 1 11); do curl -s -o /dev/null -w '%{time_starttransfer}\n' https://www.exemple.fr/services/ done | sort -n | sed -n '6p' ``` Cette boucle affiche la médiane des onze mesures du temps jusqu'au premier octet, en secondes. Lancez-la depuis la même machine et le même réseau pour chaque configuration. ## Quand choisir l'un ou l'autre, et quand ne rien ajouter Prenez WP Rocket pour un site vitrine sur un hébergement mutualisé sans cache de page côté serveur, maintenu par une équipe qui veut des purges correctes sans écrire de code : l'intégration avec Elementor est documentée et suivie. Préférez la configuration maison lorsque l'hébergement fournit déjà un cache de page avec une méthode de purge documentée et que vous maîtrisez le petit module de synchronisation. Et n'ajoutez rien pour un site dont la majorité des pages sont personnalisées par utilisateur (espace membre, boutique avec panier) sans avoir d'abord défini les exclusions : un cache de page mal exclu est pire qu'aucun cache. Pour aller plus loin sur les réglages croisés, la [documentation de WP Rocket consacrée à Elementor](https://docs.wp-rocket.me/article/1745-using-elementor-with-wp-rocket) et la [page d'aide d'Elementor sur Element Caching](https://elementor.com/help/element-caching-help/) sont les deux références à relire à chaque version majeure. ## Conclusion Sur un site Elementor livré, le cache se règle en deux temps : d'abord les options Performance d'Elementor, sans doublon avec ce que fera l'extension, ensuite le cache de page. WP Rocket automatise l'essentiel des purges liées à l'éditeur pour un coût annuel connu ; une configuration maison fonctionne aussi bien, à condition de relier explicitement chaque vidage des fichiers d'Elementor à la purge du cache de page. Dans les deux cas, mesurez avec un protocole écrit, et livrez au client une procédure de purge qu'il peut appliquer sans vous appeler.