PageSpeed 97 von 100, aber Core Web Vitals nicht bestanden: Was steckt dahinter?

97 von 100 Punkten für die Performance. Grüner Kreis. SEO: 100. CLS: perfekt. Auf den ersten Blick sieht alles bestens aus. Das Problem: Echte Besucher warten auf derselben Website mehr als vier Sekunden, bis der wichtigste Inhalt erscheint. Google meldet trotzdem: Core Web Vitals nicht bestanden. Wie kann beides gleichzeitig stimmen?

Das ist kein ausgedachtes Beispiel. Es geht um eine echte WordPress-Website mit OceanWP und Elementor, die als individuelles Projekt für rund 400 Euro verkauft wurde. An ihr lässt sich hervorragend zeigen, warum ein grüner Score bei PageSpeed Insights noch lange nicht beweist, dass eine Website wirklich schnell ist. Genau das möchte ich heute erklären.

97 Punkte – also schnell?

Nicht unbedingt. Genauer gesagt: Aus 97 Punkten allein lässt sich das gar nicht seriös beurteilen. PageSpeed Insights stellt zwei grundverschiedene Arten von Daten nebeneinander. Die eine stammt aus einem Lighthouse-Labortest, der zu einem bestimmten Zeitpunkt unter festgelegten Bedingungen stattfindet. Daher kommt der beeindruckende grüne Kreis mit 97 von 100 Punkten.

Die anderen Daten stammen aus dem Chrome User Experience Report (CrUX), also von echten Chrome-Nutzern aus den vergangenen 28 Tagen. Und sie erzählen hier eine ganz andere Geschichte. Der Largest Contentful Paint (LCP) – die Zeit, bis das größte sichtbare Inhaltselement erscheint – liegt bei 4,4 Sekunden. Der First Contentful Paint (FCP) beträgt 4 Sekunden, die Time to First Byte (TTFB) sogar 3,9 Sekunden. Gleichzeitig ist der Interaction to Next Paint (INP) mit 97 ms sehr gut, und der Cumulative Layout Shift (CLS) liegt bei 0.

Core Web Vitals gelten erst dann als bestanden, wenn alle drei Kernmetriken beim 75. Perzentil im guten Bereich liegen. Hier sind INP und CLS gut, der LCP liegt aber über 4 Sekunden und fällt damit in Googles Kategorie „schlecht“. Diese Kombination sagt sehr viel mehr aus als die grüne 97 allein.

Ein wichtiger Hinweis: Websites mit wenig oder unregelmäßigem Traffic haben möglicherweise keine CrUX-Daten. Das heißt allerdings nicht, dass sie von solchen Problemen verschont bleiben.

Der Browser wartet fast vier Sekunden auf eine Antwort

Die interessanteste Zahl in diesem Bericht ist für mich nicht einmal der LCP-Wert, sondern die TTFB von 3,9 Sekunden. Vereinfacht gesagt misst Time to First Byte, wie lange es vom Absenden einer Anfrage dauert, bis die ersten Bytes der Serverantwort beim Browser ankommen.

Wenn der erste Inhalt erst nach rund vier Sekunden sichtbar wird und die Serverantwort erst nach etwa 3,9 Sekunden eintrifft, liegt die Verzögerung nicht daran, dass der Browser vier Sekunden lang mühsam Elementor-Sektionen, Bilder und Buttons zusammensetzt. Den größten Teil der Zeit wartet er schlicht darauf, überhaupt eine Antwort zu bekommen. Erst danach kann er die Seite tatsächlich rendern.

Das ist wichtig, weil bei einer langsamen WordPress-Seite mit Elementor schnell der Reflex kommt: „Na klar, der Page-Builder.“ Nur deuten die Zahlen in diesem Fall gerade nicht darauf hin, dass das Frontend die Hauptursache ist. Eher im Gegenteil: Sobald die Antwort eintrifft, erscheint der erste Inhalt beinahe sofort. Bis zum LCP vergehen dann nur noch ungefähr eine halbe Sekunde.

Liegt es am Hosting? Nicht unbedingt

Bei einer hohen TTFB lautet die Diagnose oft vorschnell: schlechtes Hosting. Manchmal stimmt das. Bei WordPress ist es aber nur eine von vielen möglichen Ursachen. Bis der Server fertiges HTML an den Browser senden kann, hat WordPress unter Umständen schon eine Menge Arbeit zu erledigen.

PHP wird ausgeführt, WordPress lädt samt Theme und aktiven Plugins, Datenbankabfragen laufen, Optionen werden eingelesen und der Seiteninhalt wird zusammengestellt. Manche Plugins fragen zusätzlich externe Dienste ab. Hakt es an einer dieser Stellen, kann die Antwort um Sekunden verzögert werden, obwohl die Serverhardware an sich gar nicht besonders langsam ist.

Ein naheliegender Verdächtiger ist beispielsweise die Datenbank. Ist sie überladen, enthält sie große Mengen automatisch geladener Daten oder verursacht ein Plugin bei jedem Aufruf aufwendige Abfragen, wartet WordPress womöglich lange auf die Informationen, die es für den Seitenaufbau braucht. Für Besucher sieht das immer gleich aus: Klick, nichts. Noch nichts. Immer noch nichts. Und erst Sekunden später erscheint die Seite.

Auch ein unwirksamer Cache, häufige Cache-Misses, ausgelastete PHP-Worker, schlecht programmierte Plugins oder eine externe API, auf deren Antwort WordPress warten muss, können die TTFB in die Höhe treiben. Hosting steht also auf der Liste der Verdächtigen. Aber allein anhand der TTFB lässt sich kein Schuldiger bestimmen.

Wenn die Seite so langsam ist, woher kommen dann die 97 Punkte?

Genau hier wird der Fall spannend. Ein einzelner Lighthouse-Test kann unter völlig anderen Bedingungen stattfinden als ein typischer Besuch auf der Website. Der Test bekommt womöglich eine fertig gecachte Seite, während manche echten Besucher eine frisch generierte Version abrufen. Der CDN-Cache kann bereits gefüllt sein, der Server hat gerade wenig zu tun oder die Seite wurde kurz zuvor erzeugt. All das sind ganz normale Gründe, warum ein Laborwert deutlich besser ausfallen kann als die Werte echter Nutzer.

Es gibt allerdings noch eine weitere Möglichkeit, über die man reden sollte, gerade bei Angeboten, die als „PageSpeed-Optimierung“ verkauft werden. Nicht jede Lösung auf diesem Markt hat vor allem das Ziel, eine Website für ihre Besucher schneller zu machen. Manchmal geht es in erster Linie darum, den Testwert zu erhöhen.

JavaScript lässt sich aggressiv verzögern, Teile des CSS später laden, Skripte zurückstellen, für die erste Darstellung unwichtige Elemente blockieren oder die Seite unter bestimmten Bedingungen anders ausliefern. Viele solche Maßnahmen sind völlig legitim und verbessern die Nutzererfahrung tatsächlich. Fragwürdig wird es, wenn es nur noch darum geht, dem Lighthouse-Bot möglichst wenig zu zeigen, möglichst viel hinauszuschieben und sich so schnell wie möglich den grünen Kreis abzuholen. Das ist ungefähr so, als würdest du einem Auto einen Rennsport-Aufkleber verpassen: Aus 150 km/h werden dadurch keine 300.

In Extremfällen versuchen Optimierungslösungen sogar zu erkennen, ob gerade ein Testtool zugreift, und verhalten sich dann anders. Die Abweichung hier ist jedenfalls groß genug für die Frage: Wurde die Website schneller gemacht – oder vor allem ihr PageSpeed-Ergebnis?

Die zweite Grafik macht es noch deutlicher

Mit nur einem Testergebnis könnte man noch vermuten, dass wir die Website in einem ungewöhnlich guten oder schlechten Moment erwischt haben. Der zweite Screenshot zeigt jedoch, wie sich die Core Web Vitals auf Mobilgeräten über einen längeren Zeitraum entwickelt haben.

Die visuelle Stabilität ist weiterhin gut. Auch die Reaktionsfähigkeit schneidet gut ab, obwohl in der Grafik eine gewisse Verschlechterung zu sehen ist. Die Ladeleistung liegt dagegen über lange Zeit im roten Bereich. Das sieht nicht mehr nach einem einzigen unglücklichen Test an einem schlechten Servertag aus.

Auch das Muster ist ziemlich eindeutig: Beim Laden springt das Layout nicht herum. Sobald die Seite da ist, reagiert sie gut auf Eingaben. Das eigentliche Problem ist die lange Wartezeit, bis überhaupt etwas sichtbar wird. Das ist etwas anderes als eine Website, die überall schwerfällig ist, mit überladenem JavaScript, verrutschendem Layout, riesigen Bildern und trägen Interaktionen. Hier gibt es einen deutlich konkreteren Ansatzpunkt für die Fehlersuche.

„PageSpeed 90+“ ist kein Geschäftsziel

Deshalb sollte das Versprechen „Ich bringe deine Website auf 90+ bei PageSpeed“ zumindest ein kleines Warnsignal auslösen. Ein guter Lighthouse-Wert ist natürlich erfreulich. Ich möchte ihn nach einer gelungenen Optimierung selbst sehen. Problematisch wird es erst, wenn die Zahl zum Selbstzweck wird.

Kein Unternehmen verdient mehr, nur weil Lighthouse seiner Website 97 Punkte gegeben hat. Auf die Website kommt ein Mensch, häufig mit einem ganz normalen Smartphone über eine Mobilfunkverbindung. Wenn nach dem Klick vier Sekunden lang kaum etwas passiert, hilft dem Besucher auch der Screenshot mit dem grünen Kreis nicht, den der Dienstleister bei der Abnahme geschickt hat.

Die Frage „Wie viele Punkte hast du bei PageSpeed?“ ist deshalb viel weniger interessant als „Wie schnell funktioniert die Seite für echte Besucher?“ PageSpeed Insights liefert Daten für beide Fragen. Man muss nur über die große grüne Zahl hinausblicken.

Diesmal ist Elementor nicht allein schuld

Dieser Fall zeigt auch, warum reflexartige Schuldzuweisungen an einzelne Technologien wenig bringen. Elementor kann durchaus schwerfällige Websites erzeugen. Man kann damit Seiten bauen, die mit JavaScript, riesigen Bildern und unnötigen Widgets überladen sind. Das gilt allerdings für fast jeden größeren Page-Builder.

Die vorliegenden Daten reichen aber nicht aus, um den LCP von 4,4 Sekunden einfach Elementor zuzuschreiben. INP ist sehr gut, CLS liegt bei null und sobald die Serverantwort ankommt, erscheint der Inhalt relativ schnell. Die größte Verzögerung entsteht vorher.

Man kann also Elementor entfernen, alles neu bauen und trotzdem eine langsame Website haben, wenn das eigentliche Problem in der Datenbank, bei PHP, im fehlenden Cache oder an einem schlecht funktionierenden Plugin liegt. Erst muss klar sein, wofür diese Sekunden draufgehen. Dann lässt sich entscheiden, was tatsächlich repariert werden muss.

Wie findest du heraus, woran es wirklich liegt?

Als Erstes solltest du Labor- und Felddaten getrennt betrachten und prüfen, ob sie ein ähnliches Bild zeigen. Wenn Lighthouse regelmäßig hervorragende Werte ausgibt, echte Nutzer aber eine sehr hohe TTFB erleben, lohnt sich der Blick auf das WordPress-Backend, den Cache und die Datenbank eher als das endlose Kürzen weiterer CSS-Dateien.

Bei einer solchen Website würde ich messen, wie lange das HTML-Dokument generiert wird, ob der Page-Cache funktioniert, welche Datenbankabfragen laufen, wie groß die Menge der automatisch aus wp_options geladenen Daten ist, wie lange PHP arbeitet und was die aktiven Plugins tun. Außerdem sollte geprüft werden, ob WordPress beim Laden externe Anfragen absetzt, deren Antwort die Seitenausgabe blockiert.

Bleibt zwischen einem normalen Aufruf und dem Lighthouse-Test eine große Lücke, kann man im nächsten Schritt Serverantworten, HTML und geladene Ressourcen vergleichen: Was bekommt ein normaler Browser und was das Testtool? Erst dieser Vergleich ermöglicht eine fundierte Einschätzung, ob die Abweichung durch normale Cache-Effekte und unterschiedliche Messbedingungen entsteht oder ob die Konfiguration vor allem auf einen guten Score ausgerichtet ist.

Der grüne Kreis sieht gut aus. Entscheidend sind die Besucher

PageSpeed Insights lügt nicht. Das Problem entsteht, wenn wir aus einem ganzen Bericht nur die größte, grünste Zahl herausgreifen und sie als Beweis dafür verkaufen, dass die Website schnell ist.

Hier stehen 97 von 100 Punkten bei Lighthouse neben nicht bestandenen Core Web Vitals: Der LCP liegt bei 4,4 Sekunden, die TTFB bei 3,9 Sekunden. Keiner dieser Werte muss falsch sein. Sie messen unterschiedliche Dinge und beruhen auf unterschiedlichen Daten.

Ein guter PageSpeed-Wert sollte daher das Ergebnis einer gut funktionierenden Website sein, nicht das eigentliche Optimierungsziel. Wenn die Seite schnell antwortet, zügig rendert, beim Laden nicht springt und zuverlässig auf Eingaben reagiert, ist der grüne Kreis eine schöne Bestätigung. Geht es bei der Optimierung aber nur darum, diesen Kreis zu bekommen, kann genau das herauskommen, was wir hier sehen: 97 Punkte im Test und Besucher, die trotzdem auf die Seite warten müssen.

WebsiteGarage-Kommentar

97 Punkte machen sich auf einem Screenshot hervorragend und helfen dabei, „Optimierung“ zu verkaufen. Aber Menschen sind keine Screenshots. Wer vier Sekunden darauf wartet, dass WordPress, die Datenbank, ein Plugin oder der Server endlich antwortet, hat vom grünen Lighthouse-Wert herzlich wenig.

Deshalb interessiert mich bei einer Optimierung nicht nur, ob am Ende ein grüner Kreis im Bericht steht. Ich will vor allem verstehen, warum die Website so lange braucht und was passiert, wenn echte Menschen sie benutzen.