Zum Inhalt springen
checkfrei
Menü

HTML-Größe reduzieren: Grenzwerte, Ursachen und Lösungen

Stand: 3. Oktober 2026 · CAZ Labs

Kurz gesagt

Das HTML einer Seite sollte unkomprimiert unter 200 KB bleiben, über 500 KB ist es eindeutig zu viel. Der Text selbst ist dabei fast nie das Problem. Aufgebläht wird das Dokument durch eingebettete Daten, Inline-Grafiken und verschachtelte Page-Builder-Blöcke.

Warum das wichtig ist

Das HTML ist die erste Datei, die der Browser lädt, und die einzige, auf die er nicht verzichten kann. Erst beim Lesen erfährt er, welche Bilder, Schriften und Skripte er noch holen muss. Ein dickes Dokument verzögert also alles, was danach kommt.

Zur Einordnung: Ein Text mit 1.000 Wörtern ist als reiner Text rund 7 KB groß. Wiegt dein HTML 400 KB, besteht es zu über 98 Prozent aus etwas anderem, nämlich aus Markup, Inline-CSS, JavaScript und eingebetteten Daten.

Auch nach dem Laden kostet ein großes Dokument Zeit, weil der Browser jedes Element verarbeiten muss. Auf einem älteren Handy merkst du das. Die Komprimierung macht die Übertragung kleiner, am Rechenaufwand im Browser ändert sie nichts. Deshalb messen wir die unkomprimierte Größe.

So prüfst du es selbst

checkfrei misst die Größe des unkomprimierten HTML bei jedem kostenlosen Check mit. Unter 200 KB ist gut, bis 500 KB gibt es eine Warnung, darüber einen Fehler.

Selbst nachsehen geht in den Entwicklertools des Browsers. Noch schneller ist curl: Ohne Zusatzoption fordert es keine Komprimierung an, die Zahl entspricht also dem unkomprimierten HTML. Unter Windows schreibst du NUL statt /dev/null.

  1. F12 drücken, den Tab Netzwerk öffnen und die Seite neu laden.
  2. Schalt in den Einstellungen des Netzwerk-Tabs die großen Anfragezeilen ein. Dann zeigt Chrome in der Spalte Größe zwei Werte: übertragen und tatsächlich. Der zweite ist der, den wir messen.
  3. Um zu sehen, was so viel Platz frisst, öffne den Quelltext mit Strg+U und scroll einmal durch. Lange Blöcke voller Zeichensalat sind fast immer eingebettete Bilder (data:image) oder JSON-Daten.
bash
curl -s -o /dev/null -w "%{size_download} Bytes\n" https://deine-domain.de

So behebst du es

Die Ursachen wiederholen sich von Seite zu Seite:

  • Bilder als Base64. Ein Foto mit 60 KB wird als data:-Adresse rund 80 KB groß und steht dann mitten im HTML, wo es kein Browser-Cache wiederverwenden kann.
  • Inline-SVG, besonders Icons, die zwanzigmal auf der Seite stehen, oder Illustrationen mit Tausenden Pfadpunkten.
  • Page-Builder-Verschachtelung. Elementor, Divi und ähnliche Builder packen jeden Textblock in mehrere div-Ebenen mit langen Klassenlisten.
  • Doppelte Navigation. Viele Themes geben das Menü einmal für Desktop und einmal für Mobil aus. Bei einem Mega-Menü mit 200 Links ist das ein ordentlicher Teil der Seite.
  • Eingebettete Daten. Shops und Frameworks schreiben Produktdaten oder den Zustand der App als JSON ins HTML.

WordPress

  1. Such im Quelltext nach data:image. Gefunden? Dann bettet das Theme oder ein Optimierungs-Plugin Bilder inline ein. Such in dessen Einstellungen nach der passenden Option und schalt sie ab.
  2. Prüf, ob dein Optimierungs-Plugin das komplette CSS in den Kopf schreibt. Bei Autoptimize heißt die Option "Inline all CSS". Das lohnt sich nur bei sehr wenig CSS.
  3. Räum Page-Builder-Seiten auf. Elemente, die du per Einstellung auf Mobil oder Desktop ausblendest, stehen trotzdem im HTML. Was niemand sieht, kann weg.

Shopify

Bei Shopify blähen vor allem Apps das HTML auf. Deinstallierte Apps hinterlassen manchmal Snippets im Theme. Dupliziere das Theme, öffne über Code bearbeiten den Ordner snippets und prüf, ob Dateien alter Apps noch eingebunden sind.

Next.js

Next.js schreibt die Daten, die Client-Komponenten brauchen, mit ins HTML. Im Pages Router steckt alles aus getStaticProps oder getServerSideProps im Skript __NEXT_DATA__, im App Router landen die Props von Client-Komponenten im eingebetteten RSC-Payload. Reich deshalb nur die Felder weiter, die wirklich angezeigt werden.

jsx
// schickt das komplette CMS-Objekt mit ins HTML
<Produktkarte produkt={produkt} />

// nur das, was die Karte anzeigt
<Produktkarte name={produkt.name} preis={produkt.preis} bild={produkt.bild.url} />

HTML

Große <style>- und <script>-Blöcke gehören in eigene Dateien. Die lädt der Browser einmal und nimmt sie beim nächsten Seitenaufruf aus dem Cache. Wiederholte Icons legst du einmal als SVG-Symbol ab und verweist mit <use> darauf.

html
<!-- einmal pro Seite -->
<svg hidden>
  <symbol id="icon-telefon" viewBox="0 0 24 24"><path d="..."/></symbol>
</svg>

<!-- überall, wo das Icon gebraucht wird -->
<svg width="20" height="20" aria-hidden="true"><use href="#icon-telefon"/></svg>

So prüft checkfrei

Wir messen das unkomprimierte HTML. Unter 200 KB ist gut, bis 500 KB gibt es eine Warnung, darüber einen Fehler.

Gewicht 1 von 3 im Bereich Ladezeit.

Häufige Fragen

Wie groß darf eine HTML-Seite sein?

Unkomprimiert sind bis 200 KB unproblematisch, das reicht auch für lange Artikel. Zwischen 200 und 500 KB lohnt ein Blick, was so viel Platz braucht.

Wirkt sich die HTML-Größe auf das Google-Ranking aus?

Indirekt. Google bewertet die Ladezeit, etwa über den LCP, und ein großes Dokument macht sie langsamer. Eine feste Größe, ab der Google schlechter rankt, ist nicht bekannt.

Reicht es nicht, das HTML zu komprimieren?

Komprimierung verkleinert die Übertragung, oft auf ein Viertel. Der Browser muss das Dokument danach aber in voller Größe verarbeiten. Richtig ist beides zusammen: schlankes HTML und Komprimierung.

Jetzt deine Seite prüfen

checkfrei prüft HTML-Größe und 68 weitere Punkte in einem Durchgang. Kostenlos und ohne Anmeldung.