Website zu langsam? Core Web Vitals verstehen und verbessern

"Die Seite ist zu langsam" ist selten eine präzise Diagnose. Dahinter steckt meistens eines von drei sehr unterschiedlichen Problemen. Der Hauptinhalt braucht zu lange, bis er sichtbar wird. Ein Klick fühlt sich zäh an. Oder der Inhalt springt beim Laden, sodass man versehentlich auf das Falsche tippt. Genau diese drei Dinge messen die Core Web Vitals.

Was Core Web Vitals wirklich messen

Google beschreibt die Core Web Vitals in der Search-Central-Dokumentation (öffnet in einem neuen Tab) als Kennzahlen für die reale Nutzererfahrung in drei Bereichen: Ladeleistung, Interaktivität und visuelle Stabilität. Ladezeit ist davon nur ein Drittel. Wer beides gleichsetzt, schraubt im Zweifel an der falschen Stelle.

Ein Detail fehlt in den meisten Erklärungen. Maßgeblich ist nicht der Durchschnitt, sondern das 75. Perzentil aller Seitenaufrufe, jeweils getrennt für Mobilgeräte und Desktop und für jede Metrik einzeln. Die Aussage lautet also nicht "meine Seite lädt in 2,5 Sekunden", sondern "bei 75 Prozent der tatsächlichen Aufrufe war der Hauptinhalt nach höchstens 2,5 Sekunden da". Google begründet diese Wahl damit, dass so drei von vier Besuchen mindestens das angestrebte Niveau erlebt haben. Der langsame Aufruf im überlasteten Mobilfunknetz zählt damit mit, statt vom guten Durchschnitt geschluckt zu werden.

Wie verbreitet schlechte Werte sind

Etwas mehr als die Hälfte der mobil abgerufenen Websites besteht die Prüfung also nicht. Der Trend zeigt allerdings nach oben: 36 Prozent im Jahr 2023, 44 Prozent 2024, 48 Prozent 2025. Der Engpass auf Mobilgeräten ist eindeutig der LCP.

Als Zielvorgabe für Ihren Betrieb taugen diese Zahlen nicht, zur groben Einordnung schon. Sie stammen aus dem Chrome UX Report, decken also nur Chrome-Nutzer ab, die der Datenübermittlung zugestimmt haben, und nur Seiten mit ausreichend Besuchern. Deutschlandspezifische Werte weist der Web Almanac nicht aus.

Wo Sie Ihre eigenen Werte ablesen

Zwei kostenlose Werkzeuge reichen aus. Der Core-Web-Vitals-Bericht in der Google Search Console zeigt Felddaten aus echten Besuchen über ein rollierendes Fenster von 28 Tagen, getrennt nach Mobil und Desktop. Er fasst dabei URLs mit ähnlichem Nutzererlebnis zu Gruppen zusammen, weil ähnliche Seitenvorlagen meist dieselbe Ursache teilen. PageSpeed Insights (öffnet in einem neuen Tab) zeigt für eine einzelne Adresse beides nebeneinander: Felddaten aus denselben 28 Tagen und einen Labortest, der eine Seite unter simulierten Bedingungen lädt, laut Dokumentation auf einem Mittelklassegerät im Mobilfunknetz. Gewertet werden am Ende die Felddaten. Der Labortest hilft beim Suchen der Ursache.

Was bei den einzelnen Metriken tatsächlich hilft

LCP: Der Hauptinhalt kommt zu spät

Das LCP-Element ist meist ein großes Bild oder eine Überschrift im ersten Bildschirmbereich. Google zerlegt die Wartezeit in vier Abschnitte: die Antwortzeit des Servers, die Verzögerung bis zum Start des Ladevorgangs, die Ladedauer der Ressource selbst und die Zeit bis zur fertigen Darstellung. Bevor Sie am Bild schrauben, sollten Sie wissen, welcher der vier Abschnitte bei Ihnen der lange ist. Aus der Optimierungsanleitung von web.dev ergeben sich vier Punkte, die fast immer greifen:

• Die LCP-Ressource muss bereits im HTML-Quelltext auffindbar sein, damit der Browser sie früh entdecken kann. Bilder, die erst per JavaScript nachgeladen werden, starten zwangsläufig zu spät.
• Das LCP-Bild niemals mit Lazy Loading versehen. Google formuliert das ohne Einschränkung: Das führt immer zu unnötiger Verzögerung.
• Bei einem Bild, das voraussichtlich das LCP-Element ist, hilft das Attribut fetchpriority="high".
• Ressourcen, die im HTML nicht auffindbar sind, etwa per CSS eingebundene Hintergrundbilder, lassen sich über link rel="preload" vorziehen.

INP: Klicks fühlen sich zäh an

Beim INP geht es nicht um das Laden, sondern um die Zeit zwischen einer Eingabe und der sichtbaren Reaktion. Der Hauptgrund für schlechte Werte sind lange JavaScript-Aufgaben, die den Hauptthread blockieren. Die Empfehlungen von web.dev laufen auf drei Dinge hinaus: Arbeit in Event-Handlern auf ein Minimum reduzieren, längere Aufgaben in kleinere Teile zerlegen und im aktuellen Frame nur das erledigen, was für das sichtbare Update nötig ist. Alles andere kann warten. Ein weiterer Faktor ist die Größe des DOM: Bei sehr umfangreichen Seiten wächst der Renderaufwand mit.

Für typische Unternehmensseiten heißt das meist: weniger Skripte von Dritten. Chat-Widgets, Karten, Tracking und Cookie-Banner konkurrieren um denselben Hauptthread. Ob INP bei Ihnen überhaupt der Engpass ist, steht im Bericht. Weltweit ist INP auf Mobilgeräten die zweitbeste der drei Metriken.

CLS: Der Inhalt springt

CLS ärgert Besucher am unmittelbarsten. Dafür lässt sich kaum eine Metrik einfacher reparieren. Fast alle Sprünge entstehen, weil Platz für etwas nicht reserviert wurde, das später eintrifft. Die Optimierungsanleitung nennt dafür fünf Ansatzpunkte:

• Bei Bildern und Videos immer width und height angeben oder den Platz per CSS mit aspect-ratio reservieren.
• Für später geladene Elemente wie Werbung, Karten oder eingebettete Inhalte den Raum im ursprünglichen Layout freihalten, etwa über min-height.
• Inhalte nicht ohne Zutun des Nutzers nachträglich einfügen. Wenn es sein muss, dann unterhalb des sichtbaren Bereichs.
• Bei Webschriften einen Ersatzzeichensatz mit ähnlichen Maßen wählen. font-display: optional vermeidet den späteren Umbruch, weil die Schrift nur verwendet wird, wenn sie rechtzeitig da ist.
• Animationen über transform lösen statt über top und left, weil letztere das Layout neu berechnen.

Was das für die Sichtbarkeit bei Google bedeutet

Zu diesem Punkt kursiert viel Halbwissen, deshalb hier genau. In der Dokumentation zur Page Experience steht:

Im selben Dokument steht aber ebenso deutlich, dass gute Werte kein Spitzenranking garantieren, dass es kein einzelnes Page-Experience-Signal gibt und dass Google auch dann das relevanteste Ergebnis zeigt, wenn dessen Nutzererlebnis unterdurchschnittlich ist. Zugleich empfiehlt Google ausdrücklich, gute Core Web Vitals anzustreben. Ein Faktor unter vielen also, aber kein Hebel gegen ein Relevanzproblem. Wenn Ihre Seite in der Suche gar nicht auftaucht, liegt die Ursache fast nie bei der Ladezeit. Dafür ist die Prüfreihenfolge bei Sichtbarkeitsproblemen der bessere Einstieg.

Häufige Fragen

Mehr zur technischen Umsetzung: Webdesign & Entwicklung · Mehr zur Sichtbarkeit: SEO-Optimierung · Vorher entscheiden: Baukasten oder Webdesigner?