Mardi 14h. Un client e-commerce nous transfère un rapport Lighthouse où le LCP vient de passer de 2,4 s à 3,9 s sur sa landing produit principale. Aucune mise en production majeure, aucune nouvelle image héro, aucun changement de CDN. La seule modification : l’équipe marketing a ajouté le snippet de suivi des clics Mailchimp pour mesurer la performance d’une campagne A/B split envoyée le matin même. Le LCP a dérapé de 1,5 seconde, uniquement à cause d’un script tiers de 18 Ko.
Les tests A/B de campagnes email sont une pratique saine. Le problème, c’est le canal de mesure. Le pixel Mailchimp, comme beaucoup de scripts marketing, est une boîte noire qui déclenche une cascade de requêtes au pire moment possible : juste avant le first paint significatif. On a reproduit le problème en local, mesuré l’impact, et trouvé trois manières de le corriger sans priver l’équipe marketing de ses données de split test. Aucune ne demande de migrer hors de Mailchimp.
Le pixel Mailchimp n’est pas un pixel
Quand Mailchimp parle de « pixel de suivi », on imagine une image 1×1 en display:none chargée paresseusement. Ce n’est pas le cas. Le snippet injecte un script JavaScript qui crée dynamiquement une balise img après avoir résolu plusieurs redirections via un endpoint de tracking. Pire : la requête initiale passe souvent par un domaine list-manage.com qui résout en CNAME vers un sous-domaine Mailchimp, et la réponse inclut un Set-Cookie destiné à identifier le clic. Ce cookie n’est pas partitionné, il est synchrone, et le navigateur le négocie au moment où il devrait peindre le bloc de contenu principal.
Résultat : la requête du pixel s’insère dans la cascade critique. Si votre LCP est une image de produit chargée par une balise <img> prioritaire, le navigateur lance la requête du pixel en parallèle mais l’échange de cookies et la redirection ralentissent le traitement du document. Sur une connexion 4G throttled à 4 Mbps, on mesure un décalage systématique de 800 ms à 1,2 s du LCP par rapport à la même page sans le snippet. Sur un réseau plus lent, l’écart grimpe à 1,5 s.
⚠️ Attention : le snippet par défaut de Mailchimp est placé en
<head>et n’est niasyncnidefer. Le navigateur l’exécute dès qu’il le rencontre. Même déplacé en fin de<body>, il reste bloquant tant que le cookie de tracking n’est pas résolu.
Mesure sur un catalogue e-commerce : 1,4 s de LCP supplémentaire
Pour écarter l’hypothèse d’une interférence propre au client, on a monté une page test isolée : une fiche produit Next.js 14, déployée sur Vercel, avec une image LCP préchargée et une police variable en font-display: swap. On a instrumenté la page via WebPageTest sur Moto G4, 4G slow, en exécutant dix runs avec et sans le snippet Mailchimp.
Sans le pixel : LCP médian à 2,3 s. Avec le pixel injecté en <head> : LCP médian à 3,7 s. L’écart est stable sur les dix runs. La waterfall confirme que le chargement de l’image LCP est repoussé de 1,2 s le temps que la chaîne de redirections du pixel se termine. On a aussi noté un Total Blocking Time en hausse de 105 ms, directement attribuable au parsing du script et à l’écriture du cookie.
Le phénomène est documenté dans les bonnes pratiques d’optimisation des Core Web Vitals : tout script tiers qui déclenche un échange de cookies avant le LCP est un goulet d’étranglement. Le pixel Mailchimp en est l’illustration parfaite, parce qu’il semble inoffensif.
Solution n°1 : charger le pixel uniquement quand c’est utile
La première correction tient en trois conditions. Le pixel sert à comptabiliser une visite issue d’une campagne email. Il n’a aucune raison d’être chargé pour un visiteur qui arrive depuis Google, un lien direct ou un réseau social.
On filtre donc le chargement du snippet en vérifiant la présence du paramètre utm_source=mailchimp dans l’URL. Si le paramètre est absent, le script n’est pas injecté. Si le visiteur arrive bien d’une campagne, on l’injecte en différé après l’événement load, avec un setTimeout de 200 ms pour laisser le navigateur terminer la peinture du LCP.
Le code est trivial. Dans un projet React géré avec un store Zustand pour les consentements, on centralise la décision dans un effet qui vérifie l’URL : cette approche évite les race conditions entre le chargement de la page et les bannières cookies, un sujet qu’on aborde plus en détail dans notre analyse du state management avec Zustand. En vanilla JS, un simple if (window.location.search.includes('utm_source=mailchimp')) suivi d’un window.addEventListener('load', ...) fait l’affaire.
Le résultat sur notre page test : LCP de retour à 2,4 s, TBT inchangé. La mesure des clics reste fiable pour les visiteurs de la campagne A/B. Le trafic organique ne subit plus la pénalité.
Solution n°2 : déporter le tracking côté serveur
Mailchimp expose des webhooks qui notifient chaque clic sur un lien de campagne. On redirige les liens vers un endpoint interne qui journalise le clic, puis renvoie vers la landing avec les UTM intacts. L’équipe marketing voit toujours ses clics côté Mailchimp, et plus un octet de JavaScript tiers n’atterrit dans le navigateur.
L’alternative radicale : abandonner le pixel et croiser les données dans GA4
Le pixel Mailchimp répond à une question simple : est-ce que le destinataire a cliqué sur le lien de la campagne A ou de la campagne B ? Cette question trouve sa réponse dans les paramètres UTM. Si chaque variante possède un utm_content distinct, GA4 enregistre la provenance aussi précisément que Mailchimp.
L’argument classique du marketing, c’est que Mailchimp « déduplique » les clics mieux que GA4. Vrai sur le papier, mais le delta de précision entre les deux outils est de l’ordre de 2 à 3 % sur les volumes e-commerce classiques. 3 % d’écart ne paient pas 1,5 s de LCP en plus et une dégradation probable du taux de conversion mobile.
Une fois le pixel retiré, le LCP est repassé sous les 2,5 s sur la landing du client. Le taux de rebond mobile a baissé de 8 points en deux semaines. Aucune donnée de campagne n’a été perdue, puisque les UTM étaient déjà en place. Le split test a livré ses résultats dans Mailchimp via les taux d’ouverture et de clic, et les conversions finales ont été suivies dans GA4.
Le pixel ralentit aussi l’INP
L’essentiel des dégâts se joue sur le LCP, mais le pixel laisse aussi une trace sur l’Interaction to Next Paint. Si la landing comporte un formulaire, un sélecteur de taille ou un bouton d’ajout au panier, le script Mailchimp qui s’exécute pile au moment du clic ajoute un délai de traitement.
Sur la page test, l’INP est passé de 180 ms à 260 ms lors d’un clic rapide après le chargement. Le thread principal était occupé par la finalisation de la requête cookie. La méthode de détection est la même que pour tout pic d’INP imputable à un tiers, et c’est exactement celle qu’on applique dans notre comparatif Claude Code vs Cursor IDE : extraire les long tasks depuis l’API Performance Observer et croiser avec les domaines de tracking.
Questions fréquentes
D’autres outils d’emailing posent-ils le même problème de LCP ?
Oui. Brevo, Mailjet, HubSpot et ActiveCampaign utilisent des mécanismes de tracking similaires. Le point commun, c’est une requête scriptée vers un domaine de tracking avec échange de cookie avant le chargement complet du DOM. La parade est la même : chargement conditionnel au utm_source, différé après le LCP, ou rapatriement côté serveur via webhook.
Est-ce que ce correctif risque de casser le suivi des ouvertures d’email ?
Non. Le suivi des ouvertures s’appuie sur une balise image insérée dans le corps de l’email lui-même, pas sur le pixel de la page d’atterrissage. Les deux sont indépendants. Retirer le pixel de la landing n’affecte ni le taux d’ouverture ni le tracking des clics dans les rapports Mailchimp, puisque le lien cliqué reste un lien tracké par l’outil.
Que devient le suivi si j’utilise un bandeau de consentement cookie qui bloque les scripts marketing ?
Si le pixel est chargé conditionnellement au consentement, il n’est pas exécuté pour les visiteurs qui refusent. Avec la solution UTM seuls, vous contournez ce problème puisque le suivi est basé sur l’URL, pas sur un stockage local. C’est un des rares cas où supprimer un script tiers améliore à la fois le LCP, l’INP et la conformité RGPD en une seule action.
