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 summiert, wie viel vom bereits Sichtbaren unerwartet verrutscht und wie weit es dabei wandert. Das sind keine Sekunden, sondern ein einheitenloser Wert: 0,1 oder weniger ist gut, über 0,25 ist schlecht. 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. Und es geht nicht nur um die ersten Sekunden. Google misst CLS über die gesamte Lebensdauer der Seite, nicht nur während des Ladens. Eine Verschiebung, die innerhalb einer halben Sekunde auf deinen eigenen Klick folgt, gilt als erwartet und zählt nicht; eine Verschiebung, die von allein passiert - etwa wenn beim Weiterscrollen Inhalte nachgeladen werden -, zählt dagegen mit.

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. Zwei weitere Details sparen Zeit. Eine Gruppe erscheint erst, wenn sie eine Mindestmenge an Daten für LCP und CLS zugleich hat; ist es zu wenig, kann die Search Console stattdessen eine Origin-Gruppe zeigen, die alle URLs unter einem Protokoll, Host und Port zusammenfasst. Und “No data available” ist keine gute Note: Es bedeutet, dass es noch zu wenige echte Besuche gibt, nicht dass die Seiten schnell sind.

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. Gut zu wissen: PageSpeed Insights zeigt beides gleichzeitig - oben die Daten echter Chrome-Besucher, darunter eine Labormessung, die im Moment des Tests entsteht. Prüfe, welche der beiden du liest, und ob es Daten deiner URL oder der ganzen Website sind, denn bei zu wenig Traffic auf einer einzelnen Seite greift das Tool auf die Origin-Daten zurück. Es gibt noch einen ehrlichen Grund für Abweichungen: Ein Laborlauf lädt die Seite meist und hört dann auf, sieht also die Verschiebungen nicht, die später beim Scrollen passieren.

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. Komprimieren lohnt sich, aber versprich dir nicht, dass es auf jeder Seite die Zahl bewegt. Von den vier Teilen oben verkürzt eine leichtere Datei nur einen: das Laden selbst. Bleibt das Bild verborgen, bis ein Skript fertig ist, und erscheint dann alles auf einmal, wandert die gesparte Zeit einfach in das Rendern des Elements, und LCP bleibt, wo es war. Wenn die Datei also um ein Vielfaches leichter ist und der Bericht sich trotzdem nicht bewegt, ist das kein Fehler von dir, sondern ein Zeichen, dass die verbliebene Ursache technisch ist.

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.

Nehmen wir eine hypothetische Möbelwerkstatt und schreiben die Annahmen auf, damit die Überlegung prüfbar bleibt. Angenommen, die Search Console stuft die mobile Gruppe der Projektseiten bei LCP als Poor ein; im ersten Bildschirmbereich steht ein Küchenfoto, das der Inhaber direkt aus der Kamera hochgeladen hat, rund vier Megabyte groß; auf dem Telefon wird dieses Foto etwa 800 Pixel breit angezeigt; und die Website läuft auf einem Content-Management-System, dessen Mediathek Datei, Format und den Lazy-Load-Schalter zugänglich macht, aber nicht mehr. Die Entscheidung unter diesen Annahmen: die Website nicht umbauen und kein Plugin kaufen. Diese eine Datei durch eine Version ersetzen, die für die tatsächlich gezeigte Größe vorbereitet ist, sie als WebP oder AVIF speichern, falls das System das anbietet, das Original im Archiv behalten und Lazy Load nur für dieses Bild abschalten. Danach warten: Der Bericht spricht in achtundzwanzig Tagen echter Besuche, ein Urteil am nächsten Morgen bedeutet also nichts. Drei Dinge würden diese Entscheidung ändern. Ist das größte Element im ersten Bildschirmbereich in Wahrheit eine Überschrift oder ein anderer Block, war das Foto nie das richtige Ziel. Lädt die neue Datei schnell und die Gruppe bleibt nach mehreren Wochen trotzdem Poor, liegt die Ursache eher bei der Serverantwort oder bei Skripten, die das Rendern aufhalten. Und gibt der Editor keinen Zugriff auf Format, Komprimierung oder Lazy Load, ist der ehrliche nächste Schritt eine beschriebene Aufgabe für einen Entwickler und kein weiterer Versuch in der Mediathek. 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. Fehlen diese Felder, erledigt dieselbe Aufgabe ein Seitenverhältnis in den Styles; und für einen Block, dessen Höhe vorab unbekannt ist - ein Bewertungs-Widget, ein Werbeplatz, ein eingebettetes Formular -, funktioniert eine reservierte Mindesthöhe. Wähle für eine Karte oder ein Video einen festen Container oder bitte darum, vor dem Laden Platz dafür zu reservieren. Eine Warnung zum reservierten Platz: Er darf nicht zusammenfallen, wenn nichts ankommt. Ein Platzhalter, der verschwindet, weil keine Anzeige und keine Bewertung geliefert wurde, verursacht genau denselben Sprung wie erscheinender Inhalt.

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. Google zerlegt jede Interaktion in drei Teile: die Verzögerung, bevor der Code, der deinen Klick behandelt, überhaupt zu laufen beginnt; die Zeit, die dieser Code braucht; und die Verzögerung, bis der Browser das Ergebnis auf dem Bildschirm zeigen kann. JavaScript - also der Code, der Menüs, Filter, Warenkörbe, Formulare und Pop-ups ausführt - taucht meist in einem dieser Teile auf, und beim Laden kann ein großes Skript die Reaktion allein deshalb aufhalten, weil der Browser es noch einliest und kompiliert. Eine Sache kannst du ohne Entwickler tun, und sie ist kein Behelf: Sieh nach, wie viel du der Seite aufgeladen hast. Ein Chat, ein Bewertungs-Widget, Werbe- und Analyse-Tags, ein Slider, den niemand benutzt - jedes davon bringt eigenen Code mit. Zu entfernen, was die Seite nicht braucht, ist eine redaktionelle Entscheidung. Darüber hinaus lautet die ehrliche Antwort: Um herauszufinden, welcher der drei Teile langsam ist, brauchst du jemanden, der ein Performance-Profil lesen kann.

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.