# Cloudflare Zaraz et l’éditeur de site : déporter les scripts tiers du template

> Un template alourdi par des scripts de mesure d'audience et de marketing tiers. Comment Cloudflare Zaraz permet de les exécuter côté serveur, sans toucher au rendu du template.

- Auteur : Clément Hadrot
- Publié le : 2025-05-24
- Mis à jour le : 2025-05-24
- Catégorie : FSE
- URL : https://wpmoderne.dev.wordpress-developpement.fr/fse/cloudflare-zaraz-editeur-site-scripts-tiers/

## L’essentiel

- Les scripts tiers s'exécutent côté serveur Cloudflare, pas dans le navigateur
- Le template ne charge plus qu'un minuscule script de chargement Zaraz
- Les événements personnalisés se déclenchent via une fonction dataLayer standard

`wrangler zaraz export` : la commande qui a permis de sauvegarder la configuration existante avant de commencer à démonter, un par un, les six scripts tiers chargés directement dans le `template-part` d'en-tête d'un site vitrine à fort trafic publicitaire.

Le template `header.html` du thème bloc chargeait, en plus du nécessaire, un pixel de conversion publicitaire, un outil de heatmap, un chat en ligne et trois scripts de mesure d'audience différents, hérités de campagnes successives jamais nettoyées. Chaque script ajoutait sa propre requête réseau, son propre délai d'exécution, et parfois un blocage du rendu perceptible au chargement.

## Le problème : des scripts qui s'accumulent dans le template

Sur un thème bloc, ces scripts tiers sont généralement insérés via un bloc HTML personnalisé dans la partie de template d'en-tête, ou injectés via le hook `wp_head` depuis `functions.php`. Le problème n'est pas propre à l'éditeur de site : il touche tout site qui accumule des scripts marketing au fil du temps. Mais sur un template partagé par toutes les pages du site, chaque script supplémentaire pèse sur l'ensemble du trafic, pas seulement sur une page isolée.

## Le principe de Zaraz : exécuter les outils tiers côté edge

Cloudflare Zaraz charge un seul petit script de chargement dans le navigateur, puis relaie les événements vers les outils tiers configurés (mesure d'audience, pixels publicitaires, chat) depuis l'infrastructure Cloudflare elle-même, plutôt que depuis le navigateur du visiteur. Le navigateur n'a plus besoin de télécharger et d'exécuter le code de chacun de ces outils : il envoie un événement, et Zaraz se charge de la suite côté serveur.

> L'essentiel à retenir : Les scripts tiers s'exécutent côté serveur Cloudflare, pas dans le navigateur ; Le template ne charge plus qu'un minuscule script de chargement Zaraz ; Les événements personnalisés se déclenchent via une fonction dataLayer standard

## Snippet commenté : remplacer les scripts par des événements Zaraz

La première étape consiste à retirer purement et simplement les balises `<script>` du template d'en-tête du thème bloc :

```
<!-- avant : dans header.html, un bloc HTML personnalisé -->
<script src="https://outil-tiers.example.com/tag.js"></script>
<script>outilTiers.track('page_view');</script>
```

Ces outils sont ensuite déclarés une seule fois dans le tableau de bord Zaraz, chacun associé à un déclencheur (chargement de page, clic sur un bouton, soumission de formulaire). Côté template, il ne reste plus qu'à déclencher un événement générique, standardisé, au moment opportun :

```
<script>
  zaraz.track('vue_page_produit', {
    categorie: 'catalogue',
    identifiant_produit: '{{ id_produit }}'
  });
</script>
```

Ce même événement `vue_page_produit` peut ensuite être relayé par Zaraz vers plusieurs outils configurés côté tableau de bord (mesure d'audience, pixel publicitaire), sans que le template ait besoin de connaître l'existence de chacun de ces outils individuellement.

## Ce qui reste légitimement côté client

Certains scripts ne se prêtent pas à ce déport : un widget de chat en ligne qui doit afficher une interface visuelle interactive, par exemple, ne peut pas s'exécuter uniquement côté serveur. Sur ce projet, le chat a donc été conservé en chargement direct, mais différé grâce à l'attribut `defer` et déclenché uniquement après une interaction de l'utilisateur (survol du bouton flottant), ce qui limite son impact sur le chargement initial sans renoncer à la fonctionnalité.

## Variantes selon le contexte du projet

- **Site à fort trafic publicitaire** : privilégier Zaraz pour tous les pixels de conversion, dont l'exécution côté serveur limite aussi le blocage par les bloqueurs de publicité côté navigateur.
- **Site avec peu d'outils tiers** : le gain reste marginal ; la complexité de configuration ajoutée par Zaraz peut ne pas se justifier pour un ou deux scripts seulement.
- **Site déjà sous un autre CDN** : Zaraz est spécifique à l'infrastructure Cloudflare et suppose que le domaine soit déjà proxifié par Cloudflare ; ce n'est pas une brique indépendante installable ailleurs.

> Sur ce projet, la règle retenue a été simple : si un outil tiers n'a pas besoin d'afficher quelque chose à l'écran, il n'a rien à faire dans le navigateur du visiteur.

## En résumé

Déporter l'exécution des scripts tiers vers l'edge Cloudflare via Zaraz ne change rien au template lui-même une fois la migration faite : plus aucune balise `<script>` tierce à gérer directement dans `header.html`, seulement des appels d'événements génériques. Le gain se mesure surtout en nombre de requêtes réseau évitées côté navigateur et en simplicité de maintenance du template, débarrassé de six scripts accumulés au fil des campagnes. La documentation de référence reste celle de [Cloudflare Zaraz](https://developers.cloudflare.com/zaraz/) pour la configuration détaillée des outils et des déclencheurs.