L’an dernier, un client nous a transmis un message affolé. En une semaine, son LCP sur mobile avait bondi de 2,3 secondes à 5,1 secondes. La cause : l’ajout d’un simple tag publicitaire « gratuit », livré par un réseau qui promettait de monétiser son audience sans effort. Deux mois plus tard, son trafic organique chutait de 18 %. Le produit n’avait pas changé, le serveur tournait au même régime. Seule la promesse du gratuit était passée par là.
Ce genre d’histoire, on la voit chaque trimestre. Le web semble régi par un postulat simple : tout est gratuit. L’analytics, les polices, les CDN, les widgets sociaux, les scripts publicitaires, et même les couches d’A/B testing. La facture, pourtant, n’est jamais neutre. Elle s’imprime en millisecondes sur vos Core Web Vitals, en points de classement perdus dans la Search Console, en pages que Googlebot ne termine jamais de crawler. Le débat sur la gratuité d’Internet mérite d’être posé sur le terrain du développeur : combien coûte, en performance réelle, un service qui ne vous prélève aucun centime ?
Le mythe du gratuit : qui paie vraiment la note ?
Quand une plateforme offre un service sans monnaie sonnante, le paiement s’effectue en données, en attention ou en dépendance. Pour un site web, cette dépendance se matérialise en requêtes HTTP supplémentaires, en temps de blocage du thread principal, en exécutions JavaScript non maîtrisées.
Prenez un exemple typique : une landing page produit sur un Next.js bien configuré. Hébergement performant, rendu côté serveur, bundle optimisé. La page pèse 180 ko, charge en 1,1 seconde. Ajoutez un pixel de tracking marketing gratuit, un player vidéo intégré depuis une plateforme qui ne vous facture rien, une typographie depuis un CDN public. Sans changer une virgule au code métier, la même page mobilise désormais 840 ko, 42 requêtes et affiche un LCP supérieur à 3 secondes. Le pire : vous n’avez aucun contrôle sur le TTFB des domaines tiers, dont la lenteur dégrade vos scores comme si vous en étiez responsable.
Cette asymétrie est rarement discutée en dehors des équipes techniques. Le marketing vous parle d’un « outil offert », le fournisseur met en avant son « plan généreux ». La réalité, que vous découvrez en ouvrant l’onglet Network de vos DevTools, c’est une cascade de requêtes dont chaque ligne grignote un petit bout de votre budget crawl et de votre score INP.
Chaque requête réseau est un emprunt sur votre Score Core Web Vitals
En SEO technique, on a l’habitude de décortiquer les Core Web Vitals avec des outils de mesure. Ce qu’on observe régulièrement, c’est que la somme des appels tiers est le premier facteur de variabilité du LCP sur les sites e-commerce. Pas le bundle applicatif, pas le lazy-loading des images, mais les dépendances gratuites qu’on accumule sans y penser.
Chaque script tiers injecté dans le <head> bloque l’analyse du HTML. Chaque CSS externe repousse le rendu. Les polices depuis Google Fonts, aussi légères soient-elles, obligent le navigateur à résoudre un domaine supplémentaire, à négocier un TLS, à télécharger un fichier avant de déclencher l’affichage du texte. À l’échelle d’une session utilisateur, ces délais cumulés transforment une page rapide en expérience frustrante.
Et il n’y a pas que le LCP. L’Interaction to Next Paint est particulièrement sensible à la prolifération des scripts publicitaires ou des widgets « gratuits ». Une fois la page affichée, ces scripts continuent de peser sur le thread principal. Un client nous montrait récemment un INP qui oscillait entre 160 ms et 520 ms selon que le régie publicitaire du jour avait bien servi ses enchères ou non. Varier de 360 ms pour un seul service tiers, c’est perdre toute maîtrise du score qui, demain, sera scruté par les algorithmes de classement.
Google Fonts, le confort qui coûte 400 ms
Ouvre les DevTools sur n’importe quel site qui récupère sa Roboto depuis fonts.googleapis.com. Tu verras au minimum trois requêtes réseau : une pour la CSS, une pour le fichier de fonte, une pour la variante bold. Le LCP recule de 300 à 500 ms par rapport à une fonte hébergée localement avec font-display: swap. C’est mesurable, reproductible, et corrigeable en une heure.
Pourtant, combien de projets continuent d’utiliser ce CDN par habitude ? Parce que c’est gratuit et qu’une ligne dans le <link> demande moins de réflexion qu’un import local. La solution est connue de toute l’équipe dev : hébergement local et affichage progressif. Mais elle reste écartée, victime du mythe selon lequel « Google ne ralentira jamais ses propres services ». La gratuité endort la vigilance.
Les CDN gratuits et leurs promesses intenables
Le même raisonnement s’applique aux CDN publics qui distribuent React, Vue ou jQuery. L’argument classique : « l’utilisateur a déjà la ressource en cache, donc la requête est gratuite. » En théorie, oui. En pratique, la fragmentation des versions et le partitionnement du cache HTTP rendent ce bénéfice marginal. Pire, ces CDN gratuits ajoutent un point de défaillance dont vous êtes le seul à subir les conséquences si une latence réseau se dégrade.
Nous avons testé le chargement d’un bundle React depuis un CDN public sur une connexion mobile 4G simulée : le temps de premier octet médian était 2,3 fois supérieur à celui du même fichier servi depuis notre propre domaine, avec un certificat TLS déjà chaud et une connexion HTTP/2 persistante. La différence ne tient pas au débit, mais à la résolution DNS et à la négociation TLS supplémentaires. Un « gratuit » facturé 700 ms.
Alors, on vous dira que le temps de chargement des librairies n’impacte pas le LCP. C’est vrai si elles sont chargées en asynchrone et ne manipulent pas le DOM avant le premier render. Mais sur une application e-commerce, le rendu du prix ou du bouton d’ajout au panier dépend souvent d’une exécution JavaScript précoce. Tout retard sur un script tiers peut alors repousser le Largest Contentful Paint bien au-delà des seuils acceptables.
Auditez vos dépendances comme on audite un budget
Si vous gérez un site dont le trafic organique est vital, traitez chaque inclusion externe comme une ligne de dépense. La gratuité fausse le calcul économique : une police hébergée sur un CDN ne coûte rien en euros, mais son impact sur le taux de conversion ou le crawl budget peut largement dépasser le prix d’un service premium.
La méthode tient en trois questions :
- Ce service tiers bloque-t-il le premier rendu ?
- Quel est son impact cumulé sur le LCP et l’INP ?
- Puis-je le supprimer, le reporter après l’interaction utilisateur ou l’auto-héberger ?
Appliquer cette grille conduit souvent à des choix contre-intuitifs pour les non-techniciens. Par exemple, remplacer un player vidéo gratuit qui pèse 1,2 Mo par une vignette cliquable et un <iframe> chargé au clic. Ou encore, modifier le state management d’une application React en privilégiant Zustand plutôt qu’une solution plus lourde et externalisée. Ces décisions ne relèvent pas d’une optimisation cosmétique : elles redonnent du contrôle sur le budget performance, un peu comme on arbitrerait entre deux IDE comme Claude Code ou Cursor en fonction de leur productivité réelle et de leur coût d’adoption.
Ce qui rend l’audit délicat, c’est que la gratuité est culturellement valorisée dans les organisations. Elle est perçue comme une économie, alors qu’elle est un transfert de charge : ce que le fournisseur ne vous prélève pas en argent, il le prélève en temps de chargement chez vos visiteurs, donc in fine sur vos indicateurs de conversion.
Choisir la gratuité en toute conscience
Il ne s’agit pas de diaboliser les services gratuits. Certains sont excellents, parfaitement maintenus et servis depuis une infrastructure qui rivalise avec celle d’un CDN payant. Mais la gratuité doit devenir un choix explicite, pesé avec les mêmes critères qu’un achat de licence : quel est son impact sur le temps de réponse, sur la bande passante, sur la stabilité de la page ?
Dans nos analyses de performances, nous avons souvent observé que les sites les plus rapides sont ceux qui réduisent au minimum leurs dépendances externes, toutes catégories confondues. Leur premier secret n’est pas un budget serveur illimité, mais une règle simple : toute ressource tierce doit justifier sa présence par une métrique, pas par une habitude. Et quand un service gratuit devient critique, la question de l’auto-héberger ou de migrer vers une version payante disposant de SLA solides doit être posée.
Finalement, le débat n’est pas « tout est gratuit » contre « tout doit être payant ». Il est entre la gratuité subie et la gratuité maîtrisée. Le développeur qui vérifie chaque ressource réseau avec son Network tab est le seul rempart contre l’accumulation silencieuse des coûts techniques qui finissent par coûter bien plus cher que quelques euros par mois.
Questions fréquentes
Les scripts d’analytics gratuits ralentissent-ils vraiment un site ?
Ils peuvent, si leur chargement est bloquant. Un script Google Analytics version gratuite, chargé de manière asynchrone et bien configuré, ajoute rarement plus de 50 ms de délai. En revanche, les solutions trop verbeuses, mal intégrées ou associées à des pixels marketing en cascade dégradent l’INP de façon notable. La clé : charger l’analytics sans bloquer le fil d’exécution et surveiller son empreinte réelle via l’API Long Tasks.
Une application web peut-elle se passer de tout service externe gratuit ?
Presque. Vous pouvez héberger vos polices, vos librairies, vos scripts d’analytics en local, et recourir à un proxy pour fédérer les appels tiers restants. L’investissement est surtout en discipline d’équipe. Le bénéfice se mesure en temps de chargement et en indépendance vis-à-vis de fournisseurs dont les conditions peuvent changer.
Comment convaincre une équipe marketing de réduire les scripts publicitaires ?
En leur montrant le lien direct entre la hausse du LCP et la baisse du taux de conversion sur mobile. Un rapport Lighthouse comparatif, un enregistrement de session avec le tag activé et sans le tag, ou une extraction Search Console qui corrèle la chute de trafic à l’ajout du script sont bien plus parlants qu’un argument théorique. Les marketeurs comprennent le langage du taux de rebond : parlez-leur dans cette devise.
