210 kilo-octets de JavaScript tiers en moins dans le fil principal du navigateur : c’est le résultat obtenu après avoir déporté, via Cloudflare Zaraz, le script d’un widget d’avis clients embarqué dans un bloc dynamique avis/widget-tiers. Le bloc chargeait jusque-là ce script directement dans le navigateur, avec un effet mesurable sur le temps de blocage total de la page.
Cette recette explique comment reconfigurer ce type de script pour qu’il s’exécute côté environnement Zaraz plutôt que dans le navigateur du visiteur, sans changer de CDN et sans passer par un gestionnaire de tags classique côté client. Elle ne couvre pas la migration vers un autre CDN ni les gestionnaires de tags natifs comme Google Tag Manager.
Le problème de départ
Le bloc avis/widget-tiers chargeait un script fourni par un prestataire d’avis clients directement via wp_enqueue_script(), en dépendance bloquante avant l’affichage du widget. Ce script, non minifié côté fournisseur, exécutait lui-même plusieurs appels réseau supplémentaires au chargement, retardant l’interactivité de toute la page sur les connexions mobiles.
Ce que change Cloudflare Zaraz
Zaraz exécute les scripts tiers dans un environnement isolé côté edge Cloudflare, plutôt que dans le fil principal du navigateur du visiteur. Le navigateur ne charge plus le script du prestataire lui-même : il envoie un événement léger (quelques centaines d’octets) vers Zaraz, qui se charge d’exécuter la logique tierce et de renvoyer, si besoin, le résultat au navigateur via un canal dédié.
Retirer l’enqueue classique du bloc
La première étape consiste à retirer l’appel wp_enqueue_script() qui chargeait le script du prestataire, pour ne conserver que le rendu HTML du widget côté bloc :
function avis_bloc_widget_tiers_assets() {
// Ancien appel supprimé :
// wp_enqueue_script( 'avis-widget-tiers', 'https://cdn.prestataire.com/widget.js' );
wp_enqueue_script(
'avis-widget-zaraz-trigger',
plugins_url( 'build/zaraz-trigger.js', __FILE__ ),
array(),
'1.0.0',
true
);
}
add_action( 'wp_enqueue_scripts', 'avis_bloc_widget_tiers_assets' );
Déclencher l’événement Zaraz depuis le bloc
Le script zaraz-trigger.js, très léger, se contente de déclencher un événement personnalisé une fois le widget visible dans le viewport, via l’API IntersectionObserver déjà disponible nativement dans le navigateur :
const widget = document.querySelector( '[data-bloc="avis-widget-tiers"]' );
const observateur = new IntersectionObserver( ( entrees ) => {
entrees.forEach( ( entree ) => {
if ( entree.isIntersecting ) {
zaraz.track( 'avis_widget_visible', {
articleId: widget.dataset.articleId,
} );
observateur.disconnect();
}
} );
} );
observateur.observe( widget );

Configurer l’action côté tableau de bord Zaraz
Côté tableau de bord Cloudflare Zaraz, un « Trigger » est configuré pour écouter l’événement personnalisé avis_widget_visible, et déclenche à son tour l’« Action » correspondant au script du prestataire d’avis, exécutée côté edge plutôt que dans le navigateur.
- Trigger Zaraz écoutant l’événement
avis_widget_visibleémis par le bloc. - Action Zaraz configurée avec les identifiants du prestataire d’avis, sans exposer de clé côté client.
- Mode « managed component » de Zaraz utilisé quand le prestataire figure dans le catalogue intégré, sinon action HTTP personnalisée.
Ce qui a demandé un ajustement
Le widget d’avis clients avait besoin, dans sa version d’origine, d’injecter du HTML directement dans la page une fois chargé. Ce comportement n’est pas transposable tel quel via Zaraz, qui exécute la logique côté edge sans accès direct au DOM du visiteur. La solution retenue a consisté à faire retourner par Zaraz les données brutes des avis (JSON), puis à les afficher via un petit rendu côté bloc, plutôt que de déléguer entièrement l’affichage au script tiers.
Déporter un script tiers ne consiste pas à faire disparaître son travail, mais à choisir où ce travail s’exécute — et l’edge est souvent un bien meilleur endroit que le téléphone du visiteur.
En résumé
Sur ce bloc précis, le passage à Cloudflare Zaraz a retiré 210 ko de JavaScript tiers bloquant du fil principal, au prix d’une réécriture du rendu du widget côté bloc pour ne plus dépendre de l’injection DOM du prestataire. Cette recette s’applique à tout script tiers dont le rôle se limite à envoyer et recevoir des données, moins bien à ceux qui manipulent directement l’interface du navigateur.