Was sind Core Web Vitals? LCP, INP und CLS verständlich erklärt und gezielt verbessern

Core Web Vitals sind drei Kennzahlen, mit denen Google die echte Nutzererfahrung auf einer Seite beschreibt: LCP für das Laden, INP für die Reaktionsfähigkeit und CLS für die visuelle Stabilität. Ich arbeite seit 2012 im Onlinemarketing und optimiere diese Werte regelmäßig auf Kundenseiten. In diesem Leitfaden erkläre ich jede Kennzahl, ihre Grenzwerte und konkrete Wege zur Verbesserung.

Den allgemeinen Einfluss der Geschwindigkeit auf das Ranking beschreibe ich im Beitrag wie die Ladezeit SEO beeinflusst. Den Testablauf mit Lighthouse finden Sie in meinem Lighthouse Leitfaden. Hier geht es also ausschließlich um die drei Kennzahlen selbst.

Was sind Core Web Vitals und warum sind sie wichtig?

Core Web Vitals sind drei Google Kennzahlen, die messen, wie schnell der Hauptinhalt einer Seite lädt, wie schnell die Seite auf Eingaben reagiert und wie stabil das Layout beim Laden bleibt. Google erhebt sie bei echten Chrome Nutzern und nutzt sie als Teil der Signale zur Nutzererfahrung in der Suche.

Sie sind also aus zwei Gründen wichtig. Zunächst geht es um die Suche: Google schreibt in der Search Central Dokumentation ausdrücklich, dass die Rankingsysteme Core Web Vitals verwenden. Außerdem geht es um Menschen. Eine Seite, die langsam lädt, spät auf einen Tipp reagiert oder den Button unter dem Finger wegschiebt, verliert Besucher ganz leise. Deshalb sind diese Kennzahlen mehr als ein SEO Wert; sie messen die Reibung ganz oben im Verkaufstrichter.

Das häufigste Missverständnis in meiner Praxis lautet: Core Web Vitals seien eine einmalige technische Aufgabe. Tatsächlich kann jedes neue Plugin, jedes Kampagnenbanner und jedes Tracking Skript die Werte erneut verschlechtern. Daher behandle ich sie wie einen Gesundheitsindikator, den Sie jeden Monat prüfen.

Aus welchen drei Kennzahlen bestehen die Core Web Vitals?

Das aktuelle Set umfasst drei Kennzahlen, und jede deckt einen anderen Teil der Erfahrung ab. Laut den offiziellen Definitionen auf web.dev gelten diese Grenzwerte:

Ein Detail ist dabei allerdings entscheidend. Eine Seite besteht nur, wenn alle drei Kennzahlen im guten Bereich liegen. Zum Beispiel markiert die Search Console eine URL Gruppe als schlecht, wenn LCP und CLS glänzen, INP aber schwach ist. Zudem bewertet Google die Grenzwerte am 75. Perzentil und nicht am Durchschnitt. Darauf komme ich weiter unten zurück, denn viele Teams schauen auf Mittelwerte und ziehen falsche Schlüsse.

Das Set bleibt außerdem nicht starr. INP hat zum Beispiel im März 2024 den Vorgänger FID abgelöst. Kurz gesagt: Ihre Quelle für aktuelle Grenzwerte sollte immer web.dev sein.

Was ist LCP und welcher Wert gilt als gut?

LCP, also Largest Contentful Paint, markiert den Moment, in dem das größte sichtbare Inhaltselement im Viewport fertig dargestellt ist. Der LCP Leitfaden auf web.dev setzt den guten Bereich bei 2,5 Sekunden oder weniger an. Alles über 4 Sekunden gilt als schlecht.

Das LCP Element ist meistens eines davon:

• Das Heldenbild oder ein großes Produktfoto.
• Ein großes Hintergrundbild, das Sie per CSS einbinden.
• Das Vorschaubild eines Videos.
• Eine große Überschrift oder ein Textblock auf Seiten ohne Bilder.

Ich schätze diese Kennzahl vor allem, weil sie nah am Gefühl der Nutzer liegt. Ein Besucher empfindet eine Seite als geladen, sobald er den Hauptinhalt sieht. Allerdings schwankt LCP stark je nach Gerät. Eine Seite mit 1,2 Sekunden am Desktop mit Glasfaser kann auf einem Android Mittelklassegerät im Mobilfunknetz locker über 4 Sekunden liegen.

Lesen Sie deshalb Daten für Mobilgeräte und Desktop immer getrennt. Google trennt sie in den Berichten ebenfalls. In den meisten meiner Projekte steht mobiles LCP ganz oben auf der Liste, weil dort der Großteil des Traffics entsteht.

Warum ist LCP auf so vielen Websites langsam?

Bevor Sie LCP verbessern, müssen Sie wissen, wohin die Zeit fließt. web.dev teilt LCP in vier Teilphasen auf, und diese Aufteilung erleichtert die Diagnose enorm:

1. Zeit bis zum ersten Byte (TTFB): wie lange der Server für die erste Antwort braucht.
2. Ladeverzögerung der Ressource: wie lange der Browser wartet, bis er das LCP Bild entdeckt und anfordert.
3. Ladedauer der Ressource: wie lange der Download des Bildes selbst dauert.
4. Renderverzögerung: wie lange es nach dem Download bis zur Darstellung dauert.

In der Praxis macht der zweite Punkt die meisten Probleme. Zum Beispiel versteckt ein Slider, der das Heldenbild per JavaScript einfügt, dieses Bild vor dem Browser. Der Browser muss zuerst auf das Skript warten. Ebenso verzögert Lazy Loading am LCP Bild die Entdeckung.

Der erste Punkt schlägt meist bei günstigem Shared Hosting oder bei dynamischen Seiten ohne Cache zu. Baut der Server jede Seite bei jedem Aufruf aus der Datenbank neu, frisst TTFB allein schon eine Sekunde. Suchen Sie daher zuerst die dominante Teilphase. Springen Sie nicht sofort zur Bildkompression.

Wie verbessern Sie LCP?

Sobald die Ursache klar ist, liegen die Maßnahmen ziemlich offen. Diese Schritte setze ich am häufigsten um:

• Binden Sie das LCP Bild direkt im HTML als img Tag ein und nicht nachträglich per JavaScript.
• Geben Sie diesem Bild fetchpriority="high" und entfernen Sie Lazy Loading.
• Liefern Sie das Bild in einem modernen Format wie WebP oder AVIF und in der echten Anzeigegröße aus.
• Senken Sie TTFB mit serverseitigem Seitencache und einem CDN.
• Reduzieren Sie blockierendes CSS und synchrone Skripte.
• Laden Sie wichtige Webfonts vorab, damit ein textbasiertes LCP nicht wartet.

Konkret hilft ein einfacher Größentest. Liefern Sie ein 1920 Pixel breites Foto in einen mobilen Bereich von 400 Pixeln, laden Nutzer eine vielfach zu große Datei. In diesem Fall erstellen Sie mit dem Tool zum Bild verkleinern eine passende Version und liefern über srcset unterschiedliche Dateien für unterschiedliche Bildschirme aus.

Ändern Sie trotzdem nicht alles gleichzeitig. Gehen Sie mit einer Änderung live, beobachten Sie die Felddaten einige Wochen und nehmen Sie dann die nächste in Angriff. So erkennen Sie, welcher Schritt wirklich gewirkt hat.

Was ist INP und warum hat es FID ersetzt?

INP, also Interaction to Next Paint, misst, wie lange eine Seite nach einem Klick, Tipp oder Tastendruck bis zur nächsten sichtbaren Aktualisierung braucht. Der INP Leitfaden auf web.dev nennt 200 Millisekunden oder weniger gut. Über 500 Millisekunden gilt als schlecht.

Seit dem 12. März 2024 gehört INP zu den Core Web Vitals und hat FID (First Input Delay) abgelöst. Die Logik dahinter ist einfach. FID betrachtete nur die Verzögerung, bevor der Browser mit der ersten Interaktion begann. Die Dauer der eigentlichen Arbeit und alle späteren Interaktionen blieben außen vor.

INP beobachtet dagegen die Interaktionen während des gesamten Besuchs und meldet eine der langsamsten. Folglich ist INP eine viel ehrlichere Kennzahl. Ich habe das direkt erlebt: Unter FID sah fast jede Website gut aus. Mit INP rutschten dann viele Onlineshops mit viel JavaScript über Nacht in den gelben und roten Bereich.

Kurz gesagt zeigt INP, wie flüssig sich Ihre Website beim Stöbern, beim Filtern und beim Hinzufügen zum Warenkorb anfühlt. Aus Sicht der Conversion Rate ist das inzwischen die Kennzahl, die mir am wichtigsten ist.

Welche Interaktionen verschlechtern INP am stärksten?

Schwaches INP entsteht fast immer durch Arbeit, die den Hauptthread blockiert. Der Browser nutzt einen einzigen Hauptthread, um JavaScript auszuführen und den Bildschirm zu zeichnen. Läuft also ein langes Skript, während jemand klickt, wartet dieser Klick in der Schlange.

Diese Problemfälle sehe ich am häufigsten:

• Kategorieseiten, die bei jedem Filterklick die komplette Produktliste neu berechnen.
• Ein Menübutton, der eine schwere Animationsbibliothek startet.
• Ein Warenkorbbutton, der gleichzeitig mehrere Tracking Skripte auslöst.
• Formularfelder, die bei jedem Tastendruck Validierung und Vorschläge berechnen.
• Skripte von Drittanbietern wie Chat Widgets, Popups und Cookie Banner, die im Hintergrund laden.

Behalten Sie dabei eines im Blick. Labortests klicken nicht, deshalb bleiben diese Probleme dort oft unsichtbar. Lighthouse zeigt statt INP die Total Blocking Time (TBT) als Ersatzwert. Ein hoher TBT deutet meist auch auf schwaches INP hin. Ein niedriger TBT beweist allerdings nicht, dass INP gut ist. Nur Felddaten zeigen das echte Bild.

Wie verbessern Sie INP?

web.dev zerlegt jede Interaktion in drei Teile: Eingabeverzögerung, Verarbeitungsdauer und Darstellungsverzögerung. Ihre Strategie hängt davon ab, welcher Teil zu lang ist.

Ist die Eingabeverzögerung lang, beschäftigt sich der Hauptthread beim Klick mit anderer Arbeit. Dann teilen Sie lange Aufgaben während des Ladens auf und laden Skripte von Drittanbietern später, sofern Sie sie nicht sofort brauchen. Ist die Verarbeitungsdauer lang, erledigt der Event Handler selbst zu viel. Zum Beispiel bringt es oft viel, zuerst sofort ein visuelles Feedback zu zeigen und die schwere Arbeit in den nächsten Frame zu verschieben.

Die Darstellungsverzögerung tritt meist bei einem sehr großen DOM auf. Auf einer Seite mit Tausenden Elementen löst schon eine einzige Klassenänderung eine teure Neuberechnung aus. Deshalb empfehle ich für sehr lange Listen Virtualisierung oder Paginierung.

Tiefe JavaScript Optimierung verdient einen eigenen Artikel, daher bleibe ich hier bei den Grundzügen. Mein erster Schritt ist in der Praxis immer gleich: Ich liste alle Skripte von Drittanbietern auf der Website auf und frage, ob sie noch jemand nutzt. In den meisten Projekten fällt etwa die Hälfte weg, und INP entspannt sich fast sofort.

Was ist CLS und wie berechnet Google den Wert?

CLS, also Cumulative Layout Shift, misst, wie stark sich sichtbare Inhalte unerwartet verschieben, während die Seite offen ist. Laut dem CLS Leitfaden auf web.dev gilt 0,1 oder weniger als gut und alles über 0,25 als schlecht. Der Wert hat keine Einheit; er ist eine Punktzahl, keine Zeit.

Für jede Verschiebung multipliziert der Browser zwei Werte: den Anteil des Viewports, den die verschobenen Elemente belegen, und die Strecke, die sie zurücklegen. Danach fasst er zeitlich nahe Verschiebungen in Sitzungsfenstern zusammen. Ein Fenster dauert höchstens 5 Sekunden, und eine Pause von mehr als 1 Sekunde startet ein neues. Ihr CLS stammt dann aus dem Fenster mit der höchsten Summe während des Besuchs.

Zudem ist eine weitere Regel wichtig. Verschiebungen innerhalb von 500 Millisekunden nach einer Nutzerinteraktion zählen nicht. Klappt also Inhalt nach einem Tipp auf „mehr anzeigen“ auf, ist das in Ordnung. Das Problem sind Inhalte, die sich bewegen, obwohl der Nutzer nichts tut.

Das klassische Beispiel kennen wir daher alle. Sie wollen auf einer Nachrichtenseite einen Link antippen, oben lädt eine Anzeige, der Inhalt springt und Sie treffen das Falsche. CLS macht genau diesen Ärger messbar.

Wie senken Sie CLS?

CLS lässt sich meist am leichtesten beheben, denn die Ursachen sind vertraut. Meine Checkliste sieht so aus:

• Geben Sie allen Bildern und Videos Breite und Höhe mit oder reservieren Sie den Platz per CSS Seitenverhältnis.
• Reservieren Sie für Anzeigen, Einbettungen und iframes feste Platzhalter, bevor diese laden.
• Zeigen Sie das Cookie Banner als Overlay und nicht als Block, der Inhalte nach unten schiebt.
• Stimmen Sie die Anzeige von Webfonts und die Maße der Ersatzschrift ab, damit Text beim Nachladen nicht springt.
• Fügen Sie keine neuen Inhalte oberhalb bestehender Inhalte ein und halten Sie Hinweisleisten in einem festen Bereich.

Animationen sind ein weiterer blinder Fleck. Animationen über Eigenschaften wie top oder margin können Layoutverschiebungen auslösen. Mit transform passiert das dagegen nicht. Außerdem hilft der Back Forward Cache des Browsers, denn er stellt die Seite beim Zurückblättern ohne neues Layout sofort wieder her.

Da diese Maßnahmen eng am Design liegen, ist CLS bei einem Neubau oder Relaunch von Anfang an viel günstiger. In meinen Webdesign Projekten lege ich Bildflächen und Bannerplätze schon in der Designphase fest. So muss später niemand nachbessern.

Was unterscheidet Felddaten von Labordaten?

Hier entsteht allerdings die größte Verwirrung. Felddaten stammen von echten Chrome Nutzern, die Ihre Website besuchen. Labordaten stammen dagegen aus einem simulierten Test auf einem Gerät mit einem simulierten Netz.

Für das Ranking betrachtet Google die Felddaten. Ein Lighthouse Wert von 95 heißt also nicht, dass die Search Console grün zeigt. Das Gegenteil kommt ebenfalls vor. Ein langsames Testgerät liefert einen schwachen Laborwert, während Ihre echten Besucher mit schnelleren Handys gute Felddaten erzeugen.

Meine Regel ist einfach: Status mit Felddaten messen, Ursachen mit Labordaten finden. Tauschen Sie die beiden nie gegeneinander aus.

Warum nutzt Google das 75. Perzentil?

Google bewertet die Core Web Vitals am 75. Perzentil und nicht am Durchschnitt. Das heißt: Damit eine Seite beim LCP als gut gilt, müssen mindestens 75 Prozent der Besuche ein LCP von 2,5 Sekunden oder weniger haben.

Diese Wahl ist bewusst, denn Durchschnittswerte verstecken Ausreißer. Eine Beispielrechnung: Sieht die Hälfte Ihrer Besucher die Seite nach 1 Sekunde und die andere Hälfte nach 4 Sekunden, liegt der Durchschnitt bei 2,5 Sekunden. Alles wirkt in Ordnung. Trotzdem hat die Hälfte Ihrer Nutzer eine schlechte Erfahrung. Das 75. Perzentil macht diese langsame Gruppe sichtbar.

In der Praxis bedeutet das: Optimieren Sie für Geräte der Mittel und Einstiegsklasse, nicht für Ihre schnellsten. Ältere Handys und schwache Mobilfunkverbindungen bestimmen meist das 75. Perzentil. Aktivieren Sie deshalb in DevTools die Drosselung von CPU und Netz als feste Gewohnheit.

Zudem bewertet Google Mobilgeräte und Desktop getrennt. Ist der Desktop grün und die mobile Ansicht rot, gilt für die mobile Suche das rote Ergebnis.

Mit welchen Tools überwachen Sie Core Web Vitals?

Meine Tools für Core Web Vitals ordne ich nach Zweck:

• Google Search Console: Feldstatus nach URL Gruppen für die gesamte Website. Das ist der Startpunkt für jeden Gesundheitscheck.
• PageSpeed Insights: CrUX Felddaten und ein Lighthouse Labortest für eine einzelne URL auf einem Bildschirm.
• CrUX Vis und die CrUX API: historische Trends pro Domain oder pro Seite.
• Performance Bereich in Chrome DevTools: LCP, INP und CLS live während Ihrer eigenen Interaktionen.
• Die JavaScript Bibliothek web vitals von Google: echte Nutzerdaten Ihrer eigenen Besucher, die Sie an Ihr Analysetool senden.

Die letzte Option nutzen die wenigsten, obwohl sie aus meiner Sicht die wertvollste ist. Da CrUX ein Fenster von 28 Tagen verwendet, dauert es Wochen, bis Sie die Wirkung einer Korrektur sehen. Mit eigener Messung sehen Sie Ergebnisse nach wenigen Tagen. Zudem erkennen Sie, welches Template oder welche Interaktion das Problem verursacht.

Seiten mit wenig Traffic zeigen oft gar keine CrUX Daten. Google hat dann schlicht zu wenige Stichproben. Folglich ist Ihre eigene Messung die einzige verlässliche Quelle.

Wie lesen Sie den Core Web Vitals Bericht in der Search Console?

Der Bericht in der Search Console gruppiert ähnliche Seiten, statt jede URL einzeln aufzulisten. Die Hilfeseite von Google zum Bericht erklärt diese Gruppierung. Zum Beispiel landen alle Produktseiten mit demselben Template oft in einer einzigen Gruppe.

Ich lese den Bericht deshalb in fester Reihenfolge. Zunächst öffne ich den Tab für Mobilgeräte, weil dort der meiste Traffic entsteht. Danach öffne ich die Gruppen „Schlecht“ und „Optimierung erforderlich“ und prüfe, welche Kennzahl das Problem verursacht. Eine Gruppe übernimmt dabei den Status ihrer schwächsten Kennzahl.

Dann öffne ich eine Beispiel URL aus der Gruppe in PageSpeed Insights und wechsle zur Labordiagnose. Nach einer Korrektur können Sie im Bericht auf „Korrektur überprüfen“ klicken. Allerdings startet die Prüfung einen Beobachtungszeitraum von 28 Tagen; erwarten Sie also keine sofortige Antwort.

Den Rest des Tools erkläre ich in meiner Search Console Anleitung für Einsteiger. Der Bericht zu den Core Web Vitals ist nur ein Teil davon.

Wie stark beeinflussen Core Web Vitals das Ranking?

Die ehrliche Antwort: Sie wirken, aber sie schlagen die Relevanz nicht. Google bestätigt, dass die Rankingsysteme Core Web Vitals nutzen. Gleichzeitig betont die Dokumentation zur Nutzererfahrung, dass eine gute Seitenerfahrung allein keine Spitzenplätze garantiert und Relevanz Vorrang hat.

Meine Einschätzung aus der Praxis: Core Web Vitals wirken als Entscheidungshilfe zwischen Seiten mit ähnlicher Qualität. Die Seite mit der besten Antwort kann auch etwas langsamer gut ranken. Bieten Sie und ein Wettbewerber jedoch gleich starke Inhalte, macht der Unterschied in der Erfahrung den Ausschlag.

Die indirekte Wirkung ist allerdings viel größer als die Wirkung auf das Ranking. Auf einer langsamen, springenden Seite gehen Nutzer früher, sehen weniger Seiten an und kaufen seltener. Diese Seite beleuchte ich im Beitrag zur Absprungrate auf Firmenwebsites.

Kurz gesagt: Betrachten Sie Core Web Vitals als Grundhygiene für Suche und Nutzer und nicht als Rankingtrick. Die weiteren Faktoren der Nutzererfahrung finden Sie im Artikel über SEO und UX.

In welcher Reihenfolge planen Sie die Arbeit?

Viele Teams beginnen mit der sichtbarsten Seite, der Startseite. Der meiste Traffic und Umsatz entsteht allerdings meist auf Kategorie, Produkt oder Leistungsseiten. Diese Reihenfolge empfehle ich:

1. Öffnen Sie den mobilen Bericht in der Search Console und notieren Sie die URL Gruppen mit schlechtem Status.
2. Sortieren Sie diese Gruppen nach Traffic und Umsatzbeitrag.
3. Bestimmen Sie, welche Kennzahl im Template der wertvollsten Gruppe scheitert.
4. Analysieren Sie die Teilphasen dieser Kennzahl mit PageSpeed Insights und DevTools.
5. Gehen Sie mit jeweils einer Korrektur live.
6. Beobachten Sie das Ergebnis einige Tage mit eigenen Daten und einige Wochen mit CrUX.
7. Wechseln Sie erst nach bestätigtem Ergebnis zur nächsten Gruppe.

Der Vorteil dieser Reihenfolge: Sie denkt in Templates. Beheben Sie ein Problem mit dem Heldenbild im Produkttemplate, verbessern Sie Tausende Seiten auf einmal. Außerdem starten Sie dort, wo die geschäftliche Wirkung am größten ist. Das erleichtert auch die Berichte an die Geschäftsführung.

Möchten Sie diese Arbeit in einen größeren Plan einbetten, bieten meine Tipps zum technischen SEO einen guten Rahmen.

Welche Fehler machen die Arbeit an Core Web Vitals zunichte?

Über die Jahre habe ich dieselben Fehler in sehr unterschiedlichen Projekten gesehen. Diese kommen am häufigsten vor:

• Einem Lighthouse Wert hinterherjagen und die Felddaten nie prüfen.
• Ein Speed Plugin installieren, das jedes Bild verzögert lädt, auch das LCP Bild.
• Nur am Desktop testen und mobile Nutzer übersehen.
• Am Tag nach der Korrektur schon eine Änderung in der Search Console erwarten.
• Tracking Skripte und Popups ignorieren, die das Marketing später einbaut.

Der letzte Punkt kostet allerdings am meisten. Ein Entwickler bringt die Werte in monatelanger Arbeit in den grünen Bereich. Dann kommen für eine neue Kampagne drei Skripte und ein bildschirmfüllendes Popup dazu, und alles beginnt von vorn. Deshalb sollten Entwicklung und Marketing die Core Web Vitals gemeinsam verantworten.

Ein weiterer häufiger Fehler ist blindes Vertrauen in Speed Plugins. Manchmal helfen sie. Mit falschen Einstellungen laden sie jedoch CSS zu spät und erhöhen CLS, oder sie verzögern Skripte und stören Interaktionen. Messen Sie deshalb nach jeder Änderung der Einstellungen.

Warum sind Core Web Vitals auf Mobilgeräten schwieriger?

Mobilgeräte unterscheiden sich bei Rechenleistung, Speicher und Netz viel stärker als Desktops. Dasselbe JavaScript Paket, das auf einem starken Laptop in wenigen hundert Millisekunden läuft, braucht auf einem Mittelklassehandy ein Vielfaches. Diese Lücke zeigt sich direkt im INP.

Beim Netz ist es zudem ähnlich. Mobile Verbindungen haben eine höhere Latenz, daher kostet jede zusätzliche Anfrage, jede Weiterleitung und jede fremde Domain echte Zeit beim LCP. Zum Beispiel kann eine Sprachweiterleitung vor der Startseite für mobile Nutzer schon allein eine spürbare Verzögerung erzeugen.

Denken Sie mobiles Design also nicht als Desktopseite, die auf einen kleinen Bildschirm gequetscht ist. Wer Slider, schwere Animationen und übergroße Bilder entfernt, die mobile Nutzer nicht brauchen, verbessert oft alle drei Kennzahlen zugleich. Für einen allgemeinen Check lesen Sie meinen Beitrag zum Test der Mobilfreundlichkeit.

Wie halten Sie gute Core Web Vitals dauerhaft stabil?

Die Werte einmal grün zu bekommen, ist der leichte Teil. Sie grün zu halten, ist schwieriger. Deshalb empfehle ich einige feste Gewohnheiten.

Erstens: Legen Sie ein Performance Budget fest. Begrenzen Sie zum Beispiel die gesamte JavaScript Größe der Startseite und die Dateigröße des LCP Bildes. Sprengt eine neue Funktion das Budget, entscheidet das Team vorher, was dafür wegfällt. Somit wird Performance zum festen Teil jeder Design und Marketingentscheidung.

Zweitens: Automatisieren Sie die Messung. Senden Sie die Daten aus der Bibliothek web vitals an Ihr Analysetool und prüfen Sie sie jede Woche. Zudem fängt eine Prüfung wie Lighthouse CI im Releaseprozess Rückschritte ab, bevor sie live gehen.

Drittens: Begrenzen Sie, wer Skripte von Drittanbietern einbauen darf. Kann jeder mit Zugang zum Tag Manager Code hinzufügen, haben Sie die Performance nicht wirklich im Griff.

Möchten Sie das nicht allein stemmen, nehme ich die Überwachung der Core Web Vitals in die monatliche Routine meiner SEO Beratung auf.

Wo fangen Sie heute mit den Core Web Vitals an?

Zusammengefasst messen Core Web Vitals drei grundlegende Erfahrungen: wie schnell Menschen den Hauptinhalt sehen, wie schnell die Seite auf ihre Aktionen reagiert und wie stabil sie bleibt. Die Grenzwerte sind klar: 2,5 Sekunden für LCP, 200 Millisekunden für INP und 0,1 für CLS.

Der sinnvollste Schritt für heute: Öffnen Sie den mobilen Bericht in der Search Console und suchen Sie die scheiternde Kennzahl in Ihrem wertvollsten Template. Analysieren Sie dann die Teilphasen und starten Sie mit einer einzigen Korrektur. Jagen Sie keinem perfekten Wert nach. Zielen Sie stattdessen auf eine gute Erfahrung für mindestens 75 Prozent Ihrer echten Nutzer. Genau das belohnen am Ende Google und Ihre Kunden.