Wie viel HTML eine Seite ausliefern sollte: 517 KB, 159 KB und was dazwischen passiert ist

Payload-Diskussionen bleiben meistens abstrakt, weil niemand gern die eigenen Zahlen zeigt. Deshalb fangen wir mit unseren an. Eine unserer meistbesuchten Leistungsseiten lieferte im August 2026 exakt 517 KB HTML aus. Nur 2,45 Prozent davon waren sichtbarer Text, der Rest war Gerüst. Nach dem Entfernen einer einzigen Konfigurationszeile waren es 159 KB, eine Reduktion um 69 Prozent, ohne dass sich am Inhalt, am Design oder an der Funktion etwas geändert hätte.

Dieser Artikel erklärt, wo die 358 KB steckten, was der Fall über typische Fehlerquellen verrät, und leitet daraus ein Budget ab, an dem sich jede Seite messen lassen kann. Warum Payload für KI-Suchsysteme überhaupt zählt und wo deren harte Byte-Grenzen liegen, haben wir separat im Beitrag zu Text-Ratio und Payload in der KI-Suche aufgeschrieben — hier geht es um die Zahlen, die Ursache und die Messung.

Der Fall: 517 KB, davon 358 KB vermeidbar

Die 358 KB bestanden fast vollständig aus einem CSS-Bündel, das zweimal im selben Dokument stand. Unser Framework bietet eine Option, das gesamte Stylesheet direkt in das HTML einzubetten, statt es als separate Datei zu verlinken. Der Gedanke dahinter ist sinnvoll: Wer das CSS im Dokument mitliefert, spart einen zusätzlichen Netzwerkabruf und rendert die erste Ansicht früher.

Bei uns hat diese Option zwei Effekte gehabt, von denen nur der erste beabsichtigt war. Erstens landete das komplette Utility-CSS von rund 185 KB als <style>-Block im Dokument. Zweitens — und das war der eigentliche Schaden — schrieb das Framework dieselbe CSS-Menge zusätzlich noch einmal in den serialisierten Datenstrom, mit dem es die Seite im Browser weiter aufbaut. Dasselbe CSS lag also zweimal im selben Dokument und machte damit rund 370 KB der ausgelieferten Bytes aus.

Das Problem hatte eine zweite Ebene, die im ersten Moment weniger auffällt. Ein eingebettetes Stylesheet ist an das Dokument gebunden und deshalb nicht cachefähig. Bei jedem Klick auf eine interne Seite wurden dieselben 185 KB erneut übertragen. Als separate Datei mit langer Cache-Dauer wird das Stylesheet dagegen einmal geladen und danach bei jeder weiteren Seite aus dem Browser-Cache genommen. Nach der Umstellung sank die übertragene Datenmenge bei internen Klicks um 79 Prozent.

Die letzte Zeile ist die wichtigste. Es wurde kein Wort gestrichen, keine Funktion entfernt und kein Bild verkleinert. Der gesamte Gewinn kam daraus, dass eine Ressource dorthin zurückgelegt wurde, wo sie hingehört: in eine eigene, langfristig gecachte Datei.

Was der Fall verallgemeinert

Grosse HTML-Dokumente entstehen fast nie durch zu viel Text, sondern dadurch, dass eine Ressource an der falschen Stelle liegt. Das ist die eigentliche Lehre aus dem Fall, und sie gilt weit über unser Framework hinaus. Die drei häufigsten Varianten sehen unterschiedlich aus und haben dieselbe Struktur.

Die erste ist Inlining aus Performance-Gründen, wie in unserem Fall. Kritisches CSS im Dokument ist eine bewährte Technik — aber nur für den tatsächlich kritischen Teil, also die Regeln für den ersten sichtbaren Bereich. Wer das gesamte Stylesheet einbettet, tauscht einen eingesparten Abruf gegen dauerhaft doppelte Übertragung bei jedem einzelnen Seitenaufruf.

Die zweite ist serialisierter Zustand. Frameworks, die im Browser weiterarbeiten, schreiben die Daten, mit denen der Server gerendert hat, ein zweites Mal als strukturierten Datenblock ins Dokument, damit der Browser denselben Stand rekonstruieren kann. Bei einer Seite mit Produktlisten, Filtern oder einem grossen Navigationsbaum wird dieser Block schnell grösser als der gesamte redaktionelle Inhalt. Der Fix ist nicht Minifizierung, sondern die Frage, welche dieser Daten im Browser überhaupt gebraucht werden.

Die dritte ist Konfiguration von Drittanbietern. Consent-Manager, Tag-Manager und Chat-Widgets schreiben ihre Einstellungen direkt ins Dokument, oft mit vollständigen Listen aller Anbieter und Zwecke. Diese Blöcke sind auf jeder Seite identisch und deshalb der klassische Kandidat für eine ausgelagerte, cachefähige Datei.

Ein Budget, an dem man sich messen kann

Als Bezugspunkt taugt der Median des Webs, und der ist niedriger, als die meisten vermuten. Der Web Almanac 2025 der HTTP Archive weist für das HTML-Dokument einer medianen Startseite 22 KB auf dem Desktop und 22 KB mobil aus, für Unterseiten 21 beziehungsweise 20 KB. Das Gesamtgewicht einer Seite liegt dabei bei 2'862 KB Desktop und 2'559 KB mobil — die Masse steckt also in Bildern (1'058 KB Desktop) und JavaScript (697 KB Desktop), nicht im Dokument.

Auf dieser Basis lässt sich ein praktikables Budget pro Seitentyp aufstellen. Die Werte sind Erfahrungswerte aus unserer Arbeit, keine offiziellen Schwellen — aber sie sind reproduzierbar, weil sie sich am Median orientieren und den realistischen Zuschlag für Navigation, strukturierte Daten und Meta-Angaben berücksichtigen.

Die Rechnung dahinter ist einfach nachvollziehbar. Ein deutsches Wort belegt mit Leerzeichen und Interpunktion rund 6,4 Zeichen; in UTF-8 sind das etwa 6,5 Byte, weil Umlaute zwei Byte brauchen. 1'700 Wörter ergeben damit rund 11 KB reinen Text. Dazu kommen die Auszeichnung des Textkörpers mit ungefähr dem Zwei- bis Dreifachen, die Navigation, der Footer, die Meta-Angaben und die strukturierten Daten. So landet man bei 50 bis 90 KB — und sieht sofort, dass 400 KB dafür keine Erklärung im Inhalt haben können.

Warum das für die KI-Suche mehr zählt als für Google

Für Google ist ein aufgeblähtes Dokument ein Hygieneproblem, für Systeme, die Seiten lesen statt anzuschauen, ist es ein Extraktionsproblem. Google trennt seit über zwanzig Jahren Hauptinhalt von Navigation, Footer und Bannern; das ist eingespielt und verzeiht viel. Ein Modell, das eine Seite zitieren soll, hat weniger Verarbeitungsschritte dazwischen: Es bekommt Text, der aus HTML herausgelöst wurde, und arbeitet damit weiter.

Diese Extraktion ist Heuristik. Sie orientiert sich an semantischer Auszeichnung, an der Textdichte pro Knoten und an Mustern, die sich über mehrere Seiten desselben Hosts wiederholen. Wenn 98 Prozent eines Dokuments Gerüst sind und der eigentliche Text tief in Layout-Containern steckt, ist die Textdichte im Inhaltsbereich nicht auffällig höher als daneben. Die Extraktion nimmt dann zu viel mit — und die Passage, auf die es ankommt, verwässert — oder zu wenig, und sie wird abgeschnitten.

Der Zusammenhang mit der Text-Ratio ist damit indirekt, aber real. Die Kennzahl selbst ist kein Rankingfaktor, und Google hat das mehrfach klargestellt. Als Diagnose bleibt sie brauchbar: Unsere 2,45 Prozent haben nicht gesagt «diese Seite wird abgestraft», sondern «97,5 Prozent der ausgelieferten Bytes helfen keinem System, das den Inhalt verstehen will». Nach der Umstellung waren es 90,5 Prozent — immer noch viel, aber in einer Grössenordnung, die sich mit Navigation und Auszeichnung erklären lässt. Was darauf aufbaut, ist eine Frage der Struktur, und die haben wir in der zitierfähigen Absatzstruktur beschrieben.

Dazu kommt ein technischer Punkt, der oft übersehen wird: Was nicht im ersten HTML steht, existiert für die meisten KI-Crawler nicht, weil sie kein JavaScript ausführen. Server-seitiges Rendern ist damit keine Performance-Entscheidung mehr, sondern die Voraussetzung dafür, dass der Inhalt überhaupt ankommt. Es macht das Dokument aber auch grösser — womit das Budget von oben erst richtig relevant wird.

Die Prüfung in zwei Minuten

Für den ersten Befund braucht es kein Tool, nur den Browser und einen Texteditor. Der Ablauf hat vier Schritte.

Erstens: Seite aufrufen und den Quelltext anzeigen lassen, nicht das Entwicklerwerkzeug. Der dort dargestellte DOM enthält bereits alle Änderungen durch JavaScript und ist damit nicht das, was ausgeliefert wurde.

Zweitens: Den gesamten Quelltext in eine Datei speichern und deren Grösse ablesen. Das ist die Zahl, die zählt.

Drittens: Den sichtbaren Fliesstext der Seite markieren, in eine zweite Datei kopieren und ebenfalls die Grösse ablesen. Diese durch die erste geteilt ergibt die Text-Ratio.

Viertens: Wenn das Ergebnis unter fünf Prozent liegt, im Quelltext nach den grossen Blöcken suchen. In der Praxis sind es fast immer dieselben drei: ein <style>-Block über 50 KB, ein <script>-Block mit serialisierten Daten, oder die Konfiguration eines Consent-Werkzeugs. Wer diese drei findet, hat die Ursache.

Der Rest ist Priorisierung, und die geht nicht nach Byte, sondern nach Aufwand. Ein falsch platziertes Stylesheet ist eine Konfigurationsänderung. Ein zu grosser Datenblock ist eine Architekturfrage und gehört in die Planung, nicht in einen Sprint zwischendurch. Genau diese Trennung machen wir in einem Website-Audit explizit, und sie ist der Grund, warum wir Payload bei einem Neubau von Anfang an als Budget behandeln statt als Aufräumarbeit am Schluss.

Wo die Grenze des Arguments liegt

Payload-Arbeit gewinnt keine Rankings, sie entfernt nur einen Grund, nicht gefunden zu werden. Diese Einordnung gehört dazu, weil technische Arbeit leicht zum Selbstzweck wird. Eine Seite, die zur Suchanfrage nicht passt, wird auch mit 15 KB HTML nicht zitiert. Und eine Seite, die keine Nachfrage bedient, hat kein Byte-Problem.

Unsere eigene Umstellung ist genau in diesem Rahmen zu lesen. Sie hat 358 KB pro Seitenaufruf gespart und die Datenmenge bei interner Navigation um 79 Prozent reduziert — das ist ein sauberer technischer Gewinn und ein besseres Erlebnis für jeden Besucher auf einer langsamen Verbindung. Sie hat kein Ranking bewegt, und das war auch nicht der Anspruch. Was sie bewirkt hat: Sie hat einen Nachteil beseitigt, der nie in einem Bericht aufgetaucht wäre.

Die vernünftige Reihenfolge lautet deshalb: erst Relevanz und Substanz, dann Struktur, dann Payload. Wer diese Reihenfolge einhält, arbeitet nie an der falschen Stelle — und stellt beim dritten Schritt sicher, dass die ersten beiden auf dem Weg zum Modell nicht verloren gehen. Wie wir dieses Denken in der KI-gestützten Entwicklung verankern und was wir als Web-Agentur dabei standardmässig prüfen, steht auf den jeweiligen Seiten. Für einen ersten Befund reicht der SEO-Check.