La page web médiane pèse aujourd’hui entre 2,4 et 2,6 Mo sur mobile. En 2015, c’était 845 Ko (HTTP Archive). Triplement en dix ans. Et pourtant, Gary Illyes de Google affirme que « la taille d’un site web n’a pas d’importance. Pour une page individuelle, oui. » Martin Splitt ajoute que « page weight » n’a pas de définition unique. Pour un site e-commerce, cette distinction entre poids brut et poids utile change la façon d’aborder chaque décision d’optimisation technique.
Trois façons de mesurer le « poids » d’une page
Quand un e-commerçant me dit « ma page est trop lourde », je lui demande toujours : lourde comment ?
Le HTML seul, c’est le document que Googlebot reçoit en premier. Splitt rappelle qu’une page peut atteindre 2 Mo de HTML pur, l’équivalent de deux romans. Mais au-delà de cette limite, Googlebot tronque. Il arrête de lire (SEJ, Stan Ventures). En pratique, même les fiches produit les plus fournies dépassent rarement 200 Ko de HTML. Le risque de troncature concerne surtout les pages catalogue avec des centaines de produits inlinés ou du JavaScript qui gonfle le DOM.
Le poids total additionne HTML, CSS, JavaScript, images, polices. C’est le chiffre que PageSpeed Insights affiche et qui fait paniquer les e-commerçants. Selon HTTP Archive, le JavaScript médian représente 664 Ko par page mobile. Au percentile 90, le JS seul dépasse 2 Mo. Les images sont le principal contributeur au poids total, environ 60 % du poids au P90 (HTTP Archive, SpeedCurve). Mais ce chiffre brut ne distingue pas ce qui sert le visiteur de ce qui ne sert personne.
Le poids transféré est celui qui compte pour l’expérience réelle. Grâce à la compression Brotli ou gzip, une page de 10 Mo côté serveur peut ne transférer que 5-6 Mo sur le réseau. Le navigateur décompresse côté client. C’est la distinction que je fais systématiquement en audit : un client me montre son rapport Lighthouse avec 4,5 Mo de « page weight », je lui montre l’onglet Network avec 1,1 Mo transférés. La panique retombe et on peut parler de ce qui compte vraiment.
Et quand le temps de chargement reste élevé malgré un poids transféré raisonnable, c’est souvent la pile serveur qui est en cause, pas la page elle-même. Un TTFB de 2,5 secondes sur un hébergement mutualisé n’a rien à voir avec le poids de la page.
La taille brute n’est pas un facteur de classement
Quelque chose que je constate régulièrement en audit : des e-commerçants qui se focalisent sur le poids de la page comme si Google le mesurait directement. Ce n’est pas le cas.
Gary Illyes l’a dit clairement : la taille brute d’une page n’est pas un facteur de classement direct. Ce qui compte, c’est l’impact sur les Core Web Vitals. Une page de 15 Mo peut très bien se classer si son LCP est rapide et son CLS stable. Une page de 3 Mo peut sous-performer si un script tiers bloque le rendu pendant quatre secondes.
Google traite les CWV comme un signal « tiebreaker » (web.dev, DebugBear). Pas un facteur primaire. Entre deux pages à contenu équivalent, celle avec les meilleurs CWV gagne un avantage marginal. Mais un contenu pertinent avec un LCP médiocre battra toujours un contenu creux avec un LCP parfait. C’est documenté dans les guidelines officielles de Google.
En pratique, trois métriques comptent : le LCP (vitesse d’affichage du contenu principal), le CLS (stabilité visuelle) et l’INP (réactivité aux clics). Un LCP lent à cause d’images produit non compressées, ça impacte le SEO et les conversions. Un LCP lent à cause de données structurées complètes dans le HTML, ça n’impacte rien, parce que le schema est parsé avant le rendu visuel.
Le vrai problème de la taille, c’est Googlebot. Au-delà de 2 Mo de HTML, il tronque. Pour les pages catalogue, ça peut signifier que les produits en bas de page ne sont jamais indexés. C’est une problématique directe de gestion des URLs et d’indexation en e-commerce, pas de « poids de page » au sens large. Google intercepte environ 40 milliards d’URLs spam par jour (Gary Illyes), et le crawl budget alloué à votre site dépend entre autres de la facilité à parser vos pages. Des pages HTML propres et compactes se crawlent mieux.
L’impact réel : conversions, pas classement
Le lien entre vitesse et classement SEO est indirect. Mais le lien entre vitesse et conversions est brutal et direct.
Deloitte et Google ont mesuré que chaque seconde de délai supplémentaire coûte environ 7 % de conversions. L’étude Akamai, relayée par SpeedCurve, va plus loin : 2 secondes de délai ajoutent 103 % de bounce rate. Plus de la moitié des visiteurs partent avant d’avoir vu la page.
Les chiffres par secteur sont encore plus parlants. Rakuten a mesuré +61 % de conversions après avoir amélioré son LCP (web.dev). Dans le luxe, Deloitte a documenté +40,1 % de progression produit-vers-panier pour 0,1 seconde gagnée. Vodafone a constaté +8 % de ventes pour 0,1 seconde de LCP en moins.
Quand je fais un audit e-commerce, c’est ce type de données que je montre au client. Pas le score PageSpeed. Le score, c’est un indicateur de direction. Les conversions, c’est du chiffre d’affaires. J’ai vu des boutiques avec un score de 35 qui convertissent mieux que des concurrents à 90, parce que leur contenu est bon et leur parcours d’achat fluide. Et j’ai vu l’inverse.
Le point que beaucoup d’e-commerçants ratent : 0,1 seconde de mieux ne se sent pas humainement. Mais sur 50 000 visiteurs par mois, 8 à 10 % de conversions en plus (données Vodafone, Rakuten, Deloitte), ça se voit sur le compte en banque. L’optimisation de vitesse a un ROI mesurable. Le budget se justifie en chiffre d’affaires, pas en « ça va plus vite ».
Le ratio contenu utile vs markup mort
Plutôt que de viser un chiffre de poids absolu, la bonne grille d’analyse distingue ce qui sert le business de ce qui prend de la place pour rien.
Le contenu utile sur une fiche produit, ce sont les données structurées Schema.org (Product, Offer, AggregateRating) qui alimentent les rich snippets et le taux de clic. Les descriptions, spécifications, guides de tailles, avis clients en font partie. Les images produit aussi, en WebP ou AVIF, même si elles représentent souvent 60 % du poids total. Elles restent le premier facteur de conversion sur une fiche. Retirer ces images pour « alléger la page » est une erreur que je vois trop souvent.
Un client dans l’ameublement avait supprimé ses avis clients pour gagner 15 points de PageSpeed. Le score a monté. Le taux de conversion a chuté de 12 %. Les avis étaient du contenu utile, pour le visiteur qui hésite et pour Google qui indexe du contenu frais et unique.
Le markup mort, c’est autre chose. Sur les boutiques Shopify que j’audite, je trouve en moyenne 4-5 apps installées dont les scripts se chargent encore alors que l’app n’est plus utilisée. Chaque app orpheline ajoute du poids et du temps de chargement sans bénéfice. Le CSS de thèmes qui stylise des composants absents de la page, les widgets de chat abandonnés, les scripts analytics dont personne ne lit les données. C’est là que se trouve le gain le plus rapide. Un nettoyage de scripts inutiles fait gagner 300-800 Ko par page et 1-3 secondes de chargement sans toucher au contenu. C’est le type d’optimisation qui se mesure directement en amélioration PageSpeed et en maillage interne plus efficace.
Pourquoi Google refuse de séparer contenu humain et contenu machine
Illyes a abordé la proposition de créer des versions séparées pour les humains et les machines, dans l’esprit du fichier llms.txt. Sa réponse est nette : ça ne marchera pas. Google a déjà vécu l’époque des sites mobile/desktop séparés, et les problèmes de cohérence étaient permanents.
Deux versions signifient deux contenus à maintenir, des écarts qui se creusent, et des spammeurs qui exploitent la version machine pour afficher un contenu différent de ce que voit le visiteur. C’est du cloaking, et Google le détecte. Avec 40 milliards d’URLs spam interceptées chaque jour (chiffre Illyes), Google a les moyens de repérer les incohérences entre ce que voit le bot et ce que voit l’humain.
Pour un site e-commerce, la conséquence pratique est simple : vos données structurées, votre contenu de fiche, vos images, tout doit être dans le même document HTML. Pas de raccourcis. Si vous voulez servir du contenu aux LLMs, utilisez le même HTML que celui que vos visiteurs voient. Google préfère ça, et vos données structurées servent déjà de « version machine » exploitable.
Le bon diagnostic pour votre boutique
Avant de toucher à quoi que ce soit, voici ce que je regarde en premier sur les sites e-commerce où le SEO est un canal d’acquisition sérieux.
Ouvrez Chrome DevTools, onglet Network. La colonne « Size » montre le poids transféré. La colonne « Resource Size » montre le poids décompressé. C’est la première qui reflète l’expérience réelle du visiteur. Si votre hébergeur utilise Brotli (c’est le cas sur Shopify par défaut), votre page de 3 Mo se transfère probablement en 800 Ko - 1,2 Mo.
Les scripts tiers viennent après. Dans l’onglet Network, filtrez par « JS ». Combien de domaines externes chargent du JavaScript ? Chaque domaine externe, c’est une connexion DNS, un handshake TLS, un transfert. Si vous voyez des scripts de services que vous n’utilisez plus, supprimez-les. Le JavaScript médian par page est déjà à 664 Ko (HTTP Archive). Chaque script inutile aggrave le problème.
Regardez aussi vos images. Sont-elles en WebP ou AVIF ? Sont-elles dimensionnées pour l’écran réel ou servies en 4000 px pour un affichage de 400 px ? Le lazy loading est-il actif sur les images sous le fold ? Les images restent le levier le plus direct : elles pèsent environ 60 % du total au P90, et les compresser ou les servir au bon format ne retire rien à l’expérience utilisateur.
La question n’est jamais « ma page est-elle trop lourde ? » mais « qu’est-ce qui la rend lourde, et est-ce que ça sert le business ? » Si la réponse est non, supprimez. Si la réponse est oui, optimisez le format et le chargement, mais gardez le contenu. Si un kilo-octet ne sert ni la conversion ni l’indexation, il n’a rien à faire là.
Les pages qui me préoccupent le plus en audit ne sont pas les plus lourdes. Ce sont celles qui sont lourdes pour rien. 3 Mo de JavaScript tiers sur une fiche produit qui convertit bien, c’est un problème qui a une solution directe. 800 Ko de HTML bien structuré avec des données produit complètes, c’est exactement ce que Google veut voir.
Vous voulez savoir si vos pages portent du poids mort ? Le pré-audit est gratuit : audit.vanguard-edge-consulting.com.
L'analyse en deux voix
Deux consultants discutent de ce sujet — données, cas terrain, implications business.
Lire la version texte
Voix 1 : Salut Marc. Encore une fois ce matin, j'ai eu un client au téléphone en panique totale. Il est persuadé que sa page d'accueil est trop lourde et que Google va plomber son référencement à cause de ça.
Voix 2 : Salut Ju. C'est le grand classique des peurs en audit technique! Heureusement, on va pouvoir remettre les choses au clair Il a été écrit sur le terrain, un consultant spécialisé en SEO e-commerce, et il montre concrètement que cette obsession de la taille brute n'est souvent pas justifiée.
Voix 1 : C'est vrai que le web s'est alourdi. Mais quand on parle de "taille" aujourd'hui, de quoi parle-t-on exactement en termes de chiffres?
Voix 2 : Dans la pratique, qui cite les données de HTTP Archive, la page web mobile médiane pèse aujourd'hui entre 2,4 et 2,6 Mo, alors qu'elle n'était qu'à 845 Ko en 2015. C'est un triplement en l'espace de dix ans. Pourtant, Gary Illyes de Google affirme que la taille globale d'un site web n'a pas d'importance. Et Martin Splitt ajoute que l'expression "poids d'une page" n'a même pas de définition unique. Sur le terrain, il y a en fait trois façons très différentes de mesurer ce poids.
Voix 1 : Vas-y, je prends des notes. Quelles sont ces trois façons?
Voix 2 : La première, c'est le poids du HTML seul. C'est le document brut que Googlebot reçoit en premier. Une page peut atteindre 2 Mo de HTML pur, ce qui équivaut à deux romans. Mais attention, à souligner une chose cruciale: au-delà de cette limite de 2 Mo, Googlebot arrête tout simplement de lire et tronque la page.
Voix 1 : Attends, il coupe carrément la page? Donc si j'ai un e-commerce avec un catalogue infini et des centaines de produits, la fin de la liste risque de ne jamais être indexée?
Voix 2 : Exactement. Le risque de troncature touche surtout ces fameuses pages catalogue avec beaucoup de produits intégrés dans le code, ou du JavaScript qui gonfle le DOM. Sur une fiche produit classique, on dépasse rarement les 200 Ko de HTML. C'est un vrai enjeu pour les robots de Google, qui interceptent environ 40 milliards d'URLs de spam par jour. Des pages HTML compactes préservent votre budget de crawl car elles se lisent beaucoup plus facilement.
Voix 1 : D'accord, je comprends pour le HTML. Mais le gros chiffre rouge que mon client voit sur PageSpeed Insights, c'est quoi alors?
Voix 2 : C'est la deuxième mesure abordée dans la pratique: le poids total. Il additionne le HTML, le CSS, le JavaScript, les polices et les images. C'est vraiment le chiffre qui fait paniquer les e-commerçants. Pour te donner une idée, le JavaScript médian représente 664 Ko par page mobile, et peut dépasser les 2 Mo au 90ème percentile. Quant aux images, elles constituent à elles seules environ 60 % de ce poids total. Mais comme l'explique le consultant, ce chiffre brut a un gros défaut: il ne fait aucune différence entre ce qui sert au visiteur et ce qui ne sert à rien.
Voix 1 : D'accord, donc ce chiffre brut mélange l'essentiel et le superflu. Du coup, quelle est cette fameuse troisième façon de mesurer le poids?
Voix 2 : C'est le poids transféré, et sur le terrain, c'est celui qui compte vraiment pour l'expérience réelle. Grâce à la compression côté serveur comme Brotli ou gzip, une page de 10 Mo peut n'en transférer que 5 ou 6 sur le réseau. On a l'exemple d'un audit où un client panique devant un rapport Lighthouse de 4,5 Mo: le consultant lui ouvre l'onglet Network et lui montre que seulement 1,1 Mo a été réellement transféré. La panique retombe direct!
Voix 1 : C'est sûr que ça doit rassurer. Mais au niveau de Google, est-ce que cette taille brute est utilisée comme un facteur de classement direct pour le SEO?
Voix 2 : Pas du tout. On cite Gary Illyes de Google qui est très clair là-dessus: la taille brute d'une page n'est pas un facteur de classement direct. Ce qui compte pour Google, c'est l'impact sur les Core Web Vitals. Une page de 15 Mo peut très bien se classer si sa vitesse d'affichage, le LCP, est rapide et sa stabilité visuelle bonne. À l'inverse, une page de 3 Mo va sous-performer si un script externe bloque le rendu pendant quatre secondes. Google utilise d'ailleurs ces signaux web essentiels comme un simple "tiebreaker", ou critère de départage.
Voix 1 : Attends, un simple critère de départage? On dit donc qu'un bon contenu, même un peu lourd, peut quand même bien se positionner. Mais alors, pourquoi un e-commerçant devrait-il s'acharner à payer pour optimiser la vitesse de son site si la sanction SEO n'est pas si directe que ça?
Voix 2 : C'est là que l'analyse de consultants terrain devient percutant. Le lien avec le SEO est indirect, mais le lien avec les conversions est brutal et direct. On cite des chiffres de Deloitte et Google: chaque seconde de délai supplémentaire coûte environ 7 % de conversions. Pire encore, une étude d'Akamai montre que deux secondes de délai ajoutent 103 % de taux de rebond. Plus de la moitié des visiteurs partent avant d'avoir vu la page.
Voix 1 : 103 % de taux de rebond pour deux secondes? Ça veut dire que la moitié des gens s'en vont avant même de voir le produit... Est-ce qu'il donne des exemples terrains de boutiques qui ont corrigé le tir?
Voix 2 : Oui, les cas cités sont impressionnants. Rakuten a mesuré 61 % de conversions en plus après avoir amélioré sa vitesse d'affichage, ou LCP. Dans le secteur du luxe, Deloitte a documenté une progression de 40,1 % de la mise au panier pour un gain de seulement 0,1 seconde. Et Vodafone a constaté 8 % de ventes en plus pour ce même gain d'un dixième de seconde.
Voix 1 : Attends, 0,1 seconde? L'œil humain ne s'en rend même pas compte! Au final, l'optimisation technique, c'est un pur investissement de rentabilité, on ne fait pas ça pour décrocher un 100 sur 100 aux tests de Google.
Voix 2 : C'est exactement le point que beaucoup ratent. Dans la pratique, un dixième de seconde ne se sent pas humainement, mais sur 50 000 visiteurs par mois, de telles hausses se voient directement sur le compte en banque. Ce qui se passe concrètement que lors de ses audits, il montre ce type de données liées au chiffre d'affaires, et non les scores PageSpeed. Il a même vu des boutiques avec un score de 35 convertir mieux que des concurrents à 90, parce que leur contenu est bon et leur parcours d'achat fluide. L'optimisation a un ROI mesurable, le budget se justifie en chiffre d'affaires, et non par le simple fait que le site aille plus vite.
Voix 1 : C'est très clair. Mais alors, concrètement, comment on fait le tri? Si on ne veut pas casser la conversion, qu'est-ce qu'on doit garder et qu'est-ce qu'on peut supprimer sans risque sur une page produit?
Voix 2 : Sur le terrain, il faut utiliser une grille d'analyse très simple: distinguer ce qui sert le business de ce qui prend de la place pour rien. Le contenu utile, ce sont tes données structurées Schema.org, tes descriptions, et surtout tes images en format WebP ou AVIF. Même si les images pèsent souvent 60 % du poids total, elles restent le premier facteur de conversion. On cite l'exemple d'un client dans l'ameublement qui a supprimé ses avis clients pour gagner 15 points sur son score PageSpeed. Résultat: son score a monté, mais son taux de conversion a chuté de 12 %.
Voix 1 : Aïe, la fausse bonne idée par excellence. Et à l'inverse, ce fameux code inutile ou "markup mort", ça ressemble à quoi concrètement sur le terrain?
Voix 2 : Sur les boutiques Shopify qu'il audite, le consultant trouve en moyenne 4 à 5 applications installées dont les scripts se chargent encore alors qu'elles ne sont plus du tout utilisées. C'est du pur poids mort, tout comme le CSS de thèmes qui stylise des éléments absents ou les widgets de chat abandonnés. Un simple nettoyage de ces scripts inutiles permet de gagner entre 300 et 800 Ko par page, et de réduire le temps de chargement de 1 à 3 secondes sans jamais toucher au contenu.
Voix 1 : C'est très clair. La vraie question n'est donc jamais de savoir si la page est simplement trop lourde, mais de se demander ce qui la rend lourde et si cela sert réellement le business. Comment un e-commerçant doit-il prioriser ce chantier en termes de ROI?
Voix 2 : C'est exactement l'approche recommandée sur le terrain. La règle de base est simple: si un kilo-octet ne sert ni la conversion ni l'indexation, il n'a rien à faire là. Les pages qui préoccupent le plus le consultant lors d'un audit ne sont pas forcément les plus lourdes dans l'absolu, ce sont celles qui sont lourdes pour rien. Avoir 3 Mo de JavaScript tiers sur une fiche produit qui convertit bien, c'est un problème technique qui a une solution directe. À l'inverse, 800 Ko de HTML bien structuré avec des données produit complètes, c'est exactement ce que Google veut voir.
Voix 1 : C'est un excellent mot de la fin. On arrête de chasser le score absolu sur les outils de test, on nettoie le markup mort et on protège avant tout les éléments qui déclenchent les ventes. Quelle est l'action concrète à mettre en place pour nos auditeurs dès maintenant?
Voix 2 : L'action immédiate, c'est d'aller vérifier si vos propres pages e-commerce portent du poids mort. Et bien sûr,