Eine Seite, die sich zäh anfühlt, und eine rote Zahl bei PageSpeed Insights sind zwei verschiedene Befunde: Die Zahl stammt aus einer Simulation. Was Ihre Besucher tatsächlich erleben — und was Google für die Suche heranzieht —, messen andere Werte, und an denen sollten Sie arbeiten.
Was eine Seite bremst, fällt in wenige Gruppen: zu große Bilder, zu viel Code von fremden Servern und ein Server, der langsam antwortet. Einen guten Teil davon beheben Sie selbst.
Zwei Messungen, die man nicht verwechseln sollte
Geben Sie Ihre Adresse bei pagespeed.web.dev ein. Das Ergebnis hat zwei Teile:
- Oben, „So sieht die Leistung auf der Nutzerseite aus“: Felddaten. Sie stammen aus dem Chrome-UX-Bericht (CrUX), also von echten Besuchern mit Chrome, zusammengefasst über die letzten 28 Tage. Darüber steht, ob die Seite die Core Web Vitals-Bewertung bestanden hat.
- Unten, „Leistungsprobleme diagnostizieren“: Labordaten. Das Prüfwerkzeug Lighthouse simuliert einen einzelnen ersten Seitenaufbau auf einem nachgebildeten Mobiltelefon mit gedrosselter 4G-Verbindung. Daraus entstehen die Punktzahl von 0 bis 100 und die Verbesserungsvorschläge.
Die Punktzahl schwankt von Test zu Test, laut Lighthouse-Dokumentation meist wegen der Umstände: Werbung, wechselnde Wege im Netz, Browsererweiterungen, Virenscanner. Google selbst schreibt, es sei womöglich nicht die beste Verwendung Ihrer Zeit, allein aus SEO-Gründen eine perfekte Punktzahl anzustreben.
CrUX erfasst eine Seite erst ab einer Mindestzahl von Besuchern, die Google nicht nennt. Reicht es für die einzelne Adresse nicht, zeigt PageSpeed Insights die Werte der ganzen Website („Ursprung“), und reicht es auch dafür nicht, gar keine. Dann bleibt nur die Labormessung — nehmen Sie sie als Liste von Hinweisen, nicht als Schulnote.
Die drei Werte, die zählen
Google fasst die Nutzererfahrung in drei Messwerten zusammen, den Core Web Vitals. Die Grenzwerte für „gut“:
| Messwert | Was er misst | Gut ist |
|---|---|---|
| Largest Contentful Paint (LCP) | wann das größte sichtbare Element steht — meist das Bild oder der Textblock ganz oben | höchstens 2,5 Sekunden |
| Interaction to Next Paint (INP) | wie schnell die Seite auf Klicks, Tippen und Tastendrücke sichtbar reagiert | höchstens 200 Millisekunden |
| Cumulative Layout Shift (CLS) | wie stark Inhalte beim Laden verrutschen | höchstens 0,1 |
Bewertet wird nicht der Durchschnitt, sondern das 75. Perzentil, getrennt für Mobilgeräte und Computer: Eine Seite besteht, wenn bei jedem der drei Werte mindestens drei von vier Seitenaufrufen den Grenzwert schaffen.
INP hat am 12. März 2024 den früheren Messwert First Input Delay (FID) abgelöst. Anleitungen, die noch FID nennen, sind entsprechend alt. Im Labor klickt niemand, deshalb zeigt Lighthouse dort die Total Blocking Time (TBT) — laut web.dev ein brauchbarer Anhaltspunkt für INP, aber kein Ersatz.
Welche Seitengruppen Ihrer Website die Grenzwerte verfehlen, zeigt der Core Web Vitals-Bericht in der Search Console mit den Stufen „Gut“, „Optimierung erforderlich“ und „Langsam“ — siehe Search Console einrichten.
Was Google über Ladezeit und Ranking sagt
Die Core Web Vitals werden laut Google von seinen Ranking-Systemen genutzt. Dieselbe Dokumentation schränkt aber ein:
- Es gibt kein einzelnes Signal „Seitenerfahrung“. Die Ranking-Systeme betrachten viele Signale.
- Google zeigt die relevantesten Inhalte, auch wenn deren Seitenerfahrung schlechter ist. Bei vielen Suchen gibt es aber reichlich hilfreiche Inhalte, und in solchen Fällen kann eine gute Seitenerfahrung zum Erfolg beitragen.
- Gute Werte in der Search Console oder in anderen Werkzeugen garantieren keine Platzierung ganz oben.
Ladezeit ist also ein Faktor unter vielen: Eine schnelle Seite, die die Frage des Suchenden nicht beantwortet, rückt dadurch nicht nach vorn, und eine langsame mit der besten Antwort fällt nicht automatisch zurück. Der bessere Grund, an der Ladezeit zu arbeiten, sind Ihre Besucher.
Bilder: passend groß, modern, zur richtigen Zeit
Fotos aus Kamera oder Bilddatenbank haben leicht mehrere Megabyte und ein Vielfaches der Pixel, die der Bildschirm braucht. Drei Dinge helfen:
- Passende Größe. Ein Bild, das auf dem Telefon 400 Pixel breit erscheint, braucht auch auf einem scharfen Display keine 4.000 Pixel. Gute Systeme liefern je nach Bildschirm passende Fassungen aus; sonst verkleinern Sie Bilder vor dem Hochladen.
- Moderne Formate. WebP und AVIF komprimieren laut web.dev in der Regel besser als JPEG und PNG, und alle aktuellen Browser zeigen sie an.
- Später laden, was weiter unten steht. Mit dem Attribut
loading="lazy"holt der Browser ein Bild erst, wenn der Besucher in seine Nähe scrollt.
Beim letzten Punkt steckt eine Falle: Manche Werkzeuge setzen loading="lazy" automatisch auf alle Bilder, auch auf das große Bild ganz oben. Das ist aber meist das LCP-Element, und web.dev rät ausdrücklich davon ab, Bilder verzögert zu laden, die beim Aufruf schon sichtbar sind — besonders das LCP-Bild.
Geben Sie Bildern außerdem Breite und Höhe mit (width und height), damit der Browser den Platz freihält. Sonst springt der Text, sobald das Bild eintrifft, und genau das misst CLS.
Code von fremden Servern und zu viele Erweiterungen
Jede eingebundene Webschrift, jede Karte, jedes YouTube-Video, jeder Chat und jedes Tracking-Skript kommt von einem anderen Server. Für jeden neuen Server muss der Browser den Namen auflösen, eine Verbindung aufbauen und sie verschlüsseln — laut web.dev bis zu drei Hin- und Rückwege, im ungünstigen Fall mehr, bevor die erste Datei fließt. Dazu kommt das Gewicht: Viele verbreitete Einbettungen bringen laut web.dev über 100 KB JavaScript mit, manche bis zu 2 MB.
- Erst auf Klick laden. Statt des Videoplayers ein Vorschaubild, das den Player erst beim Klick nachlädt; statt der beweglichen Karte ein Bild mit einem Link zu Google Maps.
- Ausmisten. Das Pixel einer längst beendeten Kampagne, der Chat, den niemand nutzt, das Plugin für einen Effekt auf einer einzigen Unterseite: Was nicht gebraucht wird, fliegt raus.
- Weniger Schriftdateien. Jeder Schriftschnitt ist eine eigene Datei. Ob Schriften vom eigenen Server schneller kommen als von einem fremden Schriftendienst, ist laut web.dev nicht eindeutig — weniger Dateien helfen in jedem Fall.
Dasselbe gilt für Plugins und Baukasten-Apps: Jede Erweiterung kann eigene Skripte auf jeder Seite einbinden, auch wo sie nicht gebraucht werden. PageSpeed Insights zeigt solche Fälle etwa unter „Reduziere nicht verwendetes JavaScript“ und „Drittanbieter“. Wie Sie Erweiterungen aussortieren, steht unter WordPress sicher betreiben.
Der Server und das Zwischenspeichern
Bevor irgendein Bild lädt, muss der Server die Seite selbst ausliefern. Die Zeit bis zum ersten Byte heißt Time to First Byte (TTFB) und steht bei PageSpeed Insights unter den Felddaten. Sie umfasst Weiterleitungen, Namensauflösung, Verbindungsaufbau und die Antwortzeit des Servers. web.dev nennt 0,8 Sekunden oder weniger als guten Wert — ausdrücklich als groben Richtwert, weil TTFB kein Core Web Vital ist. Da der LCP aber erst nach dem ersten Byte kommen kann, ist ein langsamer Server eine Bremse, die keine Bildoptimierung aufholt.
Mögliche Ursachen: ein Hosting-Paket, auf dem sich viele Seiten einen Server teilen; ein Redaktionssystem, das jede Seite bei jedem Aufruf neu zusammensetzt; Ketten von Weiterleitungen, etwa von http:// auf https:// und dann noch auf www. Dagegen hilft Zwischenspeichern:
- Auf dem Server: Ein Seiten-Cache legt fertige Seiten ab, statt sie jedes Mal neu zu bauen. Bei WordPress übernimmt das ein Cache-Plugin oder das Hosting.
- Im Browser: Über den Header
Cache-Controllegt der Server fest, wie lange der Browser Dateien behalten darf. web.dev empfiehlt für Dateien mit Versionskennung im Namen ein Jahr (max-age=31536000), für die HTML-Seite selbstno-cache. Das beschleunigt jeden weiteren Aufruf, nicht den ersten.
Bleibt die TTFB trotz Seiten-Cache dauerhaft hoch, liegt es meist am Hosting. Das beheben Sie nicht mit Einstellungen, sondern mit einem anderen Tarif oder Anbieter.
Was Sie selbst tun können — und wo es endet
Ohne Programmierkenntnisse erreichbar ist das meiste aus den Abschnitten über Bilder und fremde Server. Dazu kommt ein Blick in die Einstellungen von Hosting oder Baukasten: Gibt es Caching und Bildoptimierung, und ist beides eingeschaltet?
Nicht in der Hand haben Sie, wie viel Code ein Theme oder Baukasten ohnehin mitbringt, wie schnell der Server des Anbieters antwortet und wie die Seite technisch aufgebaut ist. Steckt die Bremse im Grundgerüst, hilft kein Feintuning mehr, und es stellt sich die Frage nach einem Neuaufbau. Wie ich Seiten baue, die ohne diesen Ballast auskommen, steht unter Webdesign in Frankfurt.
Stand: 2026-09-29. Die Angaben habe ich zu diesem Zeitpunkt anhand der Dokumentation der jeweiligen Hersteller geprüft. Anbieter ändern Adressen, Bezeichnungen und Menüwege ohne Ankündigung; prüfen Sie im Zweifel die Angaben Ihres Anbieters. Wer an fremden Systemen arbeitet, braucht die Erlaubnis des Betreibers.