Bloated, ce mot répété sur Reddit : et si c’était le problème de votre site ?
Au fil de mes pérégrinations webistiques, je suis tombé récemment sur ce fil Reddit, où un développeur Front-End raconte une scène presque trop familière : des semaines de travail pour peaufiner un site, livré propre et rapide. Puis son client lui demande d’y greffer un chat pour le support, une popup d’inscription à la newsletter et un widget d’avis, le tout pour faire comme le site concurrent. Résultat : 30 points perdus sur le score de performance selon Lighthouse… Et au final, c’est le développeur qui a dû s’expliquer sur un site qui devenait soudainement lent et moins ergonomique… Pas Glop.
Ce qui m’a interloqué, c’est que le fil ait rassemblé des dizaines de témoignages similaires où les développeurs sont trop souvent confrontés à ce dilemme entre satisfaire les demandes de leurs clients et rendre leur code moins, voire beaucoup moins, propre. Certains parlent même de code « bloated », littéralement « gonflé » ou « boursouflé », pour désigner ce code alourdi par du superflu qui n’apporte plus rien ni au visiteur ni au contenu, mais pèse un peu plus à chaque nouvel ajout. D’autres évoquent « l’uglify », soit « enlaidir » ou « rendre laid » pour les moins à l’aise d’entre nous avec la langue d’outre-Manche. La frustration des développeurs qui s’expriment dans ce fil est palpable. Je m’émeus de leur envie de bien faire, tout en regrettant le manque de pédagogie.
Si cette frustration est aussi largement partagée, ce n’est pas un hasard. La plupart du temps, personne n’a jamais montré au client ce que ces ajouts coûtaient réellement, en vitesse, en expérience, en revenus. Le développeur se retrouve alors seul à porter la responsabilité d’un choix qui n’était pas vraiment le sien. C’est cette zone d’ombre que je veux éclaircir ici : si vous êtes propriétaire d’un site, voici ce qui se passe concrètement à chaque fois que vous demandez d’ajouter un outil.
Bloated ou pas ? Testez votre code
Et évaluez le rapport texte/code de vos URLs.
Chaque ajout a un coût, même quand il paraît gratuit
Un chat de support, une popup d’inscription, un widget d’avis client : chacun de ces éléments appartient à ce qu’on appelle du code tiers, ou third-party, par opposition au code first-party, celui que votre agence ou votre développeur a écrit et optimisé spécifiquement pour votre site. La différence compte : le code first-party, vous (ou votre prestataire) le maîtrisez, vous savez ce qu’il fait et combien il pèse. Le code third-party, lui, vit sur les serveurs d’un autre éditeur, évolue sans que vous en soyez informé, et embarque souvent ses propres dépendances, parfois plus lourdes que le reste de votre site réuni.
Pour fonctionner, chaque script tiers doit se charger dans le navigateur de vos visiteurs, en plus du code first-party de votre site. Ce code prend du poids, prend du temps à être téléchargé et exécuté, et ce temps s’ajoute à celui que vos visiteurs attendent déjà avant de voir votre page.
Pris isolément, un widget tiers semble anodin. Le problème, c’est que personne ne dit jamais non à un seul ajout : ce sont les additions successives de code third-party, sur des mois, qui transforment un site rapide en site lent, sans qu’aucune décision isolée ne semble responsable. C’est exactement ce qui est arrivé au développeur du fil Reddit évoqué en intro : 30 points perdus sur le score de performance en un seul lot d’ajouts tiers.
Et ce type de perte n’a rien d’anecdotique. Plusieurs commentaires du fil citent des études selon lesquelles une chute de 30 points sur le score de chargement ferait baisser le taux de conversion d’environ 10 %. L’ordre de grandeur colle avec ce que documentent d’autres études sur le sujet : WIRO rapporte notamment qu’un délai d’affichage d’une seule seconde peut réduire les conversions e-commerce jusqu’à 7 %, et que ce taux grimpe à 20 % pour un délai de 3 secondes. Sur un site qui génère 100 demandes de devis par mois, ce sont potentiellement 10 demandes qui disparaissent, pas parce que votre offre a changé, mais parce qu’un chat de support met une seconde de plus à s’afficher.
Ce n’est pas une fatalité liée à Internet en général, c’est une conséquence directe et mesurable de ce qu’on ajoute à une page, et en particulier de ce qu’on y ajoute en code tiers.
Ce que le code superflu coûte à votre visibilité sur Google
Il y a un deuxième coût, moins visible que la lenteur ressentie par vos visiteurs, qui touche directement votre référencement. Avant qu’une page apparaisse dans les résultats de recherche, Google (et les autres moteurs) envoient des robots, qu’on appelle des crawlers, pour l’explorer. Lors de cette exploration, un crawler, ce programme automatisé utilisé par les moteurs de recherche pour parcourir et indexer les pages web, doit identifier le contenu éditorial utile au milieu de tout le code HTML de la page. Plus ce code contient d’éléments superflus par rapport au contenu réel, plus on parle de code bloated, moins cette extraction est efficace, et plus le budget de crawl, c’est-à-dire le temps que le moteur de recherche consacre à explorer votre site, est gaspillé sur du code plutôt que sur votre contenu.
C’est là que la distinction posée plus haut entre code first-party et code third-party prend tout son sens : votre contenu éditorial (vos textes, vos titres, vos fiches produits) fait partie du code first-party. Les scripts tiers, eux, n’ajoutent presque jamais de contenu éditorial : ils ajoutent du code d’interface, de tracking, de configuration. Autrement dit, chaque widget accumulé fait grossir la page sans faire grossir ce qui intéresse réellement Google.
C’est un indicateur qu’on suit très concrètement chez artwaï avec MilleCheck, l’outil gratuit qu’on a développé pour auditer un site en quelques secondes. Il calcule notamment ce qu’on appelle le rapport texte/code : une valeur, en octets, qui compare le poids des informations réellement écrites et affichées sur votre page au poids total de cette page, code compris. Plus ce rapport est haut, plus votre page transporte de code qui ne sert ni votre visiteur ni votre référencement, souvent à cause de ces couches de widgets tiers accumulées au fil du temps.
Vous pouvez tester votre propre site sur millecheck.ai, sans rien installer : il suffit de coller l’adresse de votre page. Le rapport texte/code se trouve dans la vue « Analyse du contenu » de votre rapport MilleCheck.
Ce que le code superflu coûte face aux IA qui lisent votre contenu
Le budget de crawl dont on vient de parler concerne les moteurs de recherche classiques. Mais de plus en plus de visiteurs découvrent votre activité autrement : via une réponse générée par une IA comme ChatGPT, Claude ou Perplexity, qui a lu votre site pour construire sa réponse. Pour ces IA, le problème du code superflu prend une autre forme, qu’on appelle parfois le rapport signal/bruit.
Quand une IA générative lit le code bloated d’une page, seule une petite partie de ce qu’elle traite représente du contenu réellement utile. Le reste, c’est de la structure : des balises imbriquées les unes dans les autres, des attributs de mise en forme, des scripts de suivi. Chaque fragment de ce bruit coûte à traiter à l’IA autant qu’un fragment de vrai contenu, sans rien lui apporter en retour.
Ça a trois conséquences concrètes.
- D’abord un coût : plus une page contient de code superflu, plus l’IA doit « lire » de matière avant d’arriver au contenu utile.
- Ensuite un risque sur la qualité de la réponse : plus l’IA doit chercher l’information utile au milieu de structure inutile, plus le risque qu’elle se trompe ou déforme votre contenu augmente.
- Enfin un effet sur la rapidité : plus il y a de matière à traiter, plus la réponse met de temps à se construire.
Ce problème est suffisamment réel pour que Cloudflare, l’un des plus gros réseaux mondiaux de diffusion de contenu web, ait lancé un service dédié : il convertit automatiquement les pages HTML en Markdown à la volée dès qu’une IA le demande. Sur l’article où Cloudflare présente ce service, l’exemple donné est parlant : la version HTML de leur propre page de blog pèse 16 180 tokens à traiter, contre 3 150 pour sa version Markdown équivalente, une réduction de 80 %. Sur cette page-là, quatre cinquièmes du contenu envoyé à une IA ne servaient donc à rien.
Cette solution ne fait pourtant pas l’unanimité : l’en-tête utilisé pour demander la version Markdown est transmis jusqu’au serveur d’origine, ce qui pourrait permettre à un site de servir un contenu différent aux IA et aux visiteurs humains, une pratique interdite qu’on appelle le cloaking.
Côté moteurs de recherche, l’accueil a été plutôt froid, comme le rapporte Search Engine Land. John Mueller, de Google, a résumé son scepticisme ainsi (je traduis) : « les LLM se sont entraînés sur des pages web classiques, ils les ont lues et analysées depuis le début, il semble donc acquis qu’ils n’ont aucun problème à traiter du HTML. » Du côté de Microsoft, Fabrice Canel a soulevé un autre problème, celui de la charge : si les moteurs veulent vérifier que la version Markdown correspond bien à la page réelle, ils doivent de toute façon explorer les deux versions, ce qui double le travail plutôt que de l’alléger.
Je dois dire que ce constat me déprime profondément. Un code HTML propre, sémantique, sans superflu, est déjà parfaitement exploitable par une IA, sans qu’il soit besoin d’ajouter une couche de conversion entre les deux, ni de rouvrir la question du cloaking. Je ne suis même pas convaincu que ce service Cloudflare rende service à qui que ce soit sur le fond : il traite un symptôme, le poids du HTML envoyé, plutôt que la cause, des années de code accumulé sans rigueur. C’est ça, du code bloated : pas un bug, une accumulation. Et pour moi, la solution de Cloudflare est un pansement sur une jambe de bois pour un problème qu’on pourrait tout simplement éviter à la source.
Éviter les conflits dus au code bloated : la mesure avant tout
Tout commence par la mesure. Avant même de penser à refuser ou accepter un ajout, faites un état des lieux de vos URLs impactées. Il vous faut un point de référence. Je vous recommande évidemment de le faire avec MilleCheck.ai, mais tout autre outil capable de produire ce diagnostic avec les indicateurs suivants fera aussi l’affaire :
- Le score Lighthouse de chaque URL, mesuré dans un périmètre constant. J’insiste sur le mot constant : exécuter Lighthouse depuis votre PC n’est pas un périmètre constant. Les résultats varient d’un test à l’autre selon la puissance de votre machine, les autres programmes ouverts au même moment ou de votre connexion réseau. Deux mesures prises à cinq minutes d’intervalle peuvent afficher des scores différents sans qu’aucun ajout n’ait eu lieu entretemps. Préférez PageSpeed Insights, qui exécute Lighthouse depuis les serveurs de Google plutôt que depuis votre poste, même si de légères variations subsistent aussi de ce côté. MilleCheck, de son côté, exécute ce test dans un périmètre constant et isolé via WebPageTest, avant d’en extraire le score.
- Une représentation claire de la responsabilité en matière de performance entre le code tiers et votre code first-party. MilleCheck propose ces indicateurs au niveau de chaque domaine tiers, et même de chaque script individuellement, en synthétisant poids, nombre de requêtes et temps d’exécution dans un seul indicateur par élément.
- Des seuils définis pour le code superflu au sein de votre propre code first-party : rapport texte/code, nombre de mots utiles sur la page, et autres indicateurs de ce type.
Vous pouvez aussi fixer une règle simple : votre site ne doit jamais repasser sous un certain niveau de rapidité, quoi qu’on y ajoute par la suite. Ce n’est plus une question de confiance ou de négociation à chaque demande, c’est une limite posée une fois, que tout nouvel ajout doit respecter. Là encore, un outil comme MilleCheck peut vous aider avec un monitoring quotidien et un système d’alerte.
Ce diagnostic permet ainsi de comparer l’environnement de développement et l’environnement de production, pour confirmer ou non l’innocuité d’un ajout avant et après sa mise en ligne définitive. L’objectif est de tuer toute notion de ressenti sources de conflit : ces indicateurs doivent être fiables et faire consensus entre le commanditaire et le développeur.
Ensuite, avant chaque nouvel ajout, basez vous sur ces indicateurs : de combien ce nouvel outil va-t-il ralentir votre site, et existe-t-il une alternative plus légère qui rend le même service. La plupart des chats de support, popups et widgets d’avis ont des équivalents beaucoup moins lourds ; le problème vient rarement du besoin lui-même (capter des emails, afficher des avis, répondre aux visiteurs), mais du choix de l’outil le plus lourd du marché parce que c’est celui qu’on a vu ailleurs, ou de la manière dont il a été intégré.
Conclusion
Le développeur du fil Reddit qui a ouvert cet article n’avait rien fait de mal. Il avait juste livré un site propre à un moment donné, sans qu’aucune règle n’existe pour ce qui viendrait après. C’est cette absence de cadre, plus que le chat de support ou la popup en elle-même, qui a transformé un simple ajout fonctionnel en score qui dégringole de 30 points, avec toutes les conséquences que nous avons vues.
Vous n’avez pas besoin de connaître le rapport texte/code, ni le fonctionnement d’un crawler, pour reprendre la main sur ce point. Vous avez juste besoin d’un cadre de référence : mettez-vous d’accord sur quelques indicateurs de référence, et assurez-vous que ces chiffres restent vérifiables dans le temps. La mesure, les seuils, le monitoring, c’est notre travail, en tant qu’agence web ou développeur.
Encore faut-il vérifier ces indicateurs régulièrement, plutôt que de découvrir trois mois plus tard qu’un rapport a viré au rouge. Heureusement, vous connaissez déjà un outil pour ça.
Photo de Markus Spiske via Unsplash
