# Cloudflare APO fige une popup Elementor Pro ouverte pour tous les visiteurs

> Symptôme rencontré après activation d'APO sur un site avec popups Elementor Pro, diagnostic de la règle de cache à exclure et correctif appliqué.

- Auteur : WordPress Développement
- Publié le : 2023-06-20
- Mis à jour le : 2023-06-20
- Catégorie : Elementor
- URL : https://www.wpmoderne.fr/elementor/cloudflare-apo-popup-elementor-pro-cache-fige/

## L’essentiel

- Symptôme repéré via un retour utilisateur
- Cause liée au cache HTML complet d'APO
- Règle d'exclusion ciblée sur le cookie de fermeture

Une capture d'écran envoyée par un visiteur, popup grande ouverte au chargement de la page d'accueil, alors qu'elle ne devait s'afficher qu'après quinze secondes de navigation. C'est ce signal, remonté deux jours après l'activation de Cloudflare APO (Automatic Platform Optimization) sur un site utilisant plusieurs popups Elementor Pro, qui a déclenché l'investigation décrite ici.

APO met en cache la page HTML complète, y compris son état au moment de la génération côté serveur, directement au niveau du edge Cloudflare, ce qui inclut par défaut le markup des popups Elementor Pro tel qu'il existait lors de la première requête ayant rempli le cache.

## Symptôme observé

Sur ce projet, une popup de bienvenue avec inscription à la newsletter était configurée pour s'ouvrir après un délai de quinze secondes ou au déclenchement d'une intention de sortie. Après activation d'APO, un visiteur sur trois signalait la voir apparue immédiatement, parfois déjà fermée, parfois bloquée en position ouverte quelle que soit l'action effectuée sur la page.

Le comportement erratique tenait à ce que différents visiteurs recevaient une version de page HTML mise en cache à des instants différents du cycle de vie JavaScript de la popup : APO capturait la page côté edge avant que le script d'Elementor Pro n'ait fini d'initialiser l'état masqué de la popup pour ce visiteur précis.

## Diagnostic pas à pas

### Étape 1 : confirmer que le HTML est bien mis en cache

Une inspection des en-têtes de réponse HTTP, via l'onglet réseau du navigateur, a confirmé la présence de l'en-tête `cf-cache-status: HIT` sur les pages concernées, preuve qu'APO servait bien une version statique du HTML généré côté serveur.

> L'essentiel à retenir : Symptôme repéré via un retour utilisateur ; Cause liée au cache HTML complet d'APO ; Règle d'exclusion ciblée sur le cookie de fermeture

### Étape 2 : identifier le rôle du cookie de fermeture

Elementor Pro utilise un mécanisme côté client (généralement du `localStorage` ou un cookie selon la configuration du déclencheur) pour se souvenir qu'une popup a déjà été fermée par un visiteur. Le problème ne venait donc pas du cookie lui-même, correctement géré côté client, mais du markup HTML figé qui affichait la popup dans un état visuel incohérent avant même que le script de gestion d'état n'ait eu le temps de s'exécuter sur une page servie depuis le cache edge.

### Étape 3 : reproduire en navigation privée

En vidant le cache local et en testant depuis plusieurs localisations géographiques différentes (donc plusieurs nœuds edge Cloudflare), certains renvoyaient une version de page capturée pendant une phase de test où la popup avait été temporairement forcée en affichage permanent depuis l'éditeur, ce qui confirmait que le cache HTML avait figé un état transitoire.

## Le correctif appliqué

La solution ne consiste pas à désactiver APO, dont les gains de performance restent réels sur ce projet, mais à exclure du cache de page les URL contenant certains paramètres liés à l'aperçu Elementor, et surtout à forcer une purge systématique du cache APO à chaque publication ou modification d'un template contenant une popup.

```
# Règle de cache Cloudflare (Page Rule) ciblée
URL : exemple.fr/*
Paramètre à exclure du cache : elementor-preview
Cache Level : Bypass sur ce paramètre uniquement

# Purge automatique après modification d'un template popup
wp cache flush
curl -X POST "https://api.cloudflare.com/client/v4/zones/ZONE_ID/purge_cache" \
  -H "Authorization: Bearer TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"purge_everything":false,"files":["https://exemple.fr/"]}'
```

## Prévention pour la suite

- Purger systématiquement le cache APO après toute modification d'un Popup Elementor Pro
- Exclure les paramètres d'aperçu Elementor du cache edge
- Tester l'ouverture d'une popup en navigation privée après chaque déploiement de template

Ce correctif ne couvre volontairement pas l'optimisation d'images Cloudflare ni le réglage du cache serveur WordPress classique (objet, page), deux sujets traités séparément dans l'infrastructure de ce site.

> Un cache de page à l'échelle du edge ne connaît rien de l'état JavaScript d'un visiteur : toute logique d'affichage conditionnelle mérite d'être testée explicitement une fois ce cache activé.

## En résumé

Une popup Elementor Pro figée en position ouverte après activation d'APO n'est pas un bug d'Elementor : c'est la conséquence attendue d'un cache HTML complet qui capture un état transitoire. La correction passe par une exclusion ciblée et une discipline de purge, pas par un abandon des gains de performance qu'APO apporte par ailleurs.
