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.
Note pour les boutiques Shopify : depuis le 31 mars 2026, Google a fixé une limite stricte de 2 Mo HTML par URL (contre 15 Mo de référence avant). Le HTML qui dépasse est partiellement fetché — title, canonical et structured data placés en bas peuvent passer sous le cutoff. Le détail dans crawl budget Shopify : ce que Google ignore vraiment en 2026.
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
perdre près de la moitié de ses acheteurs potentiels en l'espace d'un simple battement de cils.
C'est la réalité brutale du commerce en ligne aujourd'hui.
Ah ouais, un simple battement de cils, ça ne pardonne pas.
Ben non, ça ne pardonne pas du tout.
Et du coup, bienvenue dans cette nouvelle plongée au cœur des sources.
Le principe ici, c'est de prendre une montagne d'informations, d'articles de fonds pour en extraire l'essence absolue.
Ouais, un vrai raccourci direct vers la compréhension, avec le recul nécessaire pour y voir clair.
Exactement.
Et aujourd'hui, on s'attaque à une véritable angoisse pour quiconque gère une boutique en ligne.
La peur, panique d'avoir un site trop lourd.
La fameuse page obèse qui fait fuir tout le monde.
Voilà.
Et pour démystifier tout ça, notre matière première du jour, c'est un article extrêmement fouillé.
Il a été rédigé par Samy B.
Ouais, un praticien qui cumule plus de 10 ans de terrain en référencement e-commerce.
C'est ça.
C'est un document fascinant publié sur la plateforme de Vanguard Edge Consulting.
Et ce qui rend cette analyse super pertinente, c'est que ça ne vient pas d'un théoricien en laboratoire.
Ah non, pas du tout.
C'est quelqu'un qui gère les réalités du terrain au quotidien.
Parce que la réalité, quand on voit un outil d'analyse de performance qui clignote en rouge… Ah le fameux score rouge qui fait peur à tout le monde.
Grave.
La réaction immédiate ressemble souvent à un début d'incendie.
C'est clair.
On voit un score médiocre, un indicateur qui hurme que la page est trop lourde.
Et la première impulsion, c'est de vouloir tout jeter par-dessus bord pour alléger la structure.
On panique et on veut tout supprimer.
Mais le problème avec ce chiffre rouge, c'est qu'il m'empare omission.
En fait, il mélange absolument tout.
Il met tout dans le même sac.
Totalement.
Donc l'objectif de notre analyse aujourd'hui, notre mission, c'est de décortiquer cette notion de poids d'une page web.
Et on va voir pourquoi cette panique est presque toujours mal orientée, en s'appuyant sur les données strictes de l'article de Samy B.
Avant même de vouloir supprimer des images ou des fonctionnalités, il faut vraiment se poser une question de base.
De quel poids on parle exactement ?
C'est la vraie question.
L'analyse commence par un constat qui donne un peu le vertige.
En 2015, la page mobile médiane pesait 845 kilo-octets.
Même pas un méga-octet.
C'est ça.
Et aujourd'hui, on est à environ 2,5 méga-octets.
C'est un triplement pur et simple.
C'est énorme comme inflation.
Et face à ça, il faut catégoriser.
On ne peut pas optimiser un truc qu'on ne comprend pas.
Exactement.
Le diagnostic change du tout au tout, selon l'angle sous lequel on regarde le problème.
Absolument.
Et du coup, l'analyse met en lumière trois dimensions très distinctes du poids.
Ok.
Dis-moi.
La première, c'est le poids du HTML seul.
C'est le squelette de la page.
Le document textuel brut.
Le truc de base que le navigateur reçoit.
Voilà.
C'est crucial, parce que c'est ce que le robot d'exploration de Google reçoit et lit en premier.
Et l'article rappelle une contrainte technique stricte.
Une page a une limite de 2 mégaoctets pour son code HTML pur.
2 mégaoctets ?
Ça paraît beaucoup pour du texte, non ?
Pour visualiser, 2 mégaoctets de texte, c'est grossièrement l'équivalent de 2 romans complets.
Ah ouais, fait quand même !
Ouais.
Mais attention.
Au-delà de cette limite, Google ne ralentit pas.
Il coupe.
Il tronche la page et il arrête pur et simplement de lire.
Attends, il coupe direct ?
Direct.
Mais ça représente un danger silencieux massif pour les marchands, ça ?
Bah oui, complètement.
Si on prend l'exemple classique d'une page de catégorie de produits… Avec le défilement infini, là ?
Exactement.
Le défilement infini.
Où le code s'accumule ligne après ligne dans le fichier HTML.
Ça veut dire que les 50 derniers produits de la liste, ceux qui sont tout en bas, ils risquent de ne jamais être explorés par le moteur de recherche.
C'est fou quand on y pense.
Pour la machine, ils n'existent pas, quoi.
C'est ça.
Même s'ils sont en stock, même s'ils sont prêts à être vendus… C'est une vraie perte sèche invisible.
C'est clair.
Ensuite, la deuxième dimension, c'est ce qui provoque généralement les sueurs froides.
C'est le fameux poids total.
Ah, le gros chiffre qui fait peur.
Le gros chiffre.
Là, on prend le HTML, on y ajoute les feuilles de style, les scripts Javascript, les images, les polices d'écriture.
Tout le package.
Tout.
Et c'est ce chiffre massif qu'affichent les outils comme PageSpeed Insights.
Et ça monte vite.
Très vite.
Pour donner un ordre d'idée basé sur les chiffres de Samy B, les images représentent environ 60% de ce poids total.
Et le Javascript médian, il pèse à lui seul 664 kiloctets.
Oui, mais en fait, c'est une mesure de vanité, ça.
Comment ça ?
Ce chiffre brut, il est complètement trompeur.
Il met dans le même panier des éléments qui sont vitaux pour déclencher une vente et des lignes de code purement superflues.
Ah oui, je vois.
Mais surtout, ce n'est pas ça qui transite réellement dans les câbles.
Absolument.
Et ça nous amène direct à la troisième dimension, qui est la réalité physique.
Le poids transféré.
C'est là que ça devient intéressant.
C'est là que la magie de l'infrastructure web opère.
Oui.
L'article explique que les serveurs utilisent des technologies de compression à la volée.
Des trucs comme Brotli ou Giseppe.
Des algorithmes de compression, oui.
Voilà.
Et pour bien comprendre comment ça marche, Brotli ne détruit aucune donnée.
C'est un algorithme de dictionnaire.
Un dictionnaire ?
C'est-à-dire ?
Il analyse le code, il repère qu'une balise comme « class product card » et les répéter 50 fois sur la page.
Ok.
Et il remplace toutes ces occurrences par un minuscule raccourci.
Ah, malin.
Super malin.
Résultat, une page qui pèse virtuellement 10 mégaoctets sur le papier peut n'en transférer que 1 ou 2 sur le réseau.
D'ailleurs, l'auteur pointe très justement ce décalage sur le terrain.
Oui, c'est le grand écart.
Les équipes paniquent en voyant un rapport Lighthouse qui affiche 4,5 mégaoctets de poids total.
Mais quand on ouvre l'onglet réseau des outils d'analyse, on s'aperçoit que seulement 1,1 mégaoctet a été réellement transféré au visiteur.
La différence est spectaculaire.
Du simple au cadrucle, quoi.
Pour bien imager ce mécanisme, moi je suis certaine que l'analogie de la valise marche super bien.
Imaginons la préparation d'une valise pour un vol long courrier.
Ok, je vois le genre.
Le poids total, c'est la montagne de vêtements étalée sur le lit.
Évidemment, ça semble impossible à faire entrer dans la soute, tu vois.
Ouais, on a tous connu ça.
Mais le poids transféré, c'est cette même pile de vêtements une fois qu'elle est rangée dans un de ces gros sacs sous-vides.
Le truc où on a aspiré absolument tout l'air.
Ah oui, les sacs magiques, là.
Voilà.
Et ce qui compte pour le transfert dans l'avion, c'est la taille du sac sous-vide, pas le tas sur le lit.
Ouais, alors je vais me faire l'avocat du diable sur cette métaphore.
Vas-y, je t'écoute.
Parce que c'est bien beau d'avoir un sac sous-vide minuscule pour le transport, mais une fois arrivé à l'hôtel, il faut bien que quelqu'un ouvre ce foutu sac.
C'est vrai.
Qu'il l'aspire dans l'autre sens, qu'il sorte les vêtements un par un, qu'il les défroisse et qu'il les range dans l'armoire.
Ah, tu veux dire côté utilisateur ?
Exactement.
Dans notre cas, c'est le navigateur du visiteur.
Et souvent, c'est un téléphone portable avec un processeur un peu limité qui doit décompresser tout ce cadre et l'exécuter.
Ouais, le boulot ne disparaît pas, il est juste déplacé.
C'est ça.
Si on a mis dans le sac des pulls de ski pour aller au Bahama...
Donc du code JavaScript unit-il ?
Voilà.
Le téléphone va quand même devoir le décompresser, le lire, s'apercevoir qu'il ne sert à rien et enfin l'ignorer.
Et ça, ça prend de la puissance processeur et ça fige l'écran.
C'est une nuance super importante.
Le poids transféré est géré par la compression, ok, mais le temps d'exécution reste une charge pour la machine finale.
Tout à fait.
D'ailleurs, l'analyse de Vanguard Edge Consulting met le doigt sur un autre coupable qu'on ignore souvent quand on parle de lenteur.
Le serveur lui-même.
Exactement.
On s'acharne sur le poids des fichiers alors que la friction vient souvent de la source.
C'est ce qu'on appelle le TTFB, le temps de réponse initial.
Le time to first byte.
C'est ça.
Si le serveur mouline pendant 2 secondes et demie, juste pour interroger sa base de données avant même d'envoyer le tout premier octet d'image, c'est mort.
La page aura beau peser 10 kilo-octets, l'utilisateur va fixer un écran blanc pendant des plombes.
Bon, alors si la compression maîtrise si bien le transfert brut, on arrive à la question qui fâche.
Laquelle ?
Est-ce que les moteurs de recherche pénalisent réellement une page simplement parce qu'elle contient un volume massif d'octets ?
Genre, est-ce que ce fameux poids total a un impact direct sur le référencement ?
Eh bien, la réponse apportée par l'article va briser pas mal d'idées reçues, je pense.
Ah bon ?
Ouais.
En s'appuyant sur une déclaration directe de Gary Ellis, qui est porte-parole chez Google, la conclusion est sans appel.
La taille brute d'une page n'est pas un facteur de classement direct.
Attends, attends.
C'est complètement contre-intuitif ce que tu dis là.
Je sais.
On passe des années à entendre qu'il faut des sites ultra légers pour plaire à l'algorithme, qu'il faut tout minifier.
Et là, on découvre que c'est même pas un critère direct.
Pas direct, non.
En fait, ce qui prime pour Google, ce sont les signaux web essentiels.
Les Core Web Vitals.
Voilà.
On parle de la vitesse d'affichage de l'élément principal, le fameux LCP, de la stabilité visuelle au chargement et de la réactivité au clic.
Et le poids brut dans tout ça ?
L'article est très clair sur la mécanique.
Ces signaux de performance servent de critère de départage, un genre de tie-breaker.
Un tie-breaker, ok.
Si deux pages ont un contenu d'une pertinence égale, Google va utiliser la fluidité pour décider qui passe de l'an.
D'accord, je vois.
Et l'illustration donnée par l'auteur est redoutable de logique.
Une page massive de 15 mégaoctets, mais dont l'infrastructure est bien conçue pour un affichage stable et progressif, elle battra systématiquement une page de 3 mégaoctets qui reste bloquée par un script mal codé.
Donc la stabilité prime sur le poids absolu.
Mais alors, remettons notre cascade de commerçants deux secondes.
Vas-y.
Si c'est juste un simple critère de départage pour le référencement, pourquoi investir des budgets considérables là-dedans ?
C'est une bonne question.
Pourquoi payer des développeurs une fortune pour gratter quelques dixièmes de seconde si à la fin le bon contenu l'emporte toujours ?
C'est quoi le véritable intérêt de la démarche ?
Et c'est à ce moment précis que l'analyse délaisse la théorie du SEO pur pour frapper avec des données de conversion pure.
À l'argent.
Exactement.
Le lien avec le classement sur Google est peut-être subtil, c'est vrai, mais le lien avec le chiffre d'affaires, lui, il est d'une brutalité absolue.
Vas-y, donne-moi des chiffres.
Les études documentées dans l'article sont effarantes.
Déjà, Akamai a prouvé que l'ajout de deux petites secondes au temps de chargement génère une augmentation de 103% du taux de rebond.
103% ?
Ouais.
C'est mathématique.
Plus de la moitié des gens font demi-tour avant même que la vitrine ne s'affiche.
C'est des ventes mortes dans l'offre, ça.
Le client n'est même pas rentré dans le magasin.
C'est ça.
À l'inverse, quand on optimise, les gains sont tout aussi spectaculaires.
Par exemple, la plateforme Rakuten a mesuré une hausse de 61% de ses conversions après avoir stabilisé l'affichage de ses contenus.
61% d'acheteurs en plus ?
Ouais, juste en stabilisant l'affichage.
Et il n'y a plus parlant encore l'étude menée par le cabinet Deloitte dans le secteur du luxe.
Ok.
Ils ont documenté une progression de 40,1% du taux de passage de la fiche produit vers le panier d'achat.
40% de mise au panier en plus ?
Exactement.
Et devine pour quel gain de performance ?
Je sais pas, une ou deux secondes ?
0,1 seconde.
Attends, quoi ?
Un seul petit dixième de seconde gagné.
0,1 ?
C'est ouf.
Et c'est là qu'il faut s'arrêter une seconde pour analyser la psychologie humaine derrière ces chiffres, en fait.
Vas-y, je suis curieux.
Un dixième de seconde, physiologiquement parlant, c'est sous le seuil de perception conscient.
C'est littéralement la durée d'un battement de cils.
C'est ce qu'on disait au début, ouais.
L'œil ne le voit pas.
Mais le cerveau, lui, il le ressent.
Sous la barre des 100 millisecondes, le cerveau perçoit l'interface comme une extension naturelle du doigt, tu vois ?
Ah, intéressant.
Donc la navigation est fluible et la confiance s'installe.
Exactement.
Mais au-delà de ça, il y a une micro-friction.
Et dans un secteur comme le luxe, un délai imperceptible signale à notre subconscient que le site est peut-être fragile.
Ou obsolète, ou peu fiable.
C'est ça.
La confiance s'érode silencieusement.
C'est pour ça qu'un gain de 0,1 seconde sur 50 000 visiteurs, ça se transforme en dizaise de milliers d'euros.
C'est dingue quand on y pense.
L'optimisation, en fait, ce n'est pas pour faire plaisir à Google.
C'est pour asseoir la crédibilité numérique du magasin.
Ouais, cette réflexion psychologique est passionnante.
Mais du coup, ça nous place face à un vrai paradoxe technique.
Lequel ?
Si la fluidité génère l'achat, comment on fait pour alléger la page sans détruire ce qui déclenche l'envie d'acheter, justement ?
Ah oui, le contenu riche.
Voilà.
Si on reprend notre magasin physique, on ne va pas démonter les étagères et cacher les beaux produits juste pour que le client puisse courir plus vite dans les allées.
Ça n'a pas de sens.
C'est le dilemme quotidien des équipes e-commerce.
Grave.
On veut des belles photos, des finitions.
On veut des vidéos qui en jettent.
On veut des avis clients.
Et tout ça, ça pèse super lourd.
Et pour résoudre cette équation, l'analyse de Samy B.
apporte une grille de lecture vraiment chirurgicale.
En gros, il sépare fermement le contenu utile du mark-up mort.
OK.
Le contenu utile d'un côté.
Ouais.
Et côté contenu utile, on trouve tout ce qui sert l'humain ou la sémantique de la machine.
Par exemple, les données structurées, cachées dans le code, comme schéma.org, qui génèrent les petites étoiles dans les résultats de recherche.
Ça, c'est intouchable.
Intouchable.
Et surtout, les images.
L'article est formel là-dessus.
Même si elles pèsent 60% de la page, il faut absolument les conserver.
Mais on les compresse soi-même.
Ah oui, à condition qu'elles soient dans des formats de compression moderne, comme le WebP ou la VIFF, bien sûr.
OK.
Et un autre truc sacré, les avis clients.
Ils font partie intégrante de ce contenu utile.
Et ça, c'est parfois super difficile à faire entendre aux équipes techniques.
Ah bon ?
Bah ouais.
Avec une logique purement mathématique, un dœuf pourrait se dire, tiens, le module d'avis client pèse 400 kiloctets.
Si je le supprime, mon score de vitesse va s'envoler.
C'est la solution de facilité.
Exactement.
Eh bien, figure-toi que la source partage une anecdote terrible à Suyez, un vrai cas d'école.
Un client de l'auteur, dans le secteur de l'ameublement, a testé cette idée exacte.
Il a osé ?
Il a osé.
Il a carrément désactivé l'affichage de ses avis clients pour aller plus vite.
Et alors, résultat ?
Le résultat technique a été immédiat.
Un gain direct de 15 points sur son score de performance de page.
Ah bah, mission accomplie pour les développeurs.
Ils ont dû sabler le champagne.
Ouais, sauf que la répercussion commerciale derrière.
Aïe, les conversions ont chuté de 12%.
12% en moins sur les ventes, ouche !
En voulant gagner des millisecondes, le gars a supprimé la preuve sociale.
La fameuse réassurance psychologique dont un visiteur a absolument besoin avant d'acheter un canapé à 1000 euros en ligne.
C'est l'exemple parfait de l'optimisation aveugle.
Tu cours super vite, mais dans le mur.
C'est exactement ça.
Donc la cible à abattre, c'est définitivement pas le contenu visuel ou social.
C'est les fantômes du passé.
Ce que l'article appelle le mark-up mort.
Voilà, le mark-up mort.
Et là, la mécanique est fascinante d'inefficacité.
C'est-à-dire ?
Prenons l'exemple des applications tierces sur des plateformes comme Shopify.
L'équipe marketing installe une super application de compte à rebours pour le Black Friday.
Le truc classique.
La promotion se termine, l'équipe clique sur désinstaller dans le tableau de bord.
Fini.
Sauf que, très souvent, cette désinstallation laisse derrière elle un bout de code javascript injecté dans l'entête du site.
Ah, le bout de code orphelin.
Ouais.
Et pendant des mois, voire des années, chaque nouveau visiteur va télécharger ce fichier inutile.
Le processeur du téléphone va s'efforcer de le lire, chercher à l'exécuter, ne rien trouver à faire et finalement l'abandonner.
C'est absurde.
C'est une perte d'énergie totale.
L'analyse estime que nettoyer ces scripts orphelins permet de récupérer entre 300 et 800 kiloctets de poids par page.
Sans rien changer au visuel.
Sans retirer une seule once d'informations visuelles à l'acheteur.
Que du gras.
C'est énorme.
Mais du coup, ça amène inévitablement une réflexion d'ordre architectural, tu vois.
Comment ça ?
Puisqu'on jongle en permanence entre le besoin d'images lourdes pour convaincre l'humain et le besoin d'un code textuel ultra léger et rapide pour plaire aux robots de Google.
Ouais.
Pourquoi on ne sépare pas les deux mondes, tout simplement ?
Que veut dire deux versions différentes de la page ?
Ouais.
Techniquement, on pourrait très bien concevoir une version minimaliste, sans chichi, envoyée exclusivement aux moteurs de recherche quand ils passent.
Et on garderait une version super riche et visuelle pour les utilisateurs réels.
Ah, la fameuse ruse.
La question est extrêmement tentante, je te l'accorde.
Ça résoudrait tout le problème, non ?
Sauf que l'analyse l'IA y répond avec une mise en garde hyper sévère qui est basée sur les règles strictes et dictées par les moteurs de recherche.
Google s'y refuse catégoriquement.
C'est interdit.
Finalement, tenter de séparer l'humain et la machine, c'est mettre le doigt dans un engrenage fatal qu'on appelle le cloaking.
Le cloaking.
Il faut bien comprendre comment Google détecte ça aujourd'hui.
C'est plus les années 2000, tu vois.
Ouais, l'algorithme a évolué.
Il y a dix ans, le robot d'indexation lisait juste le texte brut, bêtement.
Mais aujourd'hui, Googlebot utilise un vrai navigateur sans interface graphique pour littéralement dessiner la page en interne.
Il fait un rendu complet.
Exactement.
Il compare le code brut avec ce qui s'affiche visuellement.
S'il remarque que le code envoyé à la machine parle gentiment de chaussures de sport, mais que le rendu visuel caché montre des liens vers des casinos en ligne… Alerte rouge immédiate.
Alerte rouge, pénalité terminée.
Et pour donner une échelle de cette surveillance, la source de Vanguard Edge Consulting rappelle un chiffre dingue.
Les systèmes de Google interceptent environ 40 milliards d'adresses web, considérées comme du spam chaque jour.
40 milliards par jour.
Par jour.
Donc l'algorithme a une capacité de détection des incohérences qui est colossale.
La règle imposée aux marchands est inflexible.
Un seul document pour les gouverner tous.
C'est ça.
Un seul et unique document HTML propre et identique pour tout le monde.
L'humain et la machine.
D'ailleurs, les données structurées présentes dans ce document unique servent précisément de traducteurs officiels pour les machines.
Donc inutile de ruser.
Ok, le message est clair.
Ce qui nous ramène inexorablement à la case départ.
Plutôt que de chercher des subterfuges ou de tricher avec deux versions, il faut nettoyer ce document unique avec une précision chirurgien.
Exactement.
Et fort de cette certitude, on arrive au moment le plus pragmatique de notre analyse.
La phase d'action.
Voilà.
Face à ces révélations, la réaction immédiate, c'est forcément de se demander si nos propres pages transportent des centaines de kilo-octets de scripts morts qui ralentissent nos ventes.
C'est la question que tout le monde se pose là.
Et la bonne nouvelle, c'est que l'article de Samy B.
partage une méthodologie d'audit manuelle.
Pas besoin de payer un outil hors de prix.
Non, ça ne nécessite aucun abonnement à des outils premium.
Tout se passe directement dans le navigateur Chrome.
L'outil de développement intégré.
Le fameux DevTools.
Le couteau suisse des développeurs.
C'est ça.
L'action concrète recommandée, c'est d'aller sur son propre site, de faire un clic droit n'importe où et de sélectionner inspecter.
Ok.
Ensuite, on ouvre l'onglet réseau ou network si le navigateur est en anglais.
Et c'est là que la magie opère.
Et c'est là que l'illusion se brise, ouais.
Il ne faut surtout pas regarder la colonne globale en bas, mais bien cibler la colonne qui s'appelle size ou taille.
Pourquoi celle-là spécifiquement ?
Parce que c'est cette colonne spécifique qui affiche le poids réellement transféré sur le réseau.
Le fameux poids compressé dont on parlait tout à l'heure avec l'histoire du sac sous vide.
Ah oui, la vraie taille de la valise.
Voilà, c'est elle qui reflète la vraie friction subie par la connexion internet du visiteur sur son téléphone dans le métro.
C'est super concret.
Et une fois qu'on a la vraie mesure sous les yeux, on fait comment pour traquer les anomalies ?
On lit toutes les lignes par ligne ?
Non, la méthodologie conseille d'utiliser les filtres de cet onglet réseau.
On clique d'abord sur le filtre GS pour isoler tout le javascript de la page.
Ok.
Et en regardant la liste des fichiers qui se chargent, l'objectif c'est de repérer les noms de domaines externes.
Est-ce qu'on voit passer un script appartenant à un outil de chat qu'on a abandonné il y a deux ans ?
Ou un module de statistiques qu'on ne regardait jamais.
C'est ça.
C'est là qu'il faut identifier ces parasites et demander à les faire supprimer.
Ensuite on passe au filtre des images.
Pour traquer les mauvaises compressions.
Exactement.
On vérifie visuellement si des bannières gigantesques sont chargées dans des formats super anciens, comme le JPEG non optimisé, plutôt que de bénéficier de la légèreté des formats modernes comme le WebP ou la VIF.
C'est un audit d'hygiène numérique d'une simplicité redoutable en fait.
Oui.
Mais je suis convaincu que c'est là que se cachent les gains de rentabilité les plus rapides pour beaucoup de marchands.
Tout à fait.
C'est là qu'on trouve l'or en fait.
D'ailleurs, pour ceux qui souhaitent suivre cette méthodologie pas à pas en ayant les vraies captures d'écran sous les yeux.
Oui, pour bien visualiser.
Ou juste revoir le détail des données strictes qu'on a citées, ou comprendre encore plus finement l'impact psychologique du temps de réponse serveur, il est vraiment impératif d'aller lire l'analyse complète.
On la trouve où ?
L'article est accessible sur www.vanguardedgeconsulting.com.blog.typageweb.sio e-commerce.
Je répète, www.vanguardedgeconsulting.com.blog.typageweb.sio e-commerce.
C'est une ressource vraiment dense, super documentée qui remet bien les pendules à l'heure sur ce qui compte vraiment.
Absolument.
Et tu sais, en fermant cette analyse, il y a une réflexion beaucoup plus globale qui émerge et qui dépasse très largement le simple cadre de la technique web.
Ah oui.
Tu penses à quoi ?
On a vu avec les données de l'étude de Deloitte qu'il y a un délai de 0,1 seconde.
Le fameux clin d'œil.
Oui.
Une fraction de temps littéralement indétectable par la conscience humaine, ce truc-là pouvait détruire 40% de la progression vers l'achat dans certains secteurs hyper exigeants.
C'est énorme.
Et la question qui se pose alors, et qu'on va laisser ouverte pour la suite parce qu'elle donne le vertige, c'est si un obstacle microscopique et invisible a un tel pouvoir de destruction sur les décisions d'agents en ligne, quelles autres frictions invisibles, psychologiques ou ergonomiques qui sont tolérées par simple habitude au quotidien dans nos parcours clients ?
Je vois où tu veux en venir.
Quelles autres frictions sont en train de siphonner silencieusement le chiffre d'affaires des boutiques en ligne à cet instant précis ?
C'est une excellente question pour continuer d'explorer les coulisses de la conversion.
Ça donne matière à réfléchir.
Grave.
Merci d'avoir plongé avec nous dans ces sources aujourd'hui et à très vite pour une nouvelle analyse en profondeur.
Comment analyser le poids réel de vos pages e-commerce
Durée : 20 min- 1
Ouvrir DevTools onglet Network
Dans Chrome DevTools, la colonne Size montre le poids transféré (après compression Brotli/gzip), la colonne Resource Size le poids décompressé. C'est le poids transféré qui reflète l'expérience réelle du visiteur.
- 2
Identifier les scripts JS et images inutiles
Filtrez par JS dans l'onglet Network et comptez les domaines externes. Chaque script de service inutilisé ajoute du poids sans bénéfice. Sur Shopify, vérifiez les apps orphelines dont les scripts se chargent encore.
- 3
Vérifier la limite de 2 Mo HTML pour Googlebot
Au-delà de 2 Mo de HTML pur, Googlebot tronque la page. Les produits en bas de page ne seront jamais indexés. Vérifiez que vos pages catalogue ne dépassent pas cette limite, surtout avec des centaines de produits inlinés.
- 4
Optimiser images et scripts tiers
Convertissez les images en WebP ou AVIF, dimensionnez-les pour l'écran réel, et activez le lazy loading sous le fold. Supprimez les scripts tiers inutilisés. Un nettoyage fait gagner 300 à 800 Ko par page et 1 à 3 secondes de chargement.
Questions fréquentes
La taille des pages web affecte-t-elle le classement Google ?
Pas directement. Gary Illyes de Google confirme que la taille brute d'une page n'est pas un facteur de classement. Ce qui compte, c'est l'impact sur les Core Web Vitals (LCP, CLS, INP), traités par Google comme un signal tiebreaker entre pages de qualité équivalente. En revanche, au-delà de 2 Mo de HTML pur, Googlebot tronque la page et arrête de lire le contenu.
Quelle est la taille idéale d'une page web e-commerce ?
Il n'existe pas de seuil absolu. La page médiane pèse entre 2,4 et 2,6 Mo sur mobile (HTTP Archive), mais le poids transféré après compression Brotli/gzip est souvent 2 à 3 fois inférieur. Le bon indicateur est le ratio contenu utile (images produit, Schema.org, avis clients) vs markup mort (scripts tiers inutilisés, CSS orphelin). Un nettoyage de scripts inutiles fait gagner 300 à 800 Ko par page et 1 à 3 secondes de chargement.
Le score PageSpeed Insights est-il un facteur de classement Google ?
Non. Le score PageSpeed est un indicateur synthétique de laboratoire, pas un facteur de classement. Google utilise les Core Web Vitals mesurés sur le terrain (données CrUX) comme signal, et uniquement en tiebreaker. Deloitte et Google ont mesuré que chaque seconde de délai supplémentaire coûte environ 7 % de conversions. L'impact principal de la vitesse est commercial, pas algorithmique.