Quelle taille atteint un fichier HTML autonome pour une page typique

Un fichier HTML autonome typique pèse de 1.4 à 1.6 MB sans JavaScript, et environ 2 MB à 2.3 MB si les scripts sont intégrés eux aussi. Les images causent presque tout ce poids. Aucun jeu de données public ne mesure directement les fichiers autonomes. Cet article construit donc l'estimation à partir de données publiées sur le poids des pages et indique où le calcul est de notre fait.

D'où viennent les chiffres

La source est le chapitre sur le poids des pages du Web Almanac 2025, qui rapporte les distributions de taille de HTTP Archive par type de ressource, séparées entre ordinateur et mobile. Nous n'avons capturé ni mesuré aucun fichier nous-mêmes. Nous avons pris les médianes publiées, appliqué le surcoût de Base64 et additionné le tout. Chaque chiffre ci-dessous est soit cité de ce chapitre, soit signalé comme dérivé.

Deux limites comptent. D'abord, le Web Almanac donne la médiane de chaque type de ressource séparément, et les médianes ne s'additionnent pas. La somme de cinq médianes est un ordre de grandeur, pas la médiane des sommes. Ensuite, les tableaux de l'Almanac décrivent ce qu'un navigateur télécharge. Un fichier autonome intègre ce que la page utilise réellement, ce qui peut être moins (images à chargement différé qui ne s'affichent jamais) ou plus (images récupérées d'emblée par la personne qui a enregistré la page).

Un fichier autonome désigne ici un seul fichier .html avec son CSS, ses images et ses polices intégrés, qui s'ouvre sans aucun autre fichier à côté. Pour en créer un, voyez exporter du HTML autonome depuis Chrome.

Médianes et percentiles par type

Voici les tailles de réponse du Web Almanac 2025 en KB. La colonne p50 est la médiane.

Pour le poids total de la page, la médiane de l'Almanac est de 2,412 KB sur ordinateur et de 2,164 KB sur mobile. Les images seules représentent 1,058 KB et 911 KB de ce total, le plus gros poste à lui seul.

La ligne HTML mérite un regard à part. Dans un instantané de HTTP Archive de janvier 2013 à janvier 2014, web.dev indiquait une médiane de 13 KB pour le HTML. La médiane de 2025 tourne autour de 33 à 35 KB. Le balisage seul a à peu près triplé, et il reste la plus petite part d'un fichier autonome.

Surcoût de Base64 : environ un tiers de plus

Les images et les polices sont binaires. Pour tenir dans un fichier HTML, il faut les écrire sous forme de texte, presque toujours en Base64 dans une URL data:. L'article de Wikipédia sur le schéma data URI chiffre le coût à environ 33% de plus que les données d'origine. Un JPEG de 300 KB devient environ 400 KB de texte.

Intégrer ne réduit rien. On échange des requêtes contre des octets. Le même article ne recommande les data URI en Base64 que si le serveur prend en charge la compression HTTP ou si le fichier intégré fait moins de 1 KB. Un fichier que vous envoyez par e-mail ou enregistrez en local ne profite pas de la compression du serveur : vous payez le tiers en entier.

Le format lui-même n'est pas le plafond. MDN précise que les navigateurs ne sont pas tenus de prendre en charge une longueur maximale particulière, et que Chromium et Firefox limitent les URL data à 512 MB, tandis que Safari (WebKit) les limite à 2048 MB. Firefox 97 a relevé son ancienne limite de 256 KB à 32 MB, et Firefox 136 à 512 MB. Une vraie page n'approche jamais ces valeurs. Les limites pratiques sont le transfert du fichier, la mémoire et le temps qu'un éditeur met à l'ouvrir.

Une estimation à la louche

Voici le calcul, avec les médianes de 2025 ci-dessus. Les parties texte (HTML, CSS) restent telles quelles. Les parties binaires (images, polices) sont multipliées par 4/3 à cause de Base64. C'est une dérivation de notre part, pas une mesure.

