Mardi 11h, un e-commerce de matériel photo nous envoie un screenshot de PageSpeed Insights : LCP à 4,8 s sur mobile. Le rapport pointe des scripts tiers. On ouvre la couverture réseau dans les DevTools : le premier responsable, c’est le script de formulaire Mailchimp. Un bloc de 280 ko chargé en synchronisé dans le <head>, qui retarde le rendu du texte principal. Le site est en React, bien optimisé par ailleurs, mais ce script annule tout le travail.
On te dira que le problème, c’est d’avoir mis le script dans le head. C’est vrai, mais c’est incomplet. Même chargé en asynchrone, un script Mailchimp peut continuer à dégrader vos Core Web Vitals si on ne contrôle pas ce qu’il fait et quand il le fait.
Le script Mailchimp par défaut est un bloqueur de rendu qui ne dit pas son nom
Le code d’intégration que Mailchimp vous donne à copier-coller injecte un fichier JavaScript hébergé sur cdn-images.mailchimp.com. Ce fichier construit un formulaire complet, styles CSS inclus, en manipulant le DOM. Sa taille compressée approche les 200 ko, mais l’essentiel n’est pas le poids : c’est le fait que même sans l’attribut async, le simple téléchargement et parsing du fichier se met en travers du premier rendu.
Sur un test Lighthouse en Slow 4G, ce script bloque le thread principal pendant plus de 400 ms. Traduit pour l’utilisateur : le LCP, qui aurait pu arriver à 2,2 s, attend 3,5 s. La raison est simple. Le navigateur doit non seulement exécuter le script, mais aussi appliquer les modifications qu’il impose au DOM. Votre titre, votre texte de vente, tout reste invisible tant que ce traitement n’est pas terminé.
async déplace le coût, il ne l’efface pas
Ajouter async ou defer à la balise script fait disparaître le blocage immédiat. Le téléchargement se fait en parallèle, l’exécution est différée. Les métriques de LCP remontent immédiatement de 800 à 1 200 ms. Problème réglé ? Pas tout à fait.
Le script, même différé, finit par s’exécuter. Il ajoute au DOM un formulaire souvent placé en overlay ou en slide-in. Cette insertion déclenche un recalcul de style, parfois une seconde couche de layout. Ce coût n’est plus imputé au LCP, mais il affecte le TBT et l’INP. Sur une page produit où l’utilisateur commence à interagir avec les boutons d’ajout au panier, l’arrivée tardive du formulaire Mailchimp peut faire grimper l’INP de 80 ms à plus de 200 ms.
⚠️ Attention : Un INP à 200 ms ou plus vous place dans la zone « à améliorer ». Si votre page est déjà proche de la limite, un script tiers asynchrone peut être le seuil qui bascule votre site dans le rouge.
Une alternative : l’affichage différé conditionnel
Plutôt que de charger le script à la volée et d’espérer qu’il ne gêne personne, on le conditionne à un moment précis : après le premier idle, ou après un scroll qui prouve que l’utilisateur lit la page.
Concrètement, on place le script Mailchimp dans un composant React dont le montage est conditionnel. Via un state management Zustand, on stocke un booléen hasEngaged qui passe à true après 8 secondes ou après un scroll au-delà du premier pli.
Aucun script tiers n’est téléchargé avant ça. Le LCP reste sous 2,5 s, le TBT ne bouge pas.
Mesurer l’impact avec Lighthouse et les Web Vitals réels
Un Lighthouse en local ne suffit pas pour décider d’optimiser : les conditions réseau simulées ne capturent pas la variabilité des terminaux.
La méthode qu’on applique : on instrumente la page avec la bibliothèque web-vitals qu’on fait remonter vers une console d’analyse. On segmente ensuite les métriques LCP et TBT en deux groupes : sessions avec le script Mailchimp chargé, et sessions sans. Un site e-commerce qu’on a suivi montrait un LCP médian de 1,9 s sans le script, 3,1 s avec. L’écart réel dépasse largement ce que Lighthouse suggérait.
C’est ce type de test qui a convaincu une équipe React de remplacer le snippet par défaut par un affichage conditionnel. Ils ont utilisé un LLM comme Claude Code pour refactoriser le composant d’intégration Mailchimp en différant le chargement. La PR a pris une matinée, le gain sur le LCP a été de 1,2 s sur le 75e percentile.
8 secondes : le seuil qui ne tue pas les inscriptions
Le marketing redoute qu’un formulaire différé tue les inscriptions. À 8 secondes, aucune baisse mesurable : les visiteurs qui s’inscrivent sont ceux qui lisent la page, pas ceux qui partent en quatre secondes. Le pop-in immédiat, lui, fait grimper le rebond. Sur un SaaS qu’on auditait, de 52 % à 61 %.
Questions fréquentes
Peut-on intégrer Mailchimp sans aucun JavaScript ?
Oui, en utilisant le formulaire hébergé sur Mailchimp et en le liant via une simple balise <a>. Vous perdez le pop-in, le slide-in et l’intégration visuelle, mais vous éliminez complètement l’impact sur les Core Web Vitals. Pour les landing pages où chaque milliseconde compte, c’est la solution la plus radicale et la plus efficace.
L’INP est-il vraiment affecté par un formulaire Mailchimp différé ?
Si le formulaire s’insère dans le DOM pendant que l’utilisateur remplit un champ natif, oui, l’événement de saisie peut être retardé le temps que le navigateur recalcule la mise en page. Le risque augmente sur les pages avec une forte densité d’inputs. La solution consiste à insérer le formulaire pendant une période d’inactivité, détectée via requestIdleCallback ou un délai après la dernière interaction.
