Le WordPress d'aujourd'hui, décodé pour les développeurs

Thèmes

Cloudflare Zaraz et un thème classique : déporter le JS tiers sans casser le Customizer

Configuration de Cloudflare Zaraz pour exécuter les scripts tiers côté serveur Cloudflare, sans perturber la prévisualisation du Customizer d'un thème classique.

Par Clément Hadrot • 1 juillet 2026 • 5 min de lecture • Aucun commentaire
Cloudflare Zaraz et un thème classique : déporter le JS tiers sans casser le Customizer
<script src="https://connect.facebook.net/..."></script>
<script src="https://www.googletagmanager.com/gtm.js?id=..."></script>
<script src="https://cdn.hotjar.com/..."></script>

Trois lignes parmi six scripts tiers chargés au démarrage sur un thème classique maintenu depuis plusieurs années, chacune ajoutée à un moment différent par une équipe marketing différente, sans jamais faire l’objet d’un audit de performance global. Cloudflare Zaraz propose de déporter l’exécution de ces scripts côté serveur Cloudflare plutôt que dans le navigateur du visiteur, réduisant considérablement leur impact sur le temps de chargement perçu — à condition de ne pas casser, au passage, la prévisualisation en direct du Customizer WordPress, largement utilisée par l’équipe éditoriale de ce thème classique.

Ce billet détaille la configuration retenue pour ce déport de scripts tiers. Il ne traite ni la migration complète du thème vers l’éditeur de site, ni le tag manager natif de WordPress introduit par ailleurs : uniquement la cohabitation entre Zaraz et le Customizer.

Ce que change Zaraz par rapport à un chargement classique

Zaraz reçoit les événements du site via un petit script de collecte léger, puis exécute la logique des outils tiers (pixels de suivi, gestionnaires de balises, outils d’analyse comportementale) directement sur l’infrastructure Cloudflare, sans que le navigateur du visiteur n’ait à télécharger et exécuter chacun des scripts tiers correspondants.

function agence_theme_charger_zaraz() {
    // Le script de collecte Zaraz remplace les balises tierces individuelles
    wp_enqueue_script(
        'zaraz-collecte',
        'https://mon-domaine.fr/cdn-cgi/zaraz/s.js',
        array(),
        null,
        false
    );
}
add_action( 'wp_enqueue_scripts', 'agence_theme_charger_zaraz' );

Le problème rencontré avec le Customizer

Le Customizer WordPress affiche un aperçu en direct du site dans une iframe, avec des rechargements fréquents à chaque modification d’un réglage par l’utilisateur. Ce comportement pose deux problèmes distincts avec Zaraz activé sans précaution : d’une part, chaque rechargement de l’aperçu envoie de nouveaux événements de suivi vers les outils tiers configurés dans Zaraz, faussant les statistiques réelles de fréquentation du site ; d’autre part, certains outils tiers exécutés via Zaraz injectent des éléments visuels (bannières de consentement, widgets de chat) qui perturbent l’affichage de l’aperçu du Customizer, rendant l’édition en direct peu lisible pour l’équipe éditoriale.

Diagnostiquer via les outils de développement

L’inspection du réseau dans l’aperçu du Customizer confirmait l’envoi répété d’événements vers Zaraz à chaque interaction de réglage, avec un compteur de sessions qui grimpait de façon anormale dans le tableau de bord Zaraz pendant une simple session d’édition, sans qu’aucun visiteur réel ne soit impliqué.

L'essentiel à retenir : Zaraz exécute les scripts tiers côté serveur Cloudflare plutôt que dans le navigateur ; Le Customizer WordPress a besoin d'un mode de prévisualisation distinct pour rester fonctionnel ; Une exclusion ciblée sur l'aperçu évite de casser l'expérience d'édition en direct

Le correctif : détecter le contexte de prévisualisation

WordPress fournit une fonction native, is_customize_preview(), qui retourne vrai uniquement lorsque la page est affichée dans le contexte de l’aperçu du Customizer. Conditionner le chargement du script de collecte Zaraz à l’absence de ce contexte règle le problème à la racine.

function agence_theme_charger_zaraz() {
    if ( is_customize_preview() ) {
        return; // ne jamais charger Zaraz dans l'aperçu du Customizer
    }

    wp_enqueue_script(
        'zaraz-collecte',
        'https://mon-domaine.fr/cdn-cgi/zaraz/s.js',
        array(),
        null,
        false
    );
}
add_action( 'wp_enqueue_scripts', 'agence_theme_charger_zaraz' );

Ce simple ajout de condition suffit à isoler complètement le contexte d’édition du contexte de visite réelle du site, sans nécessiter de configuration supplémentaire côté Cloudflare Zaraz lui-même.

Étendre la vigilance aux autres contextes d’aperçu

  • Aperçu de brouillon d’article (is_preview()), également à exclure du chargement de Zaraz
  • Environnement de préproduction dupliqué depuis la production, à isoler via une variable d’environnement dédiée plutôt que de dupliquer la configuration Zaraz elle-même
  • Comptes d’administration en navigation normale du site (hors Customizer), qui restent volontairement inclus dans le suivi pour ne pas fausser l’audit du comportement réel d’un compte élevé sur le site public

Vérifier le résultat après déploiement

Après ce correctif, le tableau de bord Zaraz a été surveillé pendant une semaine de sessions d’édition intensive du Customizer par l’équipe marketing du client, sans qu’aucun événement parasite ne remonte plus dans les statistiques de fréquentation. L’aperçu du Customizer, de son côté, a retrouvé un affichage stable, sans injection intempestive d’éléments visuels tiers pendant l’édition en direct.

Tout outil de suivi tiers, quelle que soit sa méthode de chargement, doit systématiquement être exclu explicitement des contextes d’aperçu et d’édition de WordPress. L’oubli de cette exclusion fausse durablement les données de suivi sans que personne ne s’en aperçoive immédiatement.

Pour aller plus loin

Déporter des scripts tiers vers Cloudflare Zaraz apporte un gain de performance réel sur un thème classique alourdi par des années d’ajouts marketing successifs, mais ce gain ne doit jamais se faire au prix d’une expérience d’édition dégradée pour l’équipe qui maintient le site au quotidien. Une simple condition sur le contexte de prévisualisation, ajoutée dès la mise en place initiale plutôt que découverte après coup, évite ce compromis.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi