Un récent podcast de Google a attiré l’attention sur le fait que les sites Web sont de plus en plus grands que jamais. Gary Illyes et Martin Splitt de Google ont expliqué que l’idée selon laquelle les sites Web deviennent « plus grands » est une mauvaise chose n’est pas nécessairement vraie. Ce qu’il faut retenir pour les éditeurs et les référenceurs, c’est que le poids de la page n’est pas une mesure fiable, car la cause de l’« excès » de poids pourrait très bien être quelque chose d’utile.
La taille de la page dépend de ce qui est mesuré
Martin Splitt de Google a expliqué que ce que beaucoup de gens considèrent comme la taille d’une page dépend de ce qui est mesuré.
- Est-ce mesuré uniquement par le HTML ?
- Ou parlez-vous de la taille totale de la page, y compris les images, CSS et JavaScript ?
C’est une distinction importante. Par exemple, de nombreux référenceurs ont paniqué lorsqu’ils ont appris que Googlebot limitait l’exploration de leurs pages à seulement 2 mégaoctets de HTML par page. Pour mettre cela en perspective, deux mégaoctets de HTML équivalent à environ deux millions de caractères (lettres, chiffres et symboles). C’est l’équivalent d’une page HTML avec le même nombre de lettres que deux livres Harry Potter.
Mais lorsque vous incluez CSS, images et JavaScript avec le HTML, nous avons maintenant une conversation différente liée à la vitesse des pages pour les utilisateurs, et non pour le robot d’exploration de Googlebot.
Martin a discuté d’un article sur le Web Almanac de HTTPArchive, qui est un résumé des tendances des sites Web. L’article semblait mélanger différents types de poids de page, ce qui rend le tout confus car il existe au moins deux versions de poids de page.
Il a noté :
« Vous voyez, c’est là que je ne suis pas si clair sur leur définition du poids de la page.
… ils ont un paragraphe dans lequel ils essaient d’expliquer ce qu’ils entendent par poids de page. …Je ne comprends pas les différences entre ces choses. On dit donc que le poids de la page (également appelé taille de la page) est le volume total de données mesuré en kilo-octets ou en mégaoctets qu’un utilisateur doit télécharger pour afficher une page spécifique. Dans mon livre, cela comprend des images et ainsi de suite parce que je dois télécharger ça pour voir.
Et c’est pourquoi j’ai été surpris d’apprendre qu’en 2015, cela représentait 845 kilo-octets. Cela m’a surpris. …Parce que j’aurais supposé qu’avec des images, cela ferait plus de 800 kilo-octets.
… En juillet 2025, la même page médiane fait désormais 2,3 mégaoctets.
Les données sont compressées
Mais ce n’est qu’une façon de comprendre la taille d’une page. Une autre façon de considérer la taille des pages consiste à se concentrer sur ce qui est transféré sur le réseau, qui peut être plus petit en raison de la compression. La compression est un algorithme côté serveur qui minimise la taille du fichier envoyé depuis le serveur et téléchargé par le navigateur. La plupart des serveurs utilisent un algorithme de compression appelé Brotli.
Martin Splitt explique :
« Je pose cette question publiquement, car différentes personnes avaient des notions très différentes sur la façon dont elles comprenaient la taille de la page. Selon la couche que vous regardez, cela devient également déroutant.
car il y a aussi la compression.… Alors certaines personnes disent, ah, mais ce site Web télécharge 10 mégaoctets sur mon disque.
Et je dis oui. … mais peut-être que si vous regardez ce qui se passe réellement sur le réseau, vous constaterez peut-être qu’il s’agit de cinq ou six mégaoctets, et non de la totalité de 10 mégaoctets. Parce que vous pouvez compresser des éléments au niveau du réseau, puis les décompresser au niveau du client… »
Techniquement, la taille de la page dans l’exemple de Martin est en réalité de cinq ou six mégaoctets en raison de la compression, et le téléchargement est plus rapide. Mais du côté de l’utilisateur, ces cinq ou six mégaoctets sont décompressés et se transforment à nouveau en dix mégaoctets, ce qui occupe autant d’espace sur le téléphone, le bureau ou ailleurs de l’utilisateur.
Et cela introduit une ambiguïté. Votre page Web fait-elle dix ou cinq mégaoctets ?
Cela illustre un problème plus vaste : différentes personnes parlent de choses différentes lorsqu’elles parlent de la taille d’une page.
Même les définitions largement utilisées ne résolvent pas complètement l’ambiguïté. Le poids de la page est décrit comme « le volume total de données mesuré en kilo-octets ou en mégaoctets qu’un utilisateur doit télécharger », mais comme le montre clairement la discussion, il n’existe pas de définition claire.
Martin affirme :
« Lorsque vous demandez aux gens ce qu’ils pensent, si c’est important ou non, vous commencez à obtenir des réponses très différentes selon ce qu’ils pensent de la taille de la page. Et il n’y a pas de véritable définition unique. »
Qu’en est-il du rapport entre le balisage et le contenu ?
L’une des distinctions les plus intéressantes faites dans le podcast est qu’une grande page n’est pas nécessairement inefficace. Par exemple, un document HTML de 15 Mo est considéré comme acceptable car « la quasi-totalité de ces 15 Mo sont en réalité du contenu utile ». La taille reflète la valeur livrée.
En revanche, que se passerait-il si le rapport entre le contenu et le balisage était inversé, où il y avait un peu de contenu mais la majeure partie du poids de la page était le balisage.
Martin a discuté de l’exemple de ratio :
« … et si le balisage était la seule surcharge ? Et je veux dire, qu’est-ce que tu veux dire ? C’est comme, eh bien, tu sais, si c’est comme cinq mégaoctets mais que ce n’est que très peu de contenu, est-ce mauvais ? Est-ce pire que dans ce cas, les 15 mégaoctets.
Et je me dis que c’est délicat parce qu’alors nous entrons dans ce territoire étrange du rapport entre contenu et balisage. Ouais.
Et j’ai dit, eh bien, mais que se passe-t-il si une grande partie est du balisage qui est des métadonnées pour un outil tiers ou pour un service ou pour des raisons réglementaires ou des raisons de licence ou autre. Ensuite, c’est un contenu utile, mais pas nécessairement pour l’utilisateur final, mais vous devez quand même l’avoir.
Ce serait bizarre de dire que c’est pire que la page où le poids est majoritairement contenu.
Ce que Martin fait ici, c’est déplacer l’idée du poids de la page de la taille brute vers ce que les données représentent réellement.
Pourquoi les pages incluent des données que les utilisateurs ne voient jamais
Un contributeur majeur au poids des pages est le contenu que les utilisateurs ne voient jamais.
Gary Illyes cite les données structurées comme exemple de contenu spécifiquement destiné aux machines et non aux utilisateurs. Bien que cela puisse être utile pour les moteurs de recherche, cela augmente également la taille globale de la page. Si un éditeur ajoute beaucoup de données structurées à sa page afin de profiter de toutes les différentes options disponibles, cela augmentera la taille de la page même si l’utilisateur ne la verra jamais.
Cela attire l’attention sur une réalité structurelle du Web : les pages ne sont pas uniquement conçues pour les lecteurs humains. Ils sont également conçus pour les moteurs de recherche, les outils, les agents d’IA et d’autres systèmes, qui ajoutent tous leurs propres exigences au poids d’une page Web.
Quand les frais généraux sont justifiés
Tous les contenus non destinés aux utilisateurs ne sont pas inutiles.
Martin a expliqué comment le balisage peut inclure des « métadonnées » ou un objectif d’outil, de réglementation ou de licence, créant ainsi une sorte de zone grise. Même si les données supplémentaires n’améliorent pas directement l’expérience utilisateur, elles servent un objectif, notamment celui d’aider l’utilisateur à trouver la page via un moteur de recherche.
Le point auquel Martin voulait en venir est que ces considérations sur le poids de la page compliquent les tentatives de qualifier le poids de la page de bon s’il est inférieur à ce seuil ou de mauvais si le poids de la page le dépasse.
Pourquoi séparer le contenu et les métadonnées ne fonctionne pas
Une solution possible évoquée par Gary Illyes consiste à séparer le contenu destiné aux humains des données destinées aux machines. Bien que Gary n’ait pas spécifiquement mentionné la proposition LLMs.txt, ce dont il a parlé y ressemble en ce sens qu’il sert du contenu à une machine moins tous les autres frais généraux associés au contenu destiné à l’utilisateur.
Ce dont il a en fait discuté était un moyen de séparer toutes les données accessibles à la machine de ce que l’utilisateur téléchargera, réduisant ainsi, en théorie, la version utilisateur d’une page Web.
Gary rejette rapidement cette idée comme étant « utopique », car il y aura toujours des hordes de spammeurs qui trouveront un moyen d’en profiter.
Il a expliqué :
« Mais malheureusement, c’est une chose utopique. Parce que tout le monde sur Internet ne joue pas gentiment.
Nous savons à quelle quantité de spam nous devons faire face. Sur notre blog, nous disons quelque part que nous captons environ 40 milliards d’URL par jour qui sont du spam ou un nombre insensé, je ne me souviens pas exactement, mais c’est un nombre insensé et certainement des milliards. Cela ne fera qu’exacerber la quantité de spam que les moteurs de recherche et d’autres machines reçoivent, peut-être comme je parierais 1 $ et 5 cents, ce qui augmentera en fait la quantité de spam que les moteurs de recherche, les LLM et autres ingèrent.
Gary a également déclaré que l’expérience de Google est que, historiquement, lorsque vous avez des types de contenu distincts, il y aura toujours des différences entre les deux types. Il a utilisé l’exemple de l’époque où les sites Web avaient des pages mobiles et des pages de bureau, où les deux versions du contenu étaient généralement différentes, ce qui à son tour causait des problèmes de recherche et également d’utilisabilité lorsqu’un site classe une page Web pour son contenu sur une version d’une page, puis renvoie l’utilisateur vers une version différente de la page où ce contenu n’existe pas.
Bien qu’il ne l’ait pas mentionné explicitement, cette explication de l’expérience de Google pourrait éclairer davantage sur les raisons pour lesquelles Google n’adoptera pas LLMS.txt.
En conséquence, les moteurs de recherche ont largement opté pour un modèle de document unique, même s’il s’avère inefficace.
La taille du site Web par rapport à la taille de la page est le monde réel
La discussion remet en fin de compte le concept initial du problème, selon lequel les pages Web lourdes sont mauvaises.
Gary observe :
« La première question est : les sites Web grossissent-ils ? Je pense que cette question n’a même pas de sens.
Parce que peu importe dans le contexte d’un site Web s’il est gros. Dans le contexte d’une seule page, oui.
Mais dans le contexte d’un site Web, cela n’a pas vraiment d’importance.
Alors maintenant, Gary et Martin se concentrent désormais sur les pages Web qui deviennent de plus en plus lourdes, une manière plus significative d’aborder la question de l’évolution des pages Web et des sites Web.
Cela fait passer la discussion d’une idée abstraite à quelque chose de plus mesurable et exploitable.
Les pages plus lourdes entraînent toujours des coûts réels
Même avec des connexions plus rapides et une meilleure infrastructure, les pages plus grandes ont toujours des conséquences, et les pages plus petites présentent des avantages positifs.
Martin explique :
« Je pense que nous gaspillons beaucoup de ressources. Et je veux dire, nous avons eu cela dans un autre épisode où nous avons dit que nous savons qu’il existe des études qui montrent que les sites Web plus rapides ont une meilleure rétention et de meilleurs taux de conversion. Oui. Et la vitesse est en partie également basée sur la taille. Parce que plus j’envoie de données, plus il faut de temps au réseau pour transférer ces données et plus il faut de temps au processeur de l’appareil que vous utilisez pour les traiter et vous les afficher. «
D’un point de vue plus large, le problème n’est pas seulement la performance mais aussi l’efficacité. Comme le dit Illyes, « nous gaspillons beaucoup de ressources ».
Le Web devient peut-être de plus en plus lourd, mais le point le plus important à retenir est de savoir pourquoi. Les pages contiennent bien plus que du contenu destiné aux utilisateurs, et ce choix de conception détermine à la fois leur taille et leur impact.
