L'évolution du web et le poids des images : une histoire de bande passante

La toute première page web de l'histoire, publiée par Tim Berners-Lee en août 1991 depuis le CERN, ne comportait pas une seule image. C'était du texte brut avec des liens soulignés, expliquant ce qu'était ce projet appelé « World Wide Web ». Un peu plus de trente ans plus tard, une page produit e-commerce moyenne charge plus de deux mégaoctets rien qu'en images. Voici l'histoire de comment on est passé d'une chose à l'autre — et pourquoi, pour quiconque gère un site aujourd'hui, le poids des images reste la variable individuelle qui casse le plus souvent la vitesse d'un site.

1991-1995 : un web pensé pour des modems à 2400 bauds

Les premiers navigateurs graphiques — Mosaic en 1993, puis Netscape Navigator en 1994 — permettaient bien d'intégrer des images, mais le contexte technique imposait une discipline brutale. Un modem domestique typique de 1994 transmettait à 14,4 ou 28,8 kbps. Une seule image JPG de 100 Ko, que nous jugerions aujourd'hui minuscule, pouvait mettre près d'une minute à charger à cette vitesse. Résultat : les sites de l'époque utilisaient les images au compte-gouttes, presque toujours en GIF 256 couleurs (plus léger qu'un JPG sur des graphiques simples), et toute photographie réelle était recadrée et compressée de façon agressive. L'esthétique « pixelisée » que nous associons aujourd'hui aux années 90 n'était pas un choix de design — c'était la seule option que la bande passante permettait.

1995-2005 : le haut débit arrive, et l'image cesse d'être un luxe

L'arrivée de l'ADSL et du câble dans les foyers a changé la donne. Au début des années 2000, une connexion domestique moyenne supportait déjà plusieurs centaines de kbps, voire plus, et les sites web ont commencé à être conçus comme des catalogues visuels, plus seulement comme des documents avec des liens. Amazon, eBay et les premières boutiques en ligne ont vite compris qu'une photo de produit vendait mieux qu'une simple description — et les pages ont commencé à se remplir d'images sans que personne ne se soucie vraiment de leur poids, car le haut débit semblait tout résoudre. Cet optimisme a créé une habitude qui a encore du mal à disparaître : mettre en ligne la photo telle qu'elle sort de l'appareil photo ou du téléphone, sans la compresser, parce que « de toute façon, il n'y a plus de dial-up ».

2007-2015 : le mobile change tout (encore une fois)

L'iPhone, en 2007, et la vague de smartphones qui a suivi, ont ressuscité le même problème que dans les années 90, mais à l'envers : la connexion redevenait limitée (3G, forfaits de données mobiles facturés au mégaoctet) juste au moment où les sites s'étaient habitués à peser plusieurs mégaoctets en fixe. La réponse de l'industrie fut le design responsive (le terme a été forgé par Ethan Marcotte en 2010) — un même site qui s'adapte à n'importe quel écran — puis, plus progressivement, l'idée de servir des images de taille différente selon l'appareil, plutôt que d'envoyer la même photo destinée au bureau vers un écran mobile qui ni n'en a besoin, ni ne peut l'afficher en entier.

2015-aujourd'hui : Google se met à mesurer la vitesse, et soudain, ça compte

Le changement le plus déterminant de la dernière décennie n'a pas été technique, mais incitatif : Google a commencé à utiliser la vitesse de chargement comme facteur de classement, et en 2021, cela a été formalisé avec les Core Web Vitals — des métriques concrètes comme le LCP (Largest Contentful Paint, le temps que met à s'afficher le plus grand élément visible, presque toujours une image) qui ont un impact direct sur le SEO. Du jour au lendemain, bien compresser une image a cessé d'être une simple « bonne pratique » pour devenir quelque chose ayant un impact mesurable sur le trafic reçu par un site. C'est la raison d'être d'outils comme celui-ci : ce n'est pas une mode de design, c'est que le poids des images est devenu une métrique business.

Les tendances de l'image en 2026

Fort de ce contexte historique, voici ce que l'on observe aujourd'hui, en 2026, dans la manière dont les images sont utilisées sur le web :

• AVIF et WebP comme standard, non comme exception. Il y a quelques années encore, servir ces formats exigeait de vérifier soigneusement la compatibilité des navigateurs. Aujourd'hui, la prise en charge est quasiment universelle, et la question n'est plus « puis-je utiliser le WebP ? » mais « pourquoi est-ce que je continue à servir du JPG par défaut ? ».
• Moins de photographie de stock générique, plus de contenu généré ou retouché par IA.Pas seulement parce que c'est moins cher (même si c'est aussi le cas), mais parce que cela correspond mieux aux marques qui veulent une esthétique propre plutôt que la même image de personnes souriant dans un bureau que tout le monde utilise.
• Formats verticaux par défaut. La consommation majoritaire se fait désormais sur mobile, et la conception des images — pour les réseaux sociaux, les bannières, les miniatures — se pense d'abord en vertical (9:16, 4:5) avant d'être adaptée à l'horizontal, à l'inverse de ce qui se faisait il y a dix ans.
• Le chargement différé (lazy loading) natif par défaut. L'attribut loading="lazy"du HTML lui-même, sans bibliothèque externe, est devenu la norme pour éviter de charger des images que l'utilisateur ne verra jamais.
• Une pression constante pour réduire le poids, pas pour ajouter de la résolution. Les écrans continuent de s'améliorer (plus de densité de pixels, plus de HDR), mais la tendance réelle en production web va à l'inverse de ce qu'on pourrait attendre : exporter en étant plus compressé, pas moins, car le coût du transfert de données et l'impact sur les Core Web Vitals pèsent plus lourd que le gain visuel marginal d'un fichier un peu plus net.