Core Web Vitals: ohne Entwickler verbessern

Du öffnest die Google Search Console, siehst einen roten Balken und daneben LCP, INP und CLS. Der Bericht spricht scheinbar die Sprache eines Raumschiff-Cockpits, obwohl es um eine gewöhnliche Seite mit deinen Produkten, Fotos und einem “Bestellen”-Button geht. Deine Hand will den Tab schließen, mit einem Gedanken: “Das ist eindeutig etwas für einen Programmierer.” Aber so kompliziert ist nicht alles. Unter diesen drei Abkürzungen gibt es eine Aufgabe, die du oft nicht ohne eine technische Person anfassen solltest, und zwei, bei denen die Ursache häufig in Materialien liegt, die auf die Website geladen wurden: in einem Foto, Banner, Video oder einem Block, für den niemand Platz gelassen hat. Deshalb solltest du zuerst verstehen, welche Unannehmlichkeit der Bericht beschreibt.

Geschwindigkeit braucht es nicht für einen magischen Sprung in der Suche, sondern damit eine Person nicht auf ein Bild wartet, einen Button ohne Reaktion drückt oder Text hinterherjagt, der plötzlich nach unten gerutscht ist.

Largest Contentful Paint (LCP) ist die Zeit, bis das größte sichtbare Element einer Seite auf dem Bildschirm erscheint. Meistens ist das ein großes Produktfoto, ein Titelbild, ein Banner oder eine große Überschrift. Google bewertet einen LCP von 2,5 Sekunden oder weniger als gut.

Stell dir eine Seite einer Konditorei vor. Eine Person kommt aus einer Anzeige auf eine Tortenseite, sieht aber zunächst eine leere helle Fläche, und das Hauptfoto der Torte erscheint verspätet. Formal hat die Website bereits mit dem Laden begonnen, für die Person hat sie aber noch nicht begonnen: Du kamst genau wegen dieses Bildes und des Preises daneben. Das ist ein LCP-Problem. Interaction to Next Paint (INP) ist die Geschwindigkeit, mit der eine Seite sichtbar auf eine Handlung reagiert: auf einen Button-Klick, das Öffnen eines Menüs, die Auswahl einer Produktvariante oder das Ausfüllen eines Feldes. Ein guter INP liegt bei 200 Millisekunden oder weniger. Wenn du auf “In den Warenkorb” klickst und die Oberfläche ohne jede Reaktion einfriert, sieht das nicht wie ein kaputter Button aus, fühlt sich aber genau so an.

Wenn sich die Seite ohne deine Zustimmung bewegt

Cumulative Layout Shift (CLS) ist ein Wert für visuelle Stabilität: Er zeigt, wie stark eine Seite bereits sichtbare Elemente während des Ladens verschiebt. Ein guter CLS liegt bei 0,1 oder weniger. Du hast zum Beispiel den Mauszeiger oder Finger schon auf einem Button, und plötzlich erscheint darüber ein Banner, ein Foto bekommt Höhe und der Button rutscht nach unten. Die Person klickt daneben. Der Prozess hat in diesem Moment ein seltsames Hobby: Er stellt Möbel um, wenn die Gäste schon sitzen.

Google prüft diese Grenzwerte nicht anhand eines hübschen Durchschnittswerts. Sie müssen bei mindestens 75% der Ladevorgänge erfüllt sein, getrennt für Mobilgeräte und Computer. Ein gutes Ergebnis auf deinem Laptop bedeutet daher noch nicht, dass die Seite für Menschen mit einem Telefon und einer langsameren Verbindung gut ist.

Wenn du in einer alten Checkliste FID siehst, verschwende keine Zeit mit der Suche danach. First Input Delay gehört nicht mehr zu den Core Web Vitals: Am 12. März 2024 wurde es durch INP ersetzt. Schau im aktuellen Bericht also gezielt auf LCP, INP und CLS.

Die kurze Antwort: nicht allein. Google verwendet Core Web Vitals in seinen Ranking-Systemen, erklärt aber ausdrücklich, dass es kein einzelnes Signal gibt. Gute Werte garantieren keine Spitzenpositionen, und die Suche versucht, das relevanteste Material zu zeigen, selbst wenn die Nutzungserfahrung einer Seite mittelmäßig ist. Diese Klarstellung ist wichtig, weil sie dich vor zwei schlechten Entscheidungen schützt: zu erwarten, dass das Komprimieren von Fotos eine Seite automatisch über stärkere und hilfreichere Antworten hebt, oder eine unpraktische Website abzutun, weil Text und Produkt angeblich gut genug sind.

