Die mittlere mobile Startseite wog 2025 rund 2.559 Kilobyte. Davon entfielen 911 Kilobyte auf Bilder, 632 auf JavaScript, 122 auf Schriften – und 22 auf HTML. Das ist weniger als ein Prozent. Wer optimieren will, schaut sich diese Zahl an und wendet sich einem anderen Thema zu.
Das ist nachvollziehbar. Und es übersieht den entscheidenden Unterschied.
Die einzige Datei ohne Cache
Bilder, Stylesheets und Skripte liegen nach dem ersten Besuch im Browser-Cache. Beim zweiten Seitenaufruf werden sie nicht erneut übertragen. Die 632 Kilobyte JavaScript kosten Bandbreite genau einmal pro Besucher und Cache-Laufzeit.
Das HTML-Dokument nicht. Es wird bei den meisten Websites dynamisch erzeugt oder nur sehr kurz zwischengespeichert und geht deshalb bei praktisch jedem Aufruf neu über die Leitung. Jede einzelne Seite, jeder einzelne Besuch, jeder Crawler-Durchlauf.
Bei einer Million Seitenaufrufen im Jahr sind 22 Kilobyte rund 22 Gigabyte übertragene Daten – nur für das Markup. Zwei Kilobyte weniger pro Dokument sind zwei Gigabyte weniger. Kein spektakulärer Wert, aber einer, der ohne weiteres Zutun jedes Jahr wiederkehrt.
Dazu kommt die zweite Rechnung, die keine Bytes hat: Jedes Tag wird zu einem Knoten im DOM, den der Browser aufbauen, stylen und layouten muss. Der Median liegt bei knapp 600 Elementen pro Seite, und rund ein Viertel davon sind reine div-Container ohne jede Bedeutung. Das ist Arbeit für den Prozessor, nicht nur Last für die Leitung.
Das Werkzeug
Jens Oliver Meiert pflegt mit HTML Minifier Next den offiziellen Nachfolger des lange etablierten HTML Minifier. Das Werkzeug entfernt Leerraum, Kommentare, optionale Tags und redundante Attribute und kann eingebettetes CSS, JavaScript und SVG gleich mitverkleinern. Es läuft als Schritt im Build-Prozess, nicht im Browser des Besuchers.
In der aktuellen Version bringt es ein JSON-Schema für die Konfigurationsdatei mit, was Autovervollständigung im Editor ermöglicht, erkennt die Konfigurationsdatei im Projektverzeichnis automatisch und zeigt auf Wunsch an, wie gut die interne Zwischenspeicherung greift. Alles Kleinigkeiten, die aber genau das tun, was so ein Werkzeug tun soll: den Aufwand für den Anwender gegen null senken.
Der größere Hebel liegt im Template
Minifizieren beseitigt Leerzeichen. Es beseitigt nicht die Ursache.
Die meisten aufgeblähten Dokumente entstehen nicht durch Nachlässigkeit beim Schreiben, sondern durch verschachtelte Wrapper aus Baukästen, Plugins und Komponentenbibliotheken. Ein Container im Container im Container, jeder mit einer generierten Klasse. Genau deshalb ist HTML aber auch der dankbarste Ort zum Aufräumen: Du korrigierst ein Template und die Änderung wirkt auf jede Seite, die damit erzeugt wird. Bei Bildern musst Du jedes einzeln anfassen.
Bei einem Neubau ist die Sache noch einfacher. Semantisches HTML5 ersetzt drei verschachtelte Container durch ein article, ein nav oder ein section. Das ist kürzer, es ist barrierefrei ohne Zusatzattribute, und es beschreibt, was der Inhalt ist statt wie er aussieht.
Und es hat einen Nebeneffekt, der 2026 wichtiger geworden ist: KI-Crawler führen kein JavaScript aus. Was nicht im ausgelieferten HTML steht, existiert für sie nicht. Sauberes, semantisch ausgezeichnetes Markup ist damit nicht mehr nur eine Frage der Sorgfalt, sondern eine Frage der Sichtbarkeit.
div stehen zwischen body und dem ersten echten Inhalt? Und liefert Dein Server das Dokument komprimiert aus? Das steht im Antwort-Header unter content-encoding – zu sehen in den Entwicklerwerkzeugen im Reiter „Netzwerk“, beim ersten Eintrag der Liste.Der Web Almanac fasst es in einem Satz zusammen, der über HTML weit hinausreicht: Der einfachste Weg, Seitengewicht zu senken, ist, die Bytes gar nicht erst zu verschicken.
Ein Minifier komprimiert, was Du geschrieben hast. Semantisches Markup sorgt dafür, dass es weniger zu komprimieren gibt.
Quellen: Jens Oliver Meiert über HTML Minifier Next · Web Almanac 2025, Kapitel Page Weight · Web Almanac 2024, Kapitel Markup