13 Kilobyte: was ein WordPress-Theme wirklich wiegen muss

Bei Ladezeit-Versprechen lohnt sich die Frage, was genau gemessen wurde. „Unter einer Sekunde“ hängt am Server und am Messort. Ein Lighthouse-Wert hängt am Inhalt der Testseite. Was dagegen fest zum Theme gehört und sich nicht wegdiskutieren lässt, ist die Menge an CSS und JavaScript, die es auf jede Seite legt. Genau die haben wir gemessen.

Die Zahlen

Gemessen am 6. September 2026 im ausgelieferten Paket von Hafen 1.0.0, also in dem Stand, der vom 4. bis zum 22. September im offiziellen Theme-Verzeichnis lag. Genau zwei Dateien braucht der Browser für die Darstellung, beide vom eigenen Server:

Über die Leitung gehen also 9.533 Bytes in zwei Requests. gzip ist dabei die vorsichtige Zahl, weil sie jeder Hoster liefert; der Brotli-Wert daneben ist mit voller Kompressionsstufe gemessen, dynamisch komprimierende Server bleiben im Alltag etwas darüber. Damit du auf dieselben Zahlen kommst: gemessen am Paket hafen-1.0.0.zip mit node:zlib, gzip in der Standardstufe 6, Brotli auf Stufe 11. Andere Werkzeuge weichen um ein paar Byte ab, wir haben bei derselben Datei je nach Programm 9.522 bis 9.555 Bytes gemessen. Auf die Aussage wirkt sich das nicht aus, auf einen Zahlenvergleich schon, deshalb steht das Werkzeug hier dabei. Eine dritte Datei taucht in der Tabelle bewusst nicht auf: Aus der theme.json erzeugt WordPress die globalen Stile und schreibt sie in den Seitenkopf. Das steht dann im Übertragungswert des HTML-Dokuments und kostet keinen eigenen Request.

Was seit 0.8.1 dazugekommen ist

Bis 1.0.0 gut zwei Kilobyte mehr über die Leitung, mit 1.1.0 noch einmal knapp dreieinhalb: Wer die alte Zahl im Kopf hat, darf fragen, wofür. Dieselbe Messung über die Versionsreihe, jeweils style.css und hafen.js zusammen, aus den ausgelieferten Paketen:

Bis 1.0.0 lag der größte Sprung zwischen 0.8.0 und 0.9.1, und dort steckt kein neues Feature-Paket, sondern der Rückfluss aus einer echten Umstellung: Magazin-Raster für die Blogübersicht, eine gestaltete Rückfallebene für Beiträge ohne Bild, tippfreundliche Ziele in der Seitennummerierung. Der Sprung von fünf auf 37 Looks kostete dagegen nur 1.218 Bytes CSS, weil ein Look eine JSON-Datei ist und keine zusätzliche Zeile Stylesheet.

Und eine Zahl hat sich lange überhaupt nicht bewegt: hafen.js lag von 0.8.0 bis 1.0.0 unverändert bei 1.948 Bytes, quer durch alle Looks und alle Releases. Das ist kein Zufall, sondern die Grenze, die wir uns gesetzt haben. Was CSS kann, bekommt kein JavaScript. Mit 1.1.0 ist die Datei zum ersten Mal gewachsen, auf 3.344 Bytes: Der Seitenkopf läuft jetzt beim Scrollen mit, und das Skript misst seine Höhe, damit ein Sprung zu einer Überschrift nicht unter ihm landet. Das kann CSS allein nicht.

Die Schrift ist die Ausnahme, nicht die Regel

Der Standard-Look, also die Voreinstellung aus der theme.json, bringt Inter als eine einzige variable Schriftdatei mit, 48.256 Bytes für alle Schriftstärken von 100 bis 900. Mit Hafen 1.1.0 liegt der gesamte Theme-Anteil einer Seite in diesem einen Fall bei 61.243 Bytes. Das ist der ganze Betrag, es kommt nichts von außen dazu: kein Google Fonts, kein Icon-Font, kein CDN.

Sobald du im Website-Editor unter Stile einen der 38 Looks auswählst, fällt die Schriftdatei weg. Jede der 38 Varianten ersetzt die Inter-Vorgabe durch einen Systemschrift-Stapel, ohne eigenes fontFace, und das Theme bemerkt das von selbst: Der Vorlade-Hinweis im Seitenkopf schaltet sich in diesem Fall ab, statt 48 Kilobyte für eine Schrift anzufordern, die nirgends verwendet wird. Übrig bleiben bei Hafen 1.1.0 die 12.987 Bytes für CSS und JavaScript. Welche 38 Looks das sind und wie sie sich über Farbe, Typografie, Form und Dichte unterscheiden, steht in Hafen 1.0: ein Theme, 38 Looks, null Schriftdateien.

Wer die Farben des Standards behalten und nur die Schrift loswerden will, nimmt die Variante Stapellauf. Sie ändert nichts außer der Typografie: Segoe UI unter Windows, San Francisco auf Apple-Geräten, Roboto unter Android. Die anderen 37 Looks bringen zusätzlich eine eigene Farbpalette und eigene Eckenradien mit, laden aber ebenfalls keine Schriftdatei.

Woher das Gewicht sonst kommt

Zum Vergleich lohnt der Blick darauf, was ein übliches Theme mitbringt, ohne dass jemand etwas Verkehrtes getan hätte. Ein Page-Builder-Theme lädt sein eigenes Framework, dazu ein Icon-Set, oft jQuery und eine Slider-Bibliothek, meist auf jeder Seite, unabhängig davon, ob die Seite einen Slider enthält. Der teure Teil ist dabei nicht einmal die Größe, sondern die Zeit, die der Browser mit dem Ausführen verbringt.

Eine gemessene Zahl dazu haben wir, allerdings nicht von einem Page-Builder, sondern von Neve, einem Theme, das zu Recht als eines der schnelleren klassischen gilt. Beim Umzug einer gewachsenen Produktionsseite auf Hafen, gleicher Tag, gleiche Methode, unveränderter Plugin-Bestand, fiel das JavaScript der mobilen Startseite von 621 auf 382 Kilobyte und der First Contentful Paint von 3,9 auf 1,3 Sekunden. Die Differenz von 239 Kilobyte stammt aus der Theme-Ebene allein, an den Plugins wurde nichts angefasst. Die komplette Messreihe über vier Seitentypen steht in unserer Fallstudie zum Theme-Wechsel. Für ein Page-Builder-Theme haben wir keine eigene Messreihe, deshalb steht hier auch keine Zahl dafür.

Hafen kommt aus einer anderen Richtung. Layout, Farben, Abstände und Typografie stehen vollständig in der theme.json, WordPress erzeugt daraus selbst das nötige CSS. Es gibt kein Framework, weil es keins gibt, das die Blockverwaltung nicht schon mitbrächte. Und es gibt kein JavaScript für Dinge, die CSS kann; die 3.344 Bytes im Paket von Hafen 1.1.0 erledigen den klebrigen Header samt Messung seiner Höhe für Sprungmarken und das sanfte Einblenden beim Scrollen, mehr nicht. Zwei Filter im Theme sorgen zusätzlich dafür, dass WordPress nur das Block-CSS lädt, das auf der Seite tatsächlich vorkommt, statt der kompletten Blockbibliothek.

Alles, was keine Darstellung ist, steckt bewusst nicht im Theme, sondern im Begleit-Plugin Hafen Core: strukturierte Daten, llms.txt, Antwortblöcke. Das ist keine Marotte, sondern eine Regel des Verzeichnisses, denn Funktionen müssen einen Theme-Wechsel überleben. Was diese Trennung im Zulassungsverfahren bedeutet hat, steht im Bericht über den Weg ins offizielle WordPress-Verzeichnis.

Und jetzt der ehrliche Teil

Ein leichtes Theme macht keine langsame Website schnell. Es entfernt nur eine von mehreren Ursachen, und meistens nicht die größte.

In der Praxis dominieren drei andere Posten. Bilder, wenn sie in voller Kameraauflösung hochgeladen und per CSS kleingerechnet werden; ein einziges solches Bild wiegt mehr als das ganze Theme. Plugins, die ihre Skripte auf jeder Seite laden statt dort, wo sie gebraucht werden. Und das Hosting, denn keine Optimierung im Frontend hilft gegen eine Serverantwort, die eine Sekunde auf sich warten lässt.

Wer eine bestehende Seite schneller machen will, fängt deshalb nicht beim Theme an. Der Weg dahin steht in unserem Beitrag WordPress langsam? In 10 Schritten wieder schnell, und der ist unabhängig davon, welches Theme läuft. Dieser Beitrag hier beantwortet die andere Frage: was ein Theme beiträgt, wenn man neu anfängt oder wechselt.

Häufige Fragen