Geschwindigkeit ersetzt weder Inhalt noch Preis, ein verständliches Angebot oder Vertrauen in das Unternehmen. Sie nimmt Reibung zwischen einer Person und dem weg, wofür sie gekommen ist. Wenn eine Seite eine Dienstleistung erklärt, aber das erste Bild zu lange lädt, warten manche Menschen einfach nicht auf die Erklärung. Wenn eine Produktkarte springt, kann eine Person versehentlich eine andere Variante anklicken. Das ist bereits ein praktischer Grund, den Bericht zu verstehen, unabhängig von Versprechen über Suchpositionen.

Es ist sinnvoll, die Arbeit an der Geschwindigkeit neben gewöhnlichen technischen Verbesserungen der Website zu halten, statt daraus eine eigene magische Dienstleistung zu machen. Genauso ist sie ein Teil der technischen Seite von SEO, nicht ein Ersatz für die Arbeit daran, ob die Seite die Anfrage einer Person beantwortet.

Öffne in der Google Search Console den Bericht Core Web Vitals. Er zeigt Daten echter Besucher aus dem Chrome User Experience Report, kurz CrUX, der letzten 28 Tage. Dort werden URLs den Gruppen Good, Needs improvement oder Poor zugeordnet. Für LCP sind das jeweils bis 2,5 Sekunden, bis 4 Sekunden und über 4 Sekunden; für INP bis 200 Millisekunden, bis 500 Millisekunden und über 500 Millisekunden; für CLS bis 0,1, bis 0,25 und über 0,25.

Ein wichtiges Detail: Einer Seitengruppe wird der schlechteste ihrer Statuswerte zugeteilt. Wenn eine Gruppe einen normalen LCP, aber einen schlechten CLS hat, wirkt sie problematisch. Das ist kein Urteil über jede einzelne Seite und kein Grund, sofort alles zu ändern. Es ist ein Hinweis, mit welcher Art von Unannehmlichkeit du anfangen solltest.

Ein einmaliger Seitentest kann ein anderes Bild zeigen, und das ist normal. Diese Messung findet hier und jetzt unter konkreten Bedingungen statt. Die Search Console betrachtet, was bei echten Menschen über einen Zeitraum passiert ist. Ein Tool eignet sich, um eine Änderung direkt nach einer Korrektur zu prüfen; das andere zeigt, wie sich die Website im Leben verhielt und nicht nur in einem einzelnen Durchlauf.

Versuche nicht zu beweisen, welches davon “richtig” ist. Stell lieber eine einfache Frage: Sehe ich in der Search Console ein Problem bei echten Besuchern, und kann ich es auf der Seite reproduzieren? Wenn LCP schlecht ist, öffne die Seite auf einem Telefon über mobiles Internet und sieh nach, worauf die Person am längsten wartet. Wenn CLS schlecht ist, lade die Seite mehrmals und beobachte, ob sich Button, Preis, Formular oder Text bewegen.

LCP bedeutet nicht immer, dass der Server oder der Code katastrophal langsam ist. Der Wert besteht aus mehreren Teilen: der Zeit bis zur ersten Antwort der Website, der Verzögerung vor dem Start des benötigten Ressourcen-Downloads, dem Download selbst und dem Rendern des Elements. Ohne Entwickler musst du diese Teile nicht in technische Schubladen sortieren. Es reicht, das Offensichtlichste zu prüfen: Was steht im ersten Bildschirmbereich und wie viel unnötiges Gewicht bringt es mit.

Wenn der Hauptbereich ein großes Bild hat, lade dort nicht die größte Datei hoch, die du in einem Ordner findest. Bereite eine Version für die tatsächliche Größe im Design vor, komprimiere sie und nutze, wenn dein Content-Management-System es unterstützt, ein modernes Format wie WebP oder AVIF. Es geht nicht um den Namen des Formats: Eine Person soll keine zusätzlichen Daten laden, die auf ihrem Bildschirm nicht einmal sichtbar sind.

Was zuerst erscheinen sollte

Das Hauptbild im ersten Bildschirmbereich solltest du nicht per lazy-load verzögern: Der Browser wartet mit dem Laden, obwohl die Person genau dieses Bild sofort sehen wollte.

Stellen wir uns eine Website einer Möbelwerkstatt vor. Im ersten Bildschirmbereich steht ein großes Küchenfoto, das der Inhaber direkt aus der Kamera hochgeladen hat, weil es so “hochwertiger” sei. Statt die ganze Website zu ändern, bereitet er eine komprimierte Version des Fotos für diese Stelle vor, bewahrt das Original in seinem Archiv auf und prüft, dass das erste Bild kein lazy-load mehr hat. Das ist eine konkrete Änderung, die du über die Mediathek oder den Seiteneditor machen kannst, wenn sie Zugriff auf diese Felder geben. Für Fotos weiter unten auf der Seite kann verzögertes Laden passend sein, aber nicht für das erste große Bild.

Wenn du keinen Zugriff auf Format, Komprimierung oder lazy-load hast, rate nicht an Einstellungen im Code herum. Notiere die Seite, den Namen des Hauptbildes und dass es das größte Element im ersten Bildschirmbereich ist. Für einen Entwickler ist das bereits eine normale Aufgabenbeschreibung und nicht nur ein beunruhigtes “Irgendetwas ist bei Google rot.”

CLS ist oft ohne besonderes Wissen sichtbar. Öffne die Seite und scrolle nicht sofort. Achte darauf, ob Blöcke verspätet erscheinen, durch die alles verrutscht, was schon auf dem Bildschirm war. Prüfe besonders große Fotos, Videos, eingebettete Karten, Formulare, Widgets und Banner.

Google nennt Bilder ohne angegebene Maße, Werbung, Einbettungen und iframes ohne Maße, dynamisch hinzugefügte Inhalte und Webfonts als häufige Ursachen für Sprünge. Ein iframe ist ein in eine Seite eingebettetes Fenster eines anderen Dienstes, zum Beispiel einer Karte, eines Videos oder eines Formulars. Für einen Leser macht es keinen Unterschied, was den Button verschoben hat; wichtig ist, dass die Seite dafür nicht im Voraus Platz reserviert hat.

Lege im Editor für jedes Bild und Video Breite und Höhe fest. Wähle für eine Karte oder ein Video einen festen Container oder bitte darum, vor dem Laden Platz dafür zu reservieren.

Ein zweites hypothetisches Beispiel: Auf einer Dienstleistungsseite gibt es ein Buchungsformular, und darüber erscheint ein Bewertungs-Widget. Zuerst steht das Formular weit oben, dann lädt das Widget nach und schiebt den Button weg. Der Inhaber muss das Widget nicht neu schreiben. Er kann es auf dieser Seite deaktivieren, weiter nach unten verschieben oder einen Entwickler bitten, eine feste Höhe dafür zu reservieren. Wenn das System anbietet, Proportionen oder die Blockgröße anzugeben, lass die Felder nicht leer. Hier sind die ersten beiden Varianten Entscheidungen im Editor, die dritte ist eine technische Aufgabe.

INP hängt damit zusammen, wie eine Seite die Handlung einer Person verarbeitet. Oft beeinflusst JavaScript den Wert, also Code, der Menüs, Filter, Warenkörbe, Formulare, Pop-ups und andere Interaktionen ausführt. Wenn INP nicht innerhalb von 200 Millisekunden liegt, lautet die ehrliche Antwort meistens: Du brauchst einen Entwickler, der prüft, was genau die Reaktion blockiert.

Du kannst die Aufgabe trotzdem gut vorbereiten. Notiere die konkrete Handlung: “Auf dem Mobilgerät ändert sich auf der Produktkarte der Button nach der Größenwahl lange nicht” oder “Das Menü öffnet sich nach dem Klick mit einer Pause.” Ergänze URL, Gerät und die Zeit, zu der du es gesehen hast. Nenne die Ursache nicht, wenn du sie nicht kennst. Dein Wert liegt hier in der genauen Beschreibung des Moments, nicht im Versuch, JavaScript mit einem zufälligen Plugin selbst zu behandeln.

Installiere nicht nur deshalb ein Caching-Plugin, weil du einen roten Balken hast. Es kann in einer bestimmten Konfiguration nützlich sein, reduziert aber nicht das Gewicht eines Fotos, das du in übergroßer Größe hochgeladen hast, und erklärt nicht, warum die Seite verzögert reagiert. Nenne das Problem zuerst beim Namen: LCP, CLS oder INP. Entscheide erst danach, ob du eine Datei oder einen Block im Editor ändern kannst oder technische Arbeit nötig ist.

Der erste Schritt ist einer: Öffne in der Search Console den Bericht Core Web Vitals, notiere die schlechteste der drei Metriken getrennt für Mobilgeräte und Computer und suche eine Seite aus dieser Gruppe. Schau dann nicht auf die rote Farbe, sondern darauf, worauf eine Person wirklich wartet, was sie drückt oder was sie aus dem Blick verliert.