La réponse au titre est donc d'environ 1.4 à 1.6 MB sans scripts et 2.0 à 2.3 MB avec, pour une page située à la médiane sur tous les axes. Voyez-y un centre de gravité, pas une prévision pour votre page.

L'écart est large. Le 90e percentile des images est de 6,856 KB sur ordinateur et de 6,288 KB sur mobile. Une page avec autant de données d'image, intégrées en Base64, produit un fichier bien au-delà de 8 MB rien qu'avec les images (6,856 x 4/3 font environ 9,141 KB). À l'autre extrémité, le poids d'image du 10e percentile n'est que de 56 à 74 KB, si bien qu'une page légère peut rester sous 200 KB.

Où passent les octets

Regardez la proportion, pas les totaux. Sur ordinateur, les images et les polices représentent environ 1,081 des 1,199 KB des quatre types hors scripts, soit près de 90%. Une fois intégrée, cette part augmente, car Base64 ne s'applique qu'à elles. Le balisage et les styles réunis font environ 118 KB, moins de 10% du fichier.

C'est pourquoi deux fichiers autonomes peuvent différer d'un ordre de grandeur. Une page marketing avec cinq photos d'en-tête et une page de documentation en texte seul ont à peu près le même budget HTML et CSS. Ce sont les photos qui font la différence.

Les scripts sont l'autre facteur de variation. La page médiane sur ordinateur livre 708 KB de JavaScript. Qu'un fichier enregistré les contienne dépend de la façon dont vous capturez la page. Un enregistrement par le navigateur conserve généralement les scripts. Une capture destinée au travail de design n'en a souvent pas besoin. Enregistrer une archive web Safari est une autre voie, avec son propre profil de taille.

Garder le fichier léger

Vous pouvez alléger un fichier autonome sans toucher au design. Chaque conseil découle des chiffres ci-dessus.

• Redimensionnez les images avant de les intégrer. Les images font environ 90% des octets. Une photo affichée à 800 px de large n'a pas besoin d'une source de 3,000 px.
• Utilisez un format compressé. Réencodez les photos en WebP ou AVIF avant qu'elles ne deviennent du Base64, car le surcoût de 33% augmente avec la taille de départ.
• N'intégrez que les petites ressources. La règle de Wikipédia de moins de 1 KB est une limite raisonnable pour les icônes. Les fichiers plus gros restent mieux comme ressources séparées si le format le permet.
• Supprimez les scripts inutiles. Avec une médiane de 646 à 708 KB, JavaScript est le deuxième plus gros bloc.
• Allégez les polices aux caractères utilisés. Les polices sont petites à la médiane (23 KB), mais le 90e percentile avoisine 80 KB.

La taille prédit-elle les problèmes d'import ?

La taille et le comportement à l'import sont deux questions distinctes. UnHTML accepte en entrée un fichier .html autonome, et ses pages n'indiquent aucune limite de taille de fichier. Le plugin gratuit plafonne les imports à 500 calques par page, et Pro n'a pas de plafond de calques, en octobre 2026. Les calques viennent des éléments, pas des octets : un fichier de 6 MB de photos peut donc s'importer avec moins de calques qu'un fichier de 300 KB de balisage dense.

Les gros fichiers prennent tout de même plus de temps à charger et à ouvrir. Si une page s'importe lentement, vérifiez d'abord le nombre d'éléments, puis la taille du fichier. Pour des nombres de calques et des taux de repli mesurés, voyez nombres de calques, taux de repli et substitution de polices à l'import dans Figma.

En bref

Une page médiane enregistrée en un seul fichier pèse de 1.4 à 1.6 MB sans scripts et de 2.0 à 2.3 MB avec, d'après notre calcul à partir du Web Almanac 2025. Les images déterminent le chiffre, Base64 ajoute environ un tiers à chaque ressource binaire, et les navigateurs ne vous arrêteront pas avant 512 MB. Si votre fichier dépasse nettement cette fourchette, regardez d'abord les images. Quand vous voudrez amener une page enregistrée dans Figma, partez de la page d'accueil d'UnHTML.