Wie groß eine eigenständige HTML-Datei für eine typische Seite wird

Eine typische eigenständige HTML-Datei ist ohne JavaScript etwa 1.4 bis 1.6 MB groß und mit eingebetteten Skripten grob 2 MB bis 2.3 MB. Fast das gesamte Gewicht stammt von den Bildern. Kein öffentlicher Datensatz misst eigenständige Dateien direkt. Deshalb baut dieser Artikel die Schätzung aus veröffentlichten Seitengewichtsdaten auf und sagt, wo die Rechnung von uns stammt.

Woher die Zahlen kommen

Die Quelle ist das Kapitel zum Seitengewicht im Web Almanac 2025. Es nennt die HTTP-Archive-Größenverteilungen je Ressourcentyp, getrennt nach Desktop und Mobil. Wir haben selbst keine Dateien erfasst oder gemessen. Wir haben die veröffentlichten Mediane genommen, den Base64-Aufschlag angewendet und alles addiert. Jede Zahl unten ist entweder aus diesem Kapitel zitiert oder als abgeleitet gekennzeichnet.

Zwei Einschränkungen zählen. Erstens meldet der Web Almanac den Median jedes Ressourcentyps einzeln, und Mediane lassen sich nicht addieren. Die Summe von fünf Medianen ist ein Richtwert, nicht der Median der Summen. Zweitens beschreiben die Tabellen des Almanac, was ein Browser herunterlädt. Eine eigenständige Datei bettet ein, was die Seite tatsächlich nutzt. Das kann weniger sein (verzögert geladene Bilder, die nie erscheinen) oder mehr (Bilder, die beim Speichern vorzeitig abgerufen wurden).

Eine eigenständige Datei ist hier eine einzelne .html-Datei mit eingebettetem CSS, eingebetteten Bildern und Schriften, die sich ohne weitere Dateien daneben öffnen lässt. Wie Sie eine erzeugen, lesen Sie unter eigenständiges HTML aus Chrome exportieren.

Mediane und Perzentile je Typ

Das sind die Antwortgrößen des Web Almanac 2025 in KB. Die Spalte p50 ist der Median.

Lesen Sie die Tabelle zeilenweise. Die Mediane für HTML, CSS und Schriften sind klein, die für JavaScript und Bilder groß, und beim 90. Perzentil öffnet sich die Schere noch weiter. Genau dieses Muster erklärt, warum sich die Größe einer eigenständigen Datei fast vollständig aus den Bildern ergibt.

Beim Gesamtgewicht der Seite liegt der Median des Almanac bei 2,412 KB auf dem Desktop und 2,164 KB mobil. Allein die Bilder machen davon 1,058 KB und 911 KB aus, den mit Abstand größten Einzelposten.

Die HTML-Zeile verdient einen eigenen Blick. In einer HTTP-Archive-Momentaufnahme von Januar 2013 bis Januar 2014 meldete web.dev einen Median von 13 KB für HTML. Der Median von 2025 liegt bei etwa 33 bis 35 KB. Das Markup allein hat sich ungefähr verdreifacht und bleibt trotzdem der kleinste Anteil einer eigenständigen Datei.

Base64-Aufschlag: etwa ein Drittel größer

Bilder und Schriften sind binär. Damit sie in einer HTML-Datei stehen können, müssen sie als Text geschrieben werden, fast immer als Base64 in einer data:-URL. Der Wikipedia-Artikel zum Data-URI-Schema beziffert die Kosten auf ungefähr 33% mehr als die Originaldaten. Ein JPEG mit 300 KB wird zu etwa 400 KB Text.

Einbetten macht nichts kleiner. Es tauscht Anfragen gegen Bytes. Derselbe Artikel empfiehlt Base64-Data-URIs nur, wenn der Server HTTP-Kompression unterstützt oder die eingebettete Datei kleiner als 1 KB ist. Eine Datei, die Sie per E-Mail verschicken oder lokal speichern, profitiert nicht von Serverkompression. Sie zahlen also das volle Drittel.

Eine harte Obergrenze für die Dateigröße gibt es dabei nicht. Das Format selbst ist nicht die Grenze. MDN weist darauf hin, dass Browser keine bestimmte Maximallänge unterstützen müssen und dass Chromium und Firefox data-URLs auf 512 MB begrenzen, Safari (WebKit) auf 2048 MB. Firefox 97 hob sein altes Limit von 256 KB auf 32 MB an, Firefox 136 auf 512 MB. Eine echte Seite kommt nie in die Nähe dieser Werte. Die praktischen Grenzen sind Dateiübertragung, Arbeitsspeicher und die Zeit, die ein Editor zum Öffnen braucht.

Eine Überschlagsrechnung

Hier die Rechnung mit den Medianen von 2025 von oben. Die Textanteile (HTML, CSS) bleiben unverändert. Die binären Anteile (Bilder, Schriften) werden wegen Base64 mit 4/3 multipliziert. Das ist unsere Ableitung, keine Messung.

Die Antwort auf die Titelfrage lautet also ungefähr 1.4 bis 1.6 MB ohne Skripte und 2.0 bis 2.3 MB mit Skripten, für eine Seite, die auf jeder Achse im Median liegt. Betrachten Sie das als Schwerpunkt, nicht als Prognose für Ihre Seite. Eine Seite mit vielen Fotos liegt deutlich darüber, eine schlanke Textseite deutlich darunter, und die Spalte für Mobilgeräte fällt wegen der geringeren Bild- und Skriptgewichte jeweils etwas kleiner aus.

Die Streuung ist groß. Das 90. Perzentil der Bilder beträgt 6,856 KB auf dem Desktop und 6,288 KB mobil. Eine Seite mit so vielen Bilddaten ergibt, als Base64 eingebettet, allein durch die Bilder eine Datei weit über 8 MB (6,856 x 4/3 sind etwa 9,141 KB). Am anderen Ende liegt das Bildgewicht beim 10. Perzentil nur bei 56 bis 74 KB, sodass eine schlanke Seite unter 200 KB bleiben kann.

Wohin die Bytes gehen

Achten Sie auf das Verhältnis, nicht auf die Summen. Auf dem Desktop machen Bilder und Schriften etwa 1,081 von 1,199 KB über die vier Nicht-Skript-Typen aus, rund 90%. Beim Einbetten wächst dieser Anteil, denn Base64 betrifft nur sie. Markup und Stile zusammen sind etwa 118 KB, unter 10% der Datei.

Deshalb können sich zwei eigenständige Dateien um eine Größenordnung unterscheiden. Eine Marketingseite mit fünf Titelfotos und eine reine Textdokumentation haben ungefähr dasselbe HTML- und CSS-Budget. Die Fotos machen den Unterschied.

Skripte sind der zweite große Schwankungsfaktor. Die mediane Desktop-Seite liefert 708 KB JavaScript aus. Ob eine gespeicherte Datei es enthält, hängt davon ab, wie Sie die Seite erfassen. Ein Browser-Speichern behält die Skripte meist. Eine Erfassung für Designarbeit braucht sie oft nicht. Eine Safari-Webarchiv-Datei zu speichern ist ein weiterer Weg, mit eigenem Größenprofil.

Die Datei klein halten

Sie können eine eigenständige Datei verkleinern, ohne das Design anzufassen. Jeder Tipp folgt aus den Zahlen oben.

• Bilder vor dem Einbetten verkleinern. Bilder machen etwa 90% der Bytes aus. Ein Foto, das 800 px breit angezeigt wird, braucht kein Original mit 3,000 px.
• Ein komprimiertes Format nutzen. Kodieren Sie Fotos als WebP oder AVIF neu, bevor sie zu Base64 werden, denn der Aufschlag von 33% wächst mit der Ausgangsgröße.
• Nur kleine Ressourcen einbetten. Die Wikipedia-Richtlinie von unter 1 KB ist für Icons eine vernünftige Grenze. Größere Dateien bleiben besser getrennte Ressourcen, wenn das Format es zulässt.
• Nicht benötigte Skripte weglassen. Mit einem Median von 646 bis 708 KB ist JavaScript der zweitgrößte Block.
• Schriften auf benutzte Zeichen beschränken. Schriften sind im Median klein (23 KB), das 90. Perzentil liegt aber bei etwa 80 KB.

Sagt die Größe Importprobleme voraus?

Größe und Importverhalten sind getrennte Fragen. UnHTML nimmt eine eigenständige .html-Datei als Eingabe, und die Seiten nennen kein Limit für die Dateigröße. Das kostenlose Plugin begrenzt Importe auf 500 Ebenen pro Seite, Pro hat kein Ebenenlimit, Stand Oktober 2026. Ebenen entstehen aus Elementen, nicht aus Bytes. Eine 6-MB-Datei voller Fotos kann deshalb mit weniger Ebenen importiert werden als eine 300-KB-Datei mit dichtem Markup.

Große Dateien brauchen trotzdem länger zum Laden und Öffnen. Wenn eine Seite langsam importiert, prüfen Sie zuerst die Elementzahl und dann die Dateigröße. Gemessene Ebenenzahlen und Fallback-Raten finden Sie unter Ebenenzahlen, Fallback-Raten und Schriftersetzung beim Figma-Import.

Kurz gesagt

Eine mediane Seite als Einzeldatei ist nach unserer Rechnung aus dem Web Almanac 2025 etwa 1.4 bis 1.6 MB ohne Skripte und 2.0 bis 2.3 MB mit Skripten groß. Die Bilder bestimmen die Zahl, Base64 schlägt auf jede binäre Ressource etwa ein Drittel auf, und Browser bremsen Sie nicht vor 512 MB. Liegt Ihre Datei weit über diesem Bereich, schauen Sie zuerst auf die Bilder. Wenn Sie eine gespeicherte Seite nach Figma holen wollen, beginnen Sie auf der UnHTML-Startseite.