Performance-Versprechen oder Performance-Realität?
Mit jedem WordPress-Release schwirren Performance-Versprechen durch die Branche. WP 7.0 ist da keine Ausnahme — überall liest man von zweistelligen Verbesserungen, Lazy-Hydration, Static Critical CSS und einer überarbeiteten Asset-Pipeline. Das klingt gut, sagt aber wenig darüber aus, was Mandantinnen und Mandanten konkret spüren werden. Bei Werbesofa haben wir vor und nach der Migration auf WordPress 7.0 systematisch gemessen, quer durch unser Portfolio. Dieser Beitrag fasst die Zahlen zusammen.
Wichtig vorab: Performance ist immer kontextabhängig. Eine Mandantenseite mit 30 statischen Inhaltsseiten und einem Blog verhält sich anders als ein WooCommerce-Shop mit tausenden Artikeln. Wir haben deswegen drei Kategorien gebildet — kleine Content-Seiten, mittlere Service-Webseiten mit dynamischen Elementen und Shops mit über 500 Artikeln — und für jede Kategorie typische Mandantenwebseiten gemessen.
Die Messmethodik: Lighthouse-Audits mit identischem Throttling-Profil vor und nach dem Update, je drei Durchläufe pro Seite, Median als Reporting-Wert. Server-seitig haben wir TTFB direkt am Nginx-Edge in unserem Falkenstein-Rechenzentrum geloggt. Frontend-Metriken stammen aus Real-User-Monitoring der ersten 30 Tage nach Migration.
LCP — Largest Contentful Paint im Detail
LCP ist die Metrik, die den meisten Mandantinnen und Mandanten als Erstes auffällt: Wann sehen Besucherinnen und Besucher den größten Inhaltsblock einer Seite? Vor WordPress 7.0 lag der Median-LCP über unser Portfolio bei 2,3 Sekunden. Nach der Migration sind es 1,7 Sekunden — eine Verbesserung um 28 Prozent.
Die größten Verbesserungen sehen wir bei Service-Hub-Seiten mit komplexen Layouts. Diese Seiten haben Hero-Bilder, mehrere Sektionen mit Bildern, Custom-Blocks für Trust-Elemente und oft eingebettete Videos. Vor dem Update standen sie häufig vor dem Problem, dass kritisches CSS verspätet kam — der Hero erschien dann nackt und wurde sekundenbruchteilbar nachformatiert. Mit Static Critical CSS in WP 7.0 ist das Geschichte: Der Above-the-Fold-Bereich rendert mit allen Styles sofort.
Bei einfachen Inhaltsseiten ist der LCP-Gewinn kleiner — typisch 12 bis 18 Prozent — weil dort vorher schon wenig auf dem kritischen Pfad lag. Bei Shop-Seiten dagegen liegen wir teils bei 40 Prozent Verbesserung, weil die alten Hydration-Skripte für Produktkarten und Filter-Komponenten enorm viel Hauptthread-Zeit gefressen haben.
INP — Interaction to Next Paint
INP misst, wie reaktionsschnell eine Seite auf Klicks und Eingaben reagiert. Diese Metrik ist seit März 2024 Teil der Core Web Vitals und damit auch SEO-relevant. Hier sehen wir die größten Gewinne durch die React-19-Migration: Median-INP fällt von 245 ms auf 159 ms — minus 35 Prozent.
Was Mandantinnen und Mandanten konkret merken: Filter in Shop-Übersichten reagieren spürbar schneller, Dropdown-Menüs in Navigationen öffnen sich ohne Verzögerung, und das Akkordeon-Block-Element in unseren FAQ-Sektionen klappt sofort auf. Vorher hatte man auf langsameren Geräten teils 300 bis 400 Millisekunden Wartezeit — jetzt sind es konstant unter 200 Millisekunden.
Auch hier ist der Effekt je nach Seitenart unterschiedlich. Interaktive Seiten profitieren am stärksten. Statische Inhalts-Webseiten haben naturgemäß weniger Interaktion, sodass die INP-Werte ohnehin gut waren und nur marginal besser werden.
TTFB und Server-seitige Verbesserungen
TTFB (Time to First Byte) ist nicht direkt eine Core Web Vital, beeinflusst aber alle anderen Metriken. Auf unserer eigenen Hetzner-Infrastruktur in Falkenstein haben wir vor dem Update einen Median-TTFB von 187 ms gemessen — nach dem Update 134 ms. Das ist nicht direkt dem WordPress-Update zuzuschreiben, sondern PHP 8.4 und der überarbeiteten Bootstrap-Phase im Core.
PHP 8.4 mit JIT-Compilation und typed properties bringt WordPress an eine Performance-Grenze, die mit interpretierten Sprachen kaum zu unterbieten ist. Wir haben auf unseren Hetzner-Servern den OPcache aggressiv konfiguriert und über alle Mandantenwebseiten hinweg sehen wir 25 bis 35 Prozent kürzere TTFB-Werte gegenüber dem Vorgänger.
Auch Cron-Last ist gesunken: WordPress 7.0 verwendet adaptive Intervalle für interne Wartungsaufgaben statt fester Pollings. Auf unseren Servern sehen wir 60 Prozent weniger Cron-Jobs pro Stunde — ohne dass irgendetwas Wesentliches schlechter funktioniert.
Editor-Performance: 41 Prozent schneller
Eine Metrik, die meist übersehen wird, aber im Mandantenalltag enorm zählt: Wie schnell öffnet sich der Block-Editor mit einem komplexen Beitrag? Bei uns gibt es regelmäßig Service-Hub-Seiten mit 800 bis 1200 Wörtern, mehreren custom Blocks und eingebetteten Bildergalerien. Vor dem Update brauchte der Editor dort 3 bis 4 Sekunden zum Öffnen. Nach dem Update sind es 1,8 bis 2,4 Sekunden — minus 41 Prozent.
Auch das Wechseln zwischen Beiträgen ist deutlich schneller. Wer in einer Mandantenredaktion fünf Beiträge nacheinander durchgeht, spart pro Tag spürbar Zeit. Über ein Jahr summiert sich das. Wir haben das nicht in Cents umgerechnet, aber bei Mandantinnen und Mandanten, die häufig redaktionell arbeiten, ist die Editor-Performance der größte gefühlte Gewinn der Migration.
Block-Inspektor-Sidebar, Pattern-Browser, Media-Library — alle drei UI-Bereiche, die früher gefühlt langsam waren, fühlen sich jetzt direkt an. Das ist nicht nur eine Zahl auf dem Papier, sondern verändert das Arbeitsgefühl im Backend.
Wo es nicht besser geworden ist
Ehrlichkeit gehört dazu: Es gibt zwei Bereiche, in denen wir keine signifikante Verbesserung sehen. Erstens: Sehr alte Themes mit viel altem CSS profitieren weniger. Wer noch ein Pre-Block-Theme einsetzt, holt das Maximum aus WP 7.0 nicht heraus. Wir empfehlen solchen Mandanten ohnehin einen Theme-Refresh, weil die Sicherheits- und Wartbarkeits-Kosten sonst überwiegen.
Zweitens: Plugins. Schlecht geschriebene Plugins werden durch ein WordPress-Update nicht magisch schneller. Wir haben bei einigen Mandanten Plugins entfernt oder ersetzt, die vorher die meiste Last verursacht haben. Das war Teil unseres Migrations-Audits und hat oft mehr Performance-Effekt gehabt als der Versions-Sprung selbst.
Drittens, eher als Hinweis: Das KI-Subsystem kann Latenz hinzufügen, wenn man es ungebremst nutzt. Wer für jedes Speichern eines Beitrags KI-Vorschläge holt, wartet auf den Anbieter. Wir haben in unseren Setups die KI-Aufrufe asynchron gemacht, sodass das Speichern nicht blockiert wird — empfehlen das auch jedem, der KI im Editor produktiv einsetzt.
Fazit: Performance ist kein Marketing
Die WordPress 7.0 Performance-Versprechen halten. Quer durch unser Portfolio sehen wir Verbesserungen, die spürbar sind — nicht nur in Lighthouse-Scores, sondern auch in dem, was Mandantinnen und Mandanten täglich erleben. Schneller LCP heißt schnellere Wahrnehmung. Niedrigerer INP heißt reaktionsfähigere Bedienung. Kürzere Editor-Ladezeiten heißt produktiveres Arbeiten.
Wir bleiben bei unserem Ansatz, Performance nicht als einmalige Maßnahme zu behandeln. Mit jeder Mandantenwebseite, die wir betreuen, läuft monatlich ein Performance-Audit, und wir handeln nach. Mit WordPress 7.0 ist die Basis-Ausgangslage besser geworden — die Arbeit am Detail bleibt.
Wer wissen möchte, wie die eigene Webseite vor und nach WP 7.0 abschneidet, kann uns gerne ein Erstgespräch anfragen. Wir messen die Seite, vergleichen mit Branchenbenchmarks und schlagen konkrete Maßnahmen vor — wenn welche nötig sind.
Branchenvergleich: wo Werbesofa-Mandanten heute stehen
Performance-Zahlen sind nur dann aussagekräftig, wenn man sie ins Verhältnis setzt. Wir vergleichen unsere Mandantenwerte regelmäßig mit Branchen-Benchmarks aus dem Chrome User Experience Report (CrUX). Über alle Werbesofa-Mandanten hinweg liegen wir nach der WP-7.0-Migration im oberen Quartil deutscher Mittelstands-Webseiten. Das war vorher auch schon der Fall, aber der Abstand zur Median-Performance ist deutlich größer geworden.
Konkret: Während der Median deutscher Unternehmenswebsites einen LCP-Wert von 2,8 Sekunden hat, liegen Werbesofa-Mandantenseiten bei 1,7 Sekunden. INP-Median branchenweit: 280 ms; unsere Mandanten: 159 ms. TTFB branchenweit: 320 ms; unsere Mandanten: 134 ms. Diese Differenz zahlt sich in mehreren Dimensionen aus — SEO-Rankings, Conversion-Rates, Bounce-Rate. Schnelle Webseiten sind nicht nur ein Hygiene-Faktor, sondern messbar besser im Geschäftserfolg.
Wichtig zu betonen: Diese Performance-Werte sind kein Zufall und keine reine Folge des WordPress-Updates. Sie sind das Ergebnis kontinuierlicher Arbeit an Hosting, Caching, Asset-Pipeline und Block-Architektur über mehrere Jahre. WordPress 7.0 verstärkt diese Arbeit, ersetzt sie aber nicht.
Auch interessant: Während der Median deutscher Online-Shops im CrUX-Report eine Mobile-LCP-Performance von über 3,2 Sekunden zeigt, kommen die Werbesofa-WooCommerce-Mandanten auf 1,9 Sekunden. Mobile ist beim Shopping besonders relevant — die meisten Conversions passieren auf Smartphones, und jede Sekunde Wartezeit kostet messbar Umsatz. Hier zeigt sich die Investition in moderne Performance-Architektur am deutlichsten.
Häufige Fragen zur Performance nach der Migration
Wie messe ich, ob mein WordPress 7.0 Update Performance gebracht hat? Wir empfehlen, vor und nach der Migration jeweils einen Lighthouse-Audit der wichtigsten Seiten zu fahren. Lighthouse läuft in jedem Chrome-Browser über die DevTools. Wer ein professionelles Setup will, kann WebPageTest oder PageSpeed Insights nutzen — die letzteren liefern Daten aus realen Nutzer-Messungen (CrUX), nicht nur synthetische Werte. Wichtig: Immer im gleichen Netzwerk und mit gleichem Throttling messen, sonst sind die Werte nicht vergleichbar.
Wie lange dauert es, bis sich Performance-Verbesserungen im SEO niederschlagen? Core Web Vitals fließen in Google Rankings ein, aber nicht sofort. CrUX aggregiert Daten über 28 Tage rolling Window. Das heißt: Wer heute migriert, hat in etwa 4 Wochen einen vollständig aktualisierten CrUX-Wert, und Google verarbeitet diesen wenige Tage später. Praktisch sehen wir SEO-Effekte nach 4 bis 8 Wochen.
Was ist mit alten Mandantenwebseiten, die nicht Block-Themes nutzen? Solche Sites profitieren weniger stark vom WP-7.0-Update. Wer ein Pre-Block-Theme hat (PHP-Templates, klassische Theme-Struktur), bekommt Performance-Verbesserungen aus PHP 8.4 und der überarbeiteten Asset-Pipeline — aber nicht aus Lazy-Hydration oder Block-SSR. Wir empfehlen solchen Mandanten einen Theme-Refresh innerhalb der nächsten 6 bis 12 Monate, weil sonst der Abstand zum Markt zu groß wird.
Ein letzter Hinweis zur Performance-Messung: Wer regelmäßig misst, sieht Trends statt Momentaufnahmen. Wir empfehlen monatliche Lighthouse-Audits auf den wichtigsten Mandanten-Seiten und automatisierte Web Vitals-Tracking über die eigene Webseite via PerformanceObserver-API. So sehen wir Performance-Regressionen direkt, etwa wenn ein neuer Inhaltsblock mit zu großen Bildern angelegt wird. Bei Werbesofa-Wartungsmandanten ist dieses Monitoring eingebaut und liefert quartalsweise eine Übersicht der wichtigsten Performance-Metriken über die Zeit.
