« Third-party code impacted your page’s load performance » : cette ligne, répétée par les audits Lighthouse successifs, pointait systématiquement vers les mêmes coupables sur un site Elementor Pro chargé de widgets marketing — pixel de conversion publicitaire, script de chat en direct, outil d’analyse comportementale. Chacun exécuté dans le navigateur du visiteur, chacun bloquant à sa façon le thread principal pendant le chargement initial de la page.
Cloudflare Zaraz propose une alternative : exécuter la logique de ces scripts tiers côté edge Cloudflare plutôt que dans le navigateur, en s’appuyant sur les événements de la page (chargement, clic, soumission de formulaire) transmis via un client léger, plutôt que de charger chaque script tiers intégralement en local.
Cartographier les scripts tiers avant migration
Avant toute configuration Zaraz, un audit du site a listé chaque script tiers présent, sa méthode d’intégration (widget HTML natif Elementor, code personnalisé injecté dans le en-tête via une extension, script chargé par un widget Pro comme le formulaire), et surtout sa dépendance éventuelle au DOM de la page après chargement.
Le point de vigilance propre à Elementor
Certains widgets Elementor Pro, en particulier ceux liés aux formulaires et au suivi de conversion, injectent des scripts qui s’attendent à trouver certains éléments du DOM déjà présents au moment de leur exécution, ou qui écoutent directement des événements du DOM Elementor comme submit_success sur le widget Pro Forms. Déporter ces scripts vers Zaraz sans adapter leur déclenchement casse silencieusement le suivi, sans erreur JavaScript visible en apparence.
Cas qui a posé problème : le pixel de conversion sur soumission de formulaire
Le pixel de conversion publicitaire était initialement déclenché par un script inséré directement dans un widget HTML Elementor, écoutant l’événement submit_success émis par Elementor Pro Forms. Une fois ce script simplement supprimé au profit d’un déclencheur Zaraz générique sur soumission de formulaire HTML classique, l’événement Elementor spécifique n’était plus émis, et le pixel ne se déclenchait plus du tout.
La solution : un événement personnalisé transmis à Zaraz
jQuery(document).on('submit_success', '.elementor-form', function () {
if (window.zaraz) {
zaraz.track('formulaire_soumis', {
formulaire_id: jQuery(this).data('form-id') || 'inconnu'
});
}
});
Ce petit script, conservé en widget HTML Elementor, se contente de relayer l’événement natif Elementor Pro Forms vers Zaraz via zaraz.track(), plutôt que de dupliquer toute la logique du pixel de conversion en JavaScript local. C’est ensuite Zaraz, configuré côté tableau de bord Cloudflare, qui déclenche l’appel réel vers la plateforme publicitaire à réception de cet événement.
Les gains mesurés après migration
| Indicateur | Avant Zaraz | Après Zaraz |
|---|---|---|
| Temps de blocage total (TBT) | 620 ms | 280 ms |
| Scripts tiers chargés dans le navigateur | 7 | 1 (client Zaraz) |
| Score Lighthouse Performance | 68 | 84 |
Ce que cette migration ne règle pas
- La migration vers un autre CDN que Cloudflare n’entre pas dans ce périmètre
- Le tag manager natif (une alternative à Zaraz, avec une logique proche mais un modèle d’exécution différent) n’est pas comparé ici
- Chaque widget marketing ajouté après cette migration doit être revérifié individuellement pour sa compatibilité avec l’exécution côté edge
Déporter un script tiers côté edge ne dispense jamais de comprendre à quel événement précis il réagissait dans le navigateur : sans cette étape, la migration déplace le problème plutôt que de le résoudre.
Documenter la correspondance pour l’équipe
Un tableau interne recense désormais, pour chaque script tiers du site, son ancien mode de chargement (widget HTML Elementor, extension d’en-tête, script Pro Forms natif), l’événement Elementor dont il dépendait éventuellement, et sa configuration Zaraz équivalente. Ce document a évité, lors de l’ajout d’un nouveau widget de sondage quelques semaines plus tard, de reproduire l’erreur initiale du pixel de conversion : l’équipe a immédiatement vérifié l’événement d’origine avant toute migration.
Pour aller plus loin
Cette migration reste un chantier progressif : chaque nouveau widget marketing intégré au site fait désormais l’objet d’une question systématique avant intégration directe en JavaScript côté navigateur, celle de sa compatibilité native avec un déclenchement via Zaraz plutôt qu’un chargement classique. La prochaine étape envisagée consiste à étendre ce principe aux scripts liés au widget de chat en direct, resté pour l’instant en chargement classique faute de temps disponible lors de la première vague de migration.
