Theme-Wechsel in Zahlen: eine echte WordPress-Seite zieht auf Hafen um
Am 1. September 2026 hat flirtuniversity.de das Theme gewechselt, von Neve auf unser Block-Theme Hafen. Vorher und nachher haben wir am selben Tag mit derselben Methode gemessen. Hier stehen alle Zahlen, auch die, die der Wechsel allein nicht verbessert hat.
Werbeversprechen zu Theme-Geschwindigkeit gibt es viele, Messreihen von echten Umstellungen wenige. Deshalb dokumentieren wir hier eine komplette: flirtuniversity.de, eine Flirtschule mit Inhalten aus 17 Jahren, Mitgliederbereich, Consent-Verwaltung, Video-Embeds und allem, was sich auf einer gewachsenen WordPress-Seite eben ansammelt, wechselte am 1. September 2026 von Neve auf Hafen. Kein Laboraufbau, keine frisch aufgesetzte Demo-Seite. Genau deshalb sind die Zahlen konservativ, und genau deshalb sind sie etwas wert.
Die Ausgangslage
Neve ist kein schlechtes Theme, im Gegenteil, es gilt zu Recht als eines der schnelleren klassischen Themes. Die Seite stand damit mobil bei Lighthouse-Scores von 56 bis 59, mit einem First Contentful Paint um die 4 Sekunden. Der Grund liegt nicht in Nachlässigkeit, sondern in der Bauart: Ein klassisches Theme bringt sein eigenes CSS-Framework, eigene Skripte und eigene Einstellungsebenen mit, die auf jeder Seite mitladen, ob gebraucht oder nicht.
Hafen kommt aus der anderen Richtung: ein Block-Theme, bei dem Layout, Farben und Typografie in der theme.json stehen und WordPress selbst das nötige CSS erzeugt. Was das im Paket bedeutet, haben wir im Beitrag über das Theme-Gewicht nachgezählt: zwei Requests, 7 Kilobyte über die Leitung. Die Frage dieser Fallstudie war, was davon auf einer echten, vollgepackten Seite übrig bleibt.
Die Methode, damit die Zahlen nachprüfbar sind
Gemessen wurde mit Lighthouse 13.4.1 im headless Chrome, auf demselben Rechner, am selben Tag: Neve mittags vor der Umstellung, Hafen direkt nach dem Livegang mit frisch geleertem und wieder angewärmtem Cache. Je Seite und Gerätekategorie drei Läufe, gewertet wird der Median jeder Metrik. Vier Seitentypen decken die Seite ab: Startseite, Blogübersicht, ein Artikel und eine Kursseite mit Video-Hero. Das sind Laborwerte, keine Felddaten, aber unter identischen Bedingungen erhoben, und nur darauf kommt es beim Vergleich an.
Was der Theme-Wechsel allein brachte
Mobil, wo es weh tut, sah der reine Wechsel so aus, jeweils Neve gegen Hafen, gleicher Tag, gleicher Plugin-Bestand:
| Seite (mobil) | Score | First Contentful Paint | JavaScript |
|---|---|---|---|
| Startseite | 56 → 71 | 3,9 s → 1,3 s | 621 → 382 KB |
| Blogübersicht | 58 → 76 | 3,8 s → 1,3 s | 599 → 396 KB |
| Artikel | 59 → 77 | 4,1 s → 1,3 s | 638 → 398 KB |
| Kursseite | 57 → 71 | 3,9 s → 1,4 s | 599 → 359 KB |
Dazu kommen 22 bis 38 Prozent weniger Requests, eine halbierte Total Blocking Time auf der Startseite und ein Largest Contentful Paint, der um 29 bis 44 Prozent sank. Die Layoutstabilität blieb bei 0,00. Desktop war unter Neve schon grün und blieb es, bei 23 bis 34 Prozent weniger Seitengewicht.
Die wichtigste Zahl ist der First Contentful Paint: aus rund 4 Sekunden wird auf jeder gemessenen Seite 1,3 Sekunden. Das ist der Moment, in dem Besucher zum ersten Mal etwas sehen statt auf Weiß zu warten, und er hängt fast vollständig daran, wie viel CSS und JavaScript das Theme vor das Rendern schiebt.
Der ehrliche Teil: was der Wechsel nicht gelöst hat
Die verbleibenden rund 360 bis 400 Kilobyte JavaScript stammen fast vollständig aus dem Plugin-Bestand: Mitgliederbereich, Consent-Verwaltung, Statistik, Video-Embeds. Ein Theme-Wechsel räumt diese Ebene nicht auf, er legt nur offen, dass sie das eigentliche Gewicht trägt. Und der Largest Contentful Paint stand mobil auch unter Hafen noch bei 4 bis 6 Sekunden, weil das größte Element auf den wichtigsten Seiten ein Video-Poster ist, das erst per JavaScript nachgeladen wurde. Ein leichtes Theme rettet keine schweren Inhalte, das haben wir an anderer Stelle schon aufgeschrieben, und diese Messung bestätigt es.
Runde 2: was auf dem neuen Theme noch drin war
Deshalb folgte auf den Wechsel eine zweite Runde, diesmal an den Inhalten und am Ladeverhalten, alles Dinge, die erst auf dem aufgeräumten Fundament sauber wirken:
- Poster-Preload für die Video-Heros: Das Vorschaubild des größten Elements wird per preload mit hoher Priorität geladen und sofort als CSS-Hintergrund gezeigt, statt auf das Embed-Skript zu warten.
- Vorgezogener Verbindungsaufbau zu den Analyse-Hosts per preconnect, das spart auf Mobilverbindungen den DNS- und TLS-Handschlag im kritischen Pfad.
- content-visibility für Sektionen unterhalb der Falte: Der Browser rendert erst, was in Sichtweite kommt.
- Skript-Diät: Ein Bewertungs-Widget lädt nur noch auf der Startseite, wo es tatsächlich eingebunden ist, und die Auto-Anzeigen-Skripte eines stillgelegten Werbekontos flogen komplett von der Seite.
Ergebnis auf der Kursseite, dem härtesten Fall mit Video-Hero: Score mobil von 71 auf 86, der Largest Contentful Paint fiel von 5,2 auf 4,0 Sekunden. Der Artikel stieg von 77 auf 86, die Blogübersicht von 76 auf 80, die Startseite hielt ihren Score und legte bei Ladepfad und Gewicht nach. Das JavaScript sank noch einmal deutlich, auf 215 bis 254 Kilobyte je Seite. Über beide Etappen zusammen heißt das: aus mobilen Scores von 56 bis 59 unter Neve wurden 71 bis 86, bei unverändertem Inhalt.
Was davon zurück ins Theme floss
Die Umstellung war für uns beides zugleich, Kundenprojekt und Härtetest am eigenen Produkt. Eine Handvoll Befunde aus der Migration ist direkt in die Theme-Entwicklung gewandert und steckt in Hafen 0.9.0: Die Blogübersicht bekam ein Magazin-Raster mit Aufmacher-Karte, Beiträge ohne Beitragsbild eine gestaltete Rückfallebene, die Seitennummerierung tippfreundliche Ziele. Was vorher auf der Kundenseite per CSS nachgebessert wurde, wird mit dem nächsten Theme-Update Standard für alle, die Hafen installieren. So herum soll Dogfooding funktionieren: Die Fallstudie verbessert das Produkt, nicht nur die eine Seite.
Was du daraus mitnehmen kannst
Wenn du einen Theme-Wechsel erwägst, sind aus dieser Umstellung drei Dinge übertragbar. Erstens: vorher messen, nachher messen, gleiche Methode. Ohne Vorher-Zahlen weißt du hinterher nicht, ob sich der Aufwand gelohnt hat. Zweitens: Der Wechsel verbessert das Fundament, nicht die Inhalte. Schwere Bilder, Video-Embeds und Plugin-Skripte nimmst du mit, sie fallen auf dem schnellen Fundament nur deutlicher auf, und genau dann lohnt sich die zweite Runde. Drittens: Inhalte bleiben, Layouts wandern. Header, Footer und Übersichtsseiten muss man neu denken, die Texte und Bilder selbst bleiben unberührt in der Datenbank. Wie du eine langsame Seite unabhängig vom Theme beschleunigst, steht in unserer Anleitung in zehn Schritten.
Das Theme aus dieser Fallstudie
Hafen ist unser kostenloses Block-Theme im offiziellen WordPress-Verzeichnis: zwei Requests, 7 Kilobyte, keine externen Aufrufe. Die Verbesserungen aus dieser Umstellung sind auf dem Weg ins nächste Update.
Häufige Fragen
Gehen beim Wechsel auf ein Block-Theme Inhalte verloren?
Nein. Beiträge, Seiten und Bilder liegen in der Datenbank und bleiben beim Theme-Wechsel unangetastet. Neu aufgebaut werden muss, was im alten Theme über dessen eigene Einstellungen lief: Header, Footer, Menüzuordnungen und Layout-Vorgaben. In dieser Fallstudie waren das der Footer, die Blogübersicht und eine Handvoll Vorlagenzuweisungen. Die Inhalte selbst wurden nicht angefasst.
Sind die Zahlen auf meine Website übertragbar?
Die Richtung ja, die Höhe nicht automatisch. Der Effekt hängt davon ab, wie viel CSS und JavaScript dein bisheriges Theme lädt und wie schwer dein Plugin-Bestand wiegt. Die gemessene Seite hat einen großen Plugin-Stack behalten, der Vergleich zeigt also den reinen Theme-Effekt. Auf schlankeren Seiten fällt der Sprung größer aus: Bei einem anderen Umzug auf Hafen sank das JavaScript um 97 Prozent.
Warum ist der First Contentful Paint die wichtigste Zahl in dieser Fallstudie?
Weil er misst, wann Besucher zum ersten Mal etwas sehen, und weil er hier fast ausschließlich vom Theme abhängt. Der Largest Contentful Paint hängt auf dieser Seite an großen Video-Postern, also am Inhalt. Der Wechsel von rund 4 Sekunden auf 1,3 Sekunden beim ersten sichtbaren Inhalt ist der Anteil, den das Theme beisteuert, und genau der sollte in einer Theme-Fallstudie im Mittelpunkt stehen.
Reicht ein schnelles Theme, oder muss ich danach trotzdem optimieren?
Das Theme legt das Fundament, mehr nicht. In dieser Fallstudie hat der Wechsel die Scores mobil um 14 bis 18 Punkte gehoben, die zweite Runde auf dem neuen Theme noch einmal messbar nachgelegt, mit Poster-Preload, vorgezogenem Verbindungsaufbau und content-visibility. Bilder, Embeds und Plugins bleiben deine Baustellen, egal wie leicht das Theme ist.
