Google PageSpeed Insights für WordPress: Bericht lesen, Ursachen zuordnen, Punkte abarbeiten

PageSpeed Insights liefert für eine WordPress-Seite dieselbe Oberfläche wie für jede andere Website, aber die Meldungen bedeuten hier etwas sehr Konkretes. Hinter fast jeder Diagnosezeile steht eine bestimmte Schicht der Installation: der Server, das Theme samt Page-Builder, die geladenen Plugins, die Mediathek oder ein Skript, das gar nicht von der eigenen Domain kommt. Wer den Bericht nach dieser Zuordnung liest, arbeitet nicht mehr eine generische Liste ab, sondern entscheidet, wo im System die Ursache sitzt und wer sie beheben kann.

Das ist der Unterschied zwischen einem Bericht, der Arbeit erzeugt, und einem Bericht, der Arbeit sortiert. Dieser Text zeigt, wie der Bericht aufgebaut ist, was der Score tatsächlich gewichtet, welche Meldung auf welche WordPress-Schicht zeigt und in welcher Reihenfolge sich das abarbeiten lässt.

Der Bericht besteht aus zwei getrennten Messungen

Der häufigste Lesefehler passiert im oberen Drittel der Seite. PageSpeed Insights zeigt zwei getrennte Datenquellen an: Felddaten aus dem Chrome User Experience Report (CrUX), also aus echten Nutzerbesuchen, und Labordaten aus einem Lighthouse-Lauf in einer simulierten, gedrosselten Umgebung. Beide beschreiben dieselbe URL, aber nicht dasselbe Ereignis. Sie können sich deshalb widersprechen, ohne dass eine von beiden falsch ist.

Felddaten sind das Urteil der Besucher

Die Felddaten beruhen auf einem rollierenden Zeitfenster der letzten 28 Tage. Das hat eine praktische Folge, die viele WordPress-Betreiber in die Irre führt: Eine Optimierung wird dort erst mit Verzögerung vollständig sichtbar. Wer heute das Caching umstellt und morgen wieder misst, sieht im Feldbereich noch überwiegend die alte Seite, weil die Messwerte der Vorwochen weiter im Fenster liegen. Der Wert bewegt sich langsam, und genau das macht ihn belastbar.

Bewertet wird am 75. Perzentil der Seitenaufrufe, getrennt für Mobil und Desktop. Nicht der Durchschnittsbesucher entscheidet also, sondern das schlechtere Viertel. Für eine WordPress-Seite mit vielen mobilen Zugriffen über schwache Verbindungen heißt das: Der Desktop-Wert kann grün sein, während Mobil rot bleibt. Beide Ansichten sind getrennt zu lesen, und die mobile ist in den meisten Projekten die entscheidende.

Die drei Kennzahlen der Core Web Vitals haben feste Schwellen:

• Largest Contentful Paint (LCP) gilt als gut bei 2,5 Sekunden oder weniger und als schlecht ab 4,0 Sekunden.
• Interaction to Next Paint (INP) gilt als gut bei 200 Millisekunden oder weniger und als schlecht ab 500 Millisekunden.
• Cumulative Layout Shift (CLS) gilt als gut bei 0,1 oder weniger und als schlecht ab 0,25.

Ein wichtiger Hinweis zu älteren Anleitungen: Interaction to Next Paint hat am 12. März 2024 First Input Delay (FID) als Core Web Vital abgelöst. FID wurde zum 9. September 2024 aus den CrUX-Berichten entfernt. WordPress-Ratgeber, die auf FID optimieren, beziehen sich auf eine Kennzahl, die im aktuellen Bericht nicht mehr existiert. Der Unterschied ist nicht kosmetisch: FID maß nur die Verzögerung bis zum Beginn der Reaktion, INP bewertet die gesamte Interaktion bis zum nächsten gezeichneten Bild. Ein träges Menü, ein langsam öffnendes Akkordeon oder ein Formularfeld, das erst nach einem Moment reagiert, fällt jetzt auf.

Fehlen die Felddaten ganz, hat die URL schlicht zu wenig Besuche für eine belastbare Aggregation. Das ist bei einzelnen Unterseiten kleinerer WordPress-Projekte der Normalfall und kein Fehler der Installation. In diesem Fall bleibt nur der Laborteil, und der ist dann als Hinweis zu lesen, nicht als Urteil.

Labordaten sind ein einzelner, reproduzierbarer Testlauf

