Pourquoi le poids des pages mobiles a-t-il triplé en une décennie ?

D'où vient cette explosion du poids des pages ?

Le Web Almanac révèle une tendance lourde : le poids médian des pages mobiles a triplé en 11 ans. Plusieurs facteurs expliquent cette dérive : prolifération des frameworks JavaScript, images haute résolution non optimisées, multiplication des scripts tiers (analytics, publicité, chatbots), et CSS/JS non minifiés.

Cette inflation n'est pas anodine. Elle se traduit par des temps de chargement dégradés, surtout sur réseaux lents (3G, 4G instable). Or, Google a clairement indexé la vitesse comme facteur de classement via les Core Web Vitals depuis mi-2021.

Que signifie concrètement un poids médian de 2,3 Mo ?

Concrètement, 2,3 Mo représentent environ 80 requêtes HTTP en moyenne. Sur une connexion 3G (environ 1,6 Mbps), cela donne un temps de téléchargement théorique de ~11 secondes — sans compter le parsing et le rendu. La médiane masque aussi des situations extrêmes : certains sites dépassent 5-6 Mo.

Pour un praticien SEO, cela pose un problème direct : le LCP (Largest Contentful Paint) explose. Si votre hero image pèse 800 Ko et arrive après 2 Mo de JS, vous êtes hors clous. Le seuil "bon" du LCP est de 2,5 secondes — difficile à tenir avec un tel lest.

Pourquoi cette déclaration de Gary Illyes maintenant ?

Gary Illyes ne sort pas ce chiffre par hasard. Google observe une dégradation généralisée des performances dans son index. En pointant cette inflation, il envoie un message clair : les SEO et développeurs doivent reprendre le contrôle du poids des pages.

Cette déclaration s'inscrit dans la continuité du discours Google sur l'expérience utilisateur. Après avoir introduit les Core Web Vitals, le moteur rappelle que l'optimisation technique reste un prérequis — pas une cerise sur le gâteau.

• Le poids médian a triplé : de 845 Ko à 2,3 Mo en 11 ans
• JavaScript et images sont les principaux responsables de cette inflation
• Impact direct sur les Core Web Vitals, notamment LCP et FID
• Les sites mobiles sont les plus touchés : réseaux lents + poids élevé = catastrophe UX
• Google rappelle que la vitesse reste un critère de classement

Cette déclaration est-elle cohérente avec ce qu'on observe sur le terrain ?

Oui, totalement. Les audits que je mène montrent systématiquement des pages qui dépassent allègrement les 3-4 Mo, surtout sur les sites e-commerce ou médias. Le problème, c'est que beaucoup de clients ne mesurent même pas le poids de leurs pages — ils découvrent le chiffre lors de l'audit initial.

Ce qui me frappe, c'est que cette inflation est souvent invisible côté desktop. Avec des connexions fibre et des machines puissantes, les équipes internes ne ressentent pas la douleur. Mais dès qu'on teste sur un vrai mobile, en 4G bridé, la réalité frappe : 8-10 secondes pour afficher le contenu principal.

Quelles nuances faut-il apporter à ce constat ?

Gary Illyes parle de médiane, pas de moyenne. Cela signifie que 50 % des sites sont au-dessus de 2,3 Mo. Mais attention : certains sites très bien optimisés restent sous 1 Mo, même avec du contenu riche. Le problème n'est donc pas une fatalité technique — c'est une question de discipline et de priorités.

Autre nuance : le poids brut ne dit pas tout. Un site de 2,3 Mo avec du lazy loading intelligent, du code-splitting et du HTTP/2 peut charger plus vite qu'un site de 1,5 Mo mal structuré. Le poids est un indicateur, pas une condamnation automatique. [À vérifier] : Gary Illyes ne précise pas si Google pondère le poids brut ou prend en compte les stratégies de chargement différé dans son évaluation des Core Web Vitals.

Dans quels cas cette règle ne s'applique-t-elle pas strictement ?

Si vous opérez un site en PWA (Progressive Web App) avec un service worker bien configuré, le poids initial importe moins : le cache fait le job pour les visites suivantes. Idem pour les sites à forte audience récurrente (SaaS, outils métier) où l'utilisateur ne voit le poids qu'une fois.

Mais soyons honnêtes : pour un site contenu classique (blog, e-commerce, média), la première visite compte énormément. Google crawle comme un nouvel utilisateur — sans cache. Si votre LCP explose dès le premier chargement, vous perdez en ranking. La règle s'applique donc à 90 % des cas.

Que faut-il faire concrètement pour réduire le poids des pages ?

Première priorité : audit technique complet. Utilise WebPageTest, Lighthouse et PageSpeed Insights pour identifier les ressources lourdes. Ensuite, passe au crible images, JavaScript et CSS. Les images représentent souvent 50-70 % du poids — compresse-les systématiquement.

Pour les images, adopte les formats modernes (WebP, AVIF) avec fallback. Mets en place du lazy loading natif (loading="lazy") pour tout ce qui n'est pas above-the-fold. Côté JS/CSS, minifie, compresse (Gzip/Brotli), et coupe tout ce qui n'est pas critique.

Quelles erreurs éviter absolument ?

Ne charge pas 15 scripts tiers sans les auditer. Chaque pixel de tracking, chaque chatbot, chaque widget social ajoute 100-300 Ko. Beaucoup de ces scripts sont inutilisés ou redondants. Fais le tri : garde ce qui sert vraiment, diffère ou supprime le reste.

Autre piège : les polices web non optimisées. Charger 6 variantes d'une Google Font en WOFF2 peut peser 400 Ko. Limite-toi à 2-3 graisses maximum, utilise font-display: swap, et héberge localement si possible.

Comment vérifier que mon site est conforme aux bonnes pratiques ?

Teste ton site sur plusieurs conditions réseau (3G slow, 4G, fibre) via les DevTools Chrome. Le poids total doit idéalement rester sous 1,5 Mo pour le mobile. Si tu dépasses 2 Mo, c'est un signal d'alarme : creuse chaque ressource au-dessus de 100 Ko.

Mets en place un budget de performance dans ton CI/CD. Des outils comme Lighthouse CI ou SpeedCurve peuvent bloquer un déploiement si le poids ou le LCP dégradent. Automatiser la surveillance évite les régressions silencieuses.

• Auditer le poids des pages avec WebPageTest et Lighthouse
• Compresser toutes les images (WebP/AVIF + lazy loading)
• Minifier et compresser JS/CSS (Gzip/Brotli)
• Faire le tri dans les scripts tiers : garder l'essentiel, différer ou supprimer le superflu
• Optimiser les polices web : 2-3 variantes max, font-display: swap
• Tester sur connexions lentes (3G slow) pour détecter les régressions
• Mettre en place un budget de performance automatisé dans le CI/CD