Der Lighthouse-Teil misst eine simulierte Ladung unter gedrosselten Bedingungen. Sein Vorteil: Er liefert Diagnosen, also Hinweise darauf, welches Element gebremst hat. Sein Nachteil: Er ist ein Einzelereignis. Google bezeichnet den Lighthouse-Score ausdrücklich als schwankend, unter anderem durch A/B-Tests, wechselnde Werbeeinblendungen, Netzwerk- und Client-Hardware-Unterschiede sowie Erweiterungen im Browser. Eine Differenz von wenigen Punkten zwischen zwei Läufen ist deshalb kein Ergebnis, sondern Rauschen.

Die Arbeitsteilung ist damit klar. Die Felddaten sagen, ob ein Problem existiert. Die Labordaten sagen, woran es liegen könnte. Wer nur den Laborwert optimiert, poliert eine Simulation. Wer nur die Felddaten liest, weiß, dass es klemmt, aber nicht wo.

Was der Score wirklich gewichtet

Die große Zahl oben ist kein Mittelwert der Diagnosen, sondern eine gewichtete Summe aus fünf Labormetriken:

• Total Blocking Time (TBT): 30 Prozent
• Largest Contentful Paint (LCP): 25 Prozent
• Cumulative Layout Shift (CLS): 25 Prozent
• First Contentful Paint (FCP): 10 Prozent
• Speed Index: 10 Prozent

Die Färbung ist ebenfalls fest: 0 bis 49 rot, 50 bis 89 orange und 90 bis 100 grün. Ein Sprung von 48 auf 52 ändert also die Farbe, aber kaum die Erfahrung eines Besuchers.

Für WordPress folgt aus der Gewichtung eine unbequeme Einsicht: Total Blocking Time ist der größte Einzelposten und im Kern eine JavaScript-Frage. Eine Installation mit dreißig aktiven Plugins, von denen jedes sein eigenes Skript auf allen Seiten einbindet, verliert den größten Teil des Scores an Hauptthread-Arbeit, nicht an zu große Bilder. Bilder wirken vor allem auf LCP, also auf ein Viertel des Scores. Layoutsprünge, typischerweise durch nachgeladene Schriften, Cookie-Banner und Werbeplätze, kosten ein weiteres Viertel und lassen sich oft mit kleinen Eingriffen beheben. Wer also mit der Bildoptimierung anfängt, weil sie am greifbarsten wirkt, arbeitet an einem Viertel und lässt die dreißig Prozent liegen.

Die Diagnosemeldungen darunter, etwa “Reduce unused JavaScript” oder “Eliminate render-blocking resources”, fließen nicht direkt in den Score ein. Sie erklären ihn. Deshalb ist die Länge der Liste kein Maß für den Handlungsbedarf, und das Abhaken einer optischen Warnung bringt manchmal null Punkte. Umgekehrt kann eine einzige beseitigte Ursache mehrere Meldungen gleichzeitig verschwinden lassen.

Ein wichtiger Kontext: Page Experience inklusive Core Web Vitals ist laut Google ein Ranking-Signal unter vielen. Ein perfekter Score von 100 ist keine Ranking-Voraussetzung. Das Ziel ist der grüne Bereich in den Felddaten, nicht die Höchstpunktzahl im Labor.

Die Zuordnung: Welche Meldung gehört zu welcher WordPress-Schicht

Jede wiederkehrende Diagnose lässt sich einer Zuständigkeit zuordnen. Diese Zuordnung legt fest, wer das Problem lösen kann: der Hoster, das Theme, ein Plugin, die Redaktion oder ein externer Dienst. Sie ist der eigentliche Übersetzungsschritt zwischen Bericht und Aufgabenliste.

Schicht 1: Hosting und TTFB

Die Serverantwortzeit (Time to First Byte, TTFB) ist die Schicht, die alle anderen nach hinten schiebt. Google empfiehlt eine Serverantwortzeit von 0,8 Sekunden oder weniger. Ab 1,8 Sekunden gilt sie als schlecht. Solange eine WordPress-Seite dort im roten Bereich liegt, ist jede Optimierung im Frontend nur eine Verbesserung hinter einer Wartezeit, die bereits vorher entstanden ist.

Typische Ursachen sind ein überbuchtes Shared-Hosting-Paket, ein fehlendes Seiten-Caching, eine alte PHP-Version oder ein aufgeblähter Autoload-Bereich in der Options-Tabelle der Datenbank. Der Prüfweg ist kurz: PHP-Version im Hosting-Panel ansehen, prüfen ob ausgelieferte Seiten überhaupt aus einem Cache kommen, und die Antwortzeit einmal auf einer gecachten und einmal auf einer nicht cachebaren Seite messen, etwa im Warenkorb oder in der Suche. Bleibt die Zeit auch bei aktivem Cache hoch, liegt es an der Umgebung und nicht an der Konfiguration.

Schicht 2: Theme und Page-Builder

Themes und Builder liefern das Gerüst und damit die Dateien, die im Head landen und das Rendering blockieren. Ein Builder, der jedes Layout aus generischen Containern zusammensetzt, bringt oft sein vollständiges Stylesheet mit, auch wenn eine Seite nur Text enthält. Das erzeugt die Meldungen zu ungenutztem CSS und zu render-blockierenden Ressourcen.

In dieser Schicht liegen auch Layoutsprünge: ein Header, der nach dem ersten Frame seine Höhe ändert, oder eine Schrift, die spät geladen wird und den Text neu umbricht. Solche Sprünge wirken sich direkt auf den CLS aus und damit auf ein Viertel des Scores. Weil die Schicht das gesamte Frontend definiert, wirkt jede Korrektur hier auf alle Seiten desselben Templates gleichzeitig. Das ist ihr großer Hebel und zugleich ihr Risiko.

Schicht 3: Plugin-Assets

Die Frage ist hier nie “wie viele Plugins”, sondern “welches Plugin lädt wo”. Ein Formular-Plugin, das seine Skripte auf jeder Seite einbindet, obwohl nur die Kontaktseite ein Formular hat, kostet auf allen anderen Seiten Total Blocking Time. Die Diagnose “Reduce unused JavaScript” nennt in der Regel die konkrete Datei, und der Pfad darin verrät das verantwortliche Verzeichnis.

Die Arbeit besteht aus zwei Schritten. Erstens aufräumen, also Plugins entfernen, deren Funktion das Theme oder der Block-Editor bereits beherrscht. Zweitens bedingt laden, sodass Assets pro Seitentyp aus der Warteschlange genommen werden, statt sie global auszuliefern. Der zweite Schritt braucht eine Prüfung auf einer Staging-Umgebung, denn ein entferntes Skript, das doch gebraucht wird, fällt im Bericht nicht auf, wohl aber dem Besucher.

Schicht 4: Medien

WordPress hat hier viel automatisiert. Seit Version 5.5 setzt der Kern automatisch loading="lazy" für Bilder. Seit Version 5.9 wird das erste Bild im Inhalt vom Lazy Loading ausgenommen, weil es häufig das LCP-Element ist. Wenn dennoch die Meldung “Largest Contentful Paint image was lazily loaded” erscheint, liegt das meist daran, dass das Hero-Bild nicht im Inhalt steht, sondern aus einem Theme-Template oder einem Slider-Widget kommt, das die Kernlogik von WordPress umgeht.

Die übrigen Medienmeldungen betreffen den Redaktionsprozess und nicht die Technik: Bilder vor dem Upload auf die maximale Anzeigebreite bringen, moderne Formate ausliefern und Größenattribute erhalten, statt sie im Editor zu überschreiben. Diese Schicht ist die einzige, in der jeder neue Beitrag den Zustand wieder verschlechtern kann.

Schicht 5: Drittanbieter-Skripte

Alles, was von fremden Domains kommt, lässt sich nicht technisch optimieren, sondern nur strategisch verhandeln. Tag Manager, Analytics, Chat-Widgets und eingebettete Videos laufen auf demselben Hauptthread wie die eigene Seite und zählen damit voll auf die Total Blocking Time ein.

Praktikabel sind drei Wege. Die Bestandsaufnahme klärt, was wirklich gebraucht wird, denn viele Skripte stammen aus abgelaufenen Kampagnen. Die Verzögerung lädt Skripte erst nach der ersten Nutzer-Interaktion. Die Fassade zeigt ein Video zunächst als Vorschaubild und ruft den eigentlichen Dienst erst auf Klick auf. Alle drei sind Entscheidungen über Funktionen, nicht über Code, und gehören deshalb nicht allein in die Technik.

Eine Reihenfolge, die sich aus der Gewichtung ergibt

Aus der Score-Gewichtung und der Schichtzuordnung folgt eine Bearbeitungsreihenfolge, die für die meisten WordPress-Installationen trägt:

1. Serverantwortzeit unter 0,8 Sekunden bringen. Ohne diesen Schritt verschiebt jede weitere Maßnahme nur ihren eigenen Effekt.
2. JavaScript reduzieren. TBT trägt 30 Prozent zum Score bei. Die Hebel liegen bei Plugin-Assets und Drittanbietern.
3. Das LCP-Element beschleunigen. Das wichtigste Bild oder die Hauptüberschrift darf nicht verzögert geladen und nicht hinter blockierendem CSS versteckt sein.
4. Layoutsprünge beseitigen. Ein weiteres Viertel des Scores. Die Lösung sind feste Abmessungen und Schriften mit font-display.
5. Ungenutztes CSS des Themes verkleinern. Wirksam, aber riskanter, weil hier die Darstellung leicht kaputtgeht.

Sinnvoll ist außerdem, jeweils nur eine Änderung pro Durchgang vorzunehmen. Wer Caching, Bildformate und Skript-Verzögerung am selben Tag umstellt, hat danach zwar einen anderen Wert, aber keine Erklärung dafür.

Prüfen, ob die Änderung tatsächlich gewirkt hat

Nach dem Eingriff wird nicht der Gesamt-Score verglichen, sondern die spezifische Kennzahl, auf die der Eingriff zielte. Wer Skripte verzögert hat, sieht auf die Total Blocking Time. Wer das Hero-Bild befreit hat, sieht auf den LCP. Zwei Lighthouse-Läufe unmittelbar nacheinander unterscheiden sich ohnehin, also ist ein einzelner Punktunterschied ohne Aussage.

Belastbar ist die Bewegung der Felddaten, und die braucht Zeit wegen des rollierenden 28-Tage-Fensters. Für die Beobachtung über mehrere URLs hinweg ist der Core-Web-Vitals-Bericht der Search Console der passendere Ort. Er gruppiert URLs nach Status und speist sich aus denselben CrUX-Felddaten wie PageSpeed Insights, aggregiert aber über URL-Gruppen statt über einzelne Adressen. Genau das macht ihn für WordPress nützlich: Seiten, die dasselbe Template nutzen, landen in derselben Gruppe. Wenn eine Vorlage repariert ist, wandert eine ganze Gruppe von Beiträgen gemeinsam aus dem roten Bereich, und das ist der eigentliche Fortschrittsbalken.

Häufige Fragen zum Bericht

Warum zeigt PageSpeed Insights für meine Unterseite keine Felddaten? Die URL hat zu wenig Besuche für eine belastbare Aggregation. Bei einzelnen Beiträgen kleinerer WordPress-Projekte ist das normal. Der Laborteil bleibt nutzbar, liefert aber nur Hinweise auf Ursachen, kein Urteil über die tatsächliche Erfahrung.

Warum bekomme ich bei zwei Messungen kurz hintereinander unterschiedliche Werte? Google nennt den Lighthouse-Score selbst schwankend, unter anderem wegen A/B-Tests, wechselnder Werbeeinblendungen, Netzwerk- und Hardware-Unterschieden sowie Browser-Erweiterungen. Bewerten lässt sich nur ein Trend über mehrere Läufe, nicht die Differenz zwischen zweien.

Warum ist der Mobilwert schlechter als der Desktopwert? Beide werden getrennt am 75. Perzentil bewertet, und die mobile Messung simuliert schwächere Hardware und Verbindung. Ein grüner Desktopwert sagt daher nichts über die mobile Bewertung aus.

Wie lange dauert es, bis eine Optimierung im Bericht ankommt? Im Laborteil sofort, im Feldteil verzögert, weil dort ein rollierendes Fenster der letzten 28 Tage ausgewertet wird. Solange alte Besuche im Fenster liegen, mischen sie sich in den Wert.

Muss ich noch auf First Input Delay achten? Nein. INP hat FID am 12. März 2024 abgelöst, und FID wurde zum 9. September 2024 aus den CrUX-Berichten entfernt. Anleitungen, die FID als Ziel nennen, sind veraltet.

Mein Hero-Bild wird trotz aktueller WordPress-Version verzögert geladen. Woran liegt das? Die Ausnahme seit Version 5.9 greift für das erste Bild im Inhalt. Ein Hero-Bild aus einem Theme-Template, einem Slider oder einem Builder-Widget steht nicht im Inhalt und wird von dieser Logik nicht erfasst.

Drei Fehlschlüsse, die Zeit kosten

“Der Score ist rot, also ist die Seite langsam.” Der Score ist ein Laborwert eines einzelnen Laufs. Ob Besucher tatsächlich warten, steht in den Felddaten am 75. Perzentil.

“Ein Caching-Plugin löst das.” Caching adressiert primär die Serverantwortzeit, also Schicht 1. Auf Total Blocking Time durch Plugin-Skripte, auf Layoutsprünge oder auf ein falsch verzögertes LCP-Bild wirkt es nicht oder nur indirekt.

“Wir brauchen die 100.” Page Experience ist ein Signal unter vielen, und ein perfekter Score ist keine Ranking-Voraussetzung. Der sinnvolle Zielzustand ist eine Installation, deren Felddaten in allen drei Core Web Vitals im grünen Bereich liegen: LCP bei 2,5 Sekunden oder weniger, INP bei 200 Millisekunden oder weniger und CLS bei 0,1 oder weniger. Alles darüber hinaus ist Feinarbeit.