Core Web Vitals: Warum Web Performance nicht nur ein Entwicklerthema ist

Was Core Web Vitals messen und welche Werte wichtig sind

Core Web Vitals sind Kennzahlen, mit denen Google zentrale Aspekte der Nutzererfahrung auf einer Website bewertet. Im Mittelpunkt stehen drei Fragen:

• Wie schnell wird der wichtigste sichtbare Inhalt geladen? = Largest Contentful Paint (LCP).

• Wie schnell reagiert die Seite auf Nutzereingaben? = Interaction to Next Paint (INP).

• Wie stabil bleibt das Layout während des Ladens und der Nutzung? = Cumulative Layout Shift (CLS).

Historisch gehörte auch First Input Delay (FID) zu den Core Web Vitals. Inzwischen wurde diese Metrik durch Interaction to Next Paint ersetzt, weil INP die Interaktivität umfassender betrachtet und nicht nur die erste Eingabe eines Nutzers bewertet.

Als Orientierung gelten aktuell folgende Zielwerte:

• LCP: maximal 2,5 Sekunden

• INP: maximal 200 Millisekunden

• CLS: maximal 0,1

Diese Werte sollten nicht nur als Laborwerte betrachtet werden. Entscheidend ist, wie echte Nutzer die Website erleben, denn Geräte, Browser, Verbindungsgeschwindigkeiten und Nutzungssituationen können die Ergebnisse deutlich beeinflussen.

Deshalb lohnt sich der Blick auf mehrere Quellen: PageSpeed Insights gibt eine schnelle Einschätzung einzelner URLs, Lighthouse hilft bei technischen Detailanalysen im Laborumfeld und reale Nutzerdaten zeigen, wie eine Website tatsächlich erlebt wird. Wichtig ist dabei die richtige Interpretation: Ein einzelner schlechter Wert ist noch keine vollständige Diagnose, sondern ein Hinweis darauf, wo genauer hingeschaut und priorisiert werden sollte.

LCP: Wie schnell erscheint der wichtigste Inhalt?

Largest Contentful Paint, kurz LCP, misst, wann das größte sichtbare Inhaltselement im Viewport geladen ist. Das kann zum Beispiel ein großes Headerbild, ein Hero-Element, ein Textblock oder ein Produktbild sein.

Wichtig ist dabei: LCP misst nicht, wann die komplette Website vollständig geladen ist. Entscheidend ist, wann der zentrale sichtbare Inhalt für den Nutzer verfügbar wird. Gerade auf Startseiten, Landingpages, Kategorieseiten oder Produktdetailseiten ist diese Metrik besonders relevant, weil der erste Eindruck stark davon abhängt.

Ein guter LCP-Wert liegt bei maximal 2,5 Sekunden. Je schneller der Hauptinhalt erscheint, desto eher entsteht das Gefühl, dass die Seite zuverlässig und hochwertig funktioniert.

Typische Ursachen für schlechte LCP-Werte sind:

• zu große oder nicht optimierte Bilder

• langsame Serverantwortzeiten

• blockierende CSS- oder JavaScript-Dateien

• komplexe Hero-Bereiche mit Videos, Slidern oder Animationen

• fehlendes Caching

• zu spät geladene Webfonts oder zentrale Ressourcen

Aus Projektsicht ist LCP häufig kein einzelnes Entwicklungsproblem. Oft treffen mehrere Entscheidungen aufeinander: ein sehr großes Kampagnenbild, ein aufwendiger Slider, zusätzliche Tracking-Skripte und ein CMS, das Bilder nicht sauber in passenden Größen ausliefert. Das Ergebnis ist dann eine Seite, die visuell stark ausschaut, aber technisch zu langsam beim Nutzer ankommt.

INP: Wie direkt reagiert die Seite auf Eingaben?

Interaction to Next Paint, kurz INP, bewertet die Reaktionsfähigkeit einer Seite. Es geht darum, wie viel Zeit vergeht, bis eine Website nach einer Nutzerinteraktion sichtbar reagiert. Gemeint sind zum Beispiel Klicks, Tabs oder Tastatureingaben.

Ein guter INP-Wert liegt bei maximal 200 Millisekunden. Das klingt nach einem sehr kleinen Zeitfenster, ist aber für die wahrgenommene Qualität entscheidend. Nutzer merken schnell, ob eine Seite direkt reagiert oder ob zwischen Eingabe und Reaktion eine spürbare Verzögerung entsteht.

Das betrifft nicht nur offensichtliche Interaktionselemente wie Formulare oder Buttons. Auch Produktfilter, Navigationen, Slider, Warenkorb-Funktionen oder Cookie-Banner können die wahrgenommene Interaktivität beeinflussen.

Schlechte INP-Werte entstehen häufig durch:

• zu viel JavaScript im Frontend

• komplexe Third-Party-Skripte

• aufwendige Tracking- und Marketing-Tags

• schlecht optimierte Slider, Filter oder Konfiguratoren

• blockierte Hauptprozesse im Browser

• sehr komplexe DOM-Strukturen

Gerade in E-Commerce-Systemen zeigt sich das häufig deutlich. Eine Produktlisting-Seite kann inhaltlich gut aufgebaut sein und trotzdem zäh wirken, wenn Filter, Varianten, Tracking, Empfehlungslogiken und externe Skripte gleichzeitig um Ressourcen konkurrieren. Für Nutzer zählt am Ende nicht, warum die Seite verzögert reagiert. Sie erleben nur, dass sie nicht sauber funktioniert.

CLS: Wie stabil bleibt das Layout beim Laden und Nutzen?

Cumulative Layout Shift, kurz CLS, misst die visuelle Stabilität einer Seite. Vereinfacht gesagt: Die Metrik bewertet, wie stark sichtbare Inhalte unerwartet ihre Position verändern.

Jeder kennt solche Situationen: Man will auf einen Button klicken, doch kurz vorher wird noch ein Banner geladen und der Button verschiebt sich. Oder ein Bild erscheint nachträglich, ohne dass vorher Platz dafür reserviert wurde. Solche Layoutverschiebungen wirken unruhig, stören die Bedienung und können im schlimmsten Fall zu falschen Klicks führen.

Die Berechnung basiert vereinfacht auf zwei Faktoren: Wie groß ist der betroffene Bereich des Bildschirms und wie weit verschiebt er sich? Je mehr Inhalt sich bewegt und je größer die Bewegung ist, desto schlechter fällt der Layoutverschiebungswert aus.

Die Formel dafür ist:

layout shift score = impact fraction * distance fraction

1. Impact Fraction – wie viel Fläche ist betroffen?
Der Browser schaut, welche sichtbare Fläche durch ein verschobenes Element betroffen ist. Dabei zählen die alte und die neue Position des Elements zusammen als betroffener Bereich im Viewport. Beispiel: Wenn dieser Bereich 75 % des Viewports einnimmt, ist die Impact Fraction 0.75.

2. Distance Fraction – wie weit wurde verschoben?
Dann wird gemessen, wie weit sich das Element bewegt hat. Genommen wird die größte horizontale oder vertikale Verschiebung, geteilt durch die größte Viewport-Dimension. Beispiel: Wenn sich ein Element um 25 % der maßgeblichen Viewport-Dimension verschiebt, beträgt die Distance Fraction 0,25.

Dann wird gerechnet: 0,75 × 0,25 = 0,1875. Der Layout-Shift-Wert für diese einzelne Verschiebung wäre also 0,1875.

Wichtig ist: Für den finalen CLS-Wert werden nicht einfach alle Layoutverschiebungen über die komplette Seitenlebensdauer addiert. Bewertet wird das schlechteste sogenannte Sitzungsfenster. Dabei werden mehrere unerwartete Layout Shifts in kurzer Folge zusammengefasst, wenn zwischen ihnen weniger als eine Sekunde liegt und das gesamte Fenster maximal fünf Sekunden dauert.

Als Zielwert gilt: CLS ≤ 0,1 ist gut, über 0,25 ist schlecht.

Typische Ursachen für hohe CLS-Werte sind:

• Bilder ohne definierte Breite und Höhe

• nachladende Anzeigen, Banner oder Teaser

• Cookie-Banner, die Platz im Layout verändern

• dynamisch eingefügte Inhalte oberhalb bestehender Elemente

• Webfonts, die sichtbare Textverschiebungen auslösen

• eingebettete Inhalte ohne reservierten Platz

CLS ist oft ein gutes Beispiel dafür, dass Performance nicht nur mit Geschwindigkeit zu tun hat. Eine Seite kann schnell laden und sich trotzdem schlecht anfühlen, wenn sich zentrale Elemente während der Nutzung verschieben. Visuelle Stabilität ist deshalb ein wichtiger Teil professioneller Frontend-Qualität.

Warum Core Web Vitals für SEO relevant sind

Google möchte Nutzern möglichst hilfreiche Ergebnisse liefern. Hilfreich ist eine Seite aber nicht nur, wenn der Inhalt grundsätzlich passt. Sie muss auch erreichbar, nutzbar und angenehm bedienbar sein.

Core Web Vitals sind Teil dieser Nutzererfahrung. Sie gehören zur Page Experience und können damit in die Bewertung einer Seite einfließen. Gleichzeitig sollte man ihre Wirkung nicht überzeichnen. Eine schnelle Seite mit schwachem Inhalt wird in der Regel nicht allein wegen guter Performance starke Rankings erreichen. Umgekehrt kann eine fachlich sehr relevante Seite trotz schwächerer Werte sichtbar bleiben, wenn sie die Suchintention besonders gut erfüllt.

Relevant werden Core Web Vitals vor allem dort, wo mehrere Seiten inhaltlich auf einem ähnlichen Niveau konkurrieren. Wenn mehrere Seiten eine Suchanfrage ähnlich gut beantworten, kann eine bessere Page Experience dazu beitragen, in der Suche erfolgreicher zu sein.

Das macht Web Performance strategisch interessant. Es geht nicht darum, isoliert ein paar Zahlen zu optimieren. Es geht darum, technische Qualität, Nutzererwartung und organische Sichtbarkeit zusammenzudenken.

Warum Web Performance kein reines Entwicklerthema ist

In vielen Projekten wird Performance erst dann zum Thema, wenn PageSpeed Insights rote Werte zeigt oder die Search Console Probleme meldet. Dann landet das Thema schnell bei der Entwicklung. Technisch ist das nachvollziehbar, organisatorisch aber oft zu kurz gedacht.

Schlechte Core Web Vitals entstehen selten nur durch schlechten Code. Häufig sind sie das Ergebnis vieler Einzelentscheidungen:

Ein Marketing-Team möchte zusätzliche Tracking-Tags einbinden. Ein Design sieht große Bewegtbildflächen vor. Im CMS werden Bilder in zu hoher Auflösung gepflegt. Ein externer Dienstleister integriert ein weiteres Skript. Der Cookie-Banner wird nachträglich ergänzt. Im Laufe der Zeit wächst die technische Last, ohne dass jemand die Gesamtwirkung bewertet.

Aus meiner Erfahrung wird Performance gerade dann verbessert, wenn Verantwortlichkeiten klar sind. Es braucht nicht nur Entwickler, die optimieren. Es braucht auch Entscheidungen darüber, welche Skripte wirklich notwendig sind, welche Gestaltungselemente den Aufwand rechtfertigen und welche Inhalte technisch sauber gepflegt werden müssen.

Gerade bei Relaunches, Shop-Migrationen oder größeren CMS-Projekten sollte Performance deshalb früh mitgedacht werden. Wenn sie erst kurz vor Livegang geprüft wird, sind viele Ursachen bereits fest im Konzept, Design oder Systemaufbau verankert. Dann wird Optimierung schnell aufwendig und konfliktbeladen.

Was Unternehmen konkret tun können

Eine sinnvolle Core-Web-Vitals-Optimierung beginnt nicht mit blindem Aktionismus, sondern mit einer ehrlichen Bestandsaufnahme.

Welche Seitentypen sind betroffen? Geht es um die Startseite, Produktdetailseiten, Kategorieseiten, Ratgeberartikel oder Landingpages? Welche Templates erzeugen wiederkehrende Probleme? Welche Skripte, Medien oder Inhalte haben den größten Einfluss? Und welche Maßnahmen bringen tatsächlich spürbare Verbesserung für Nutzer und Geschäftsziel?

In der Praxis sind häufig folgende Maßnahmen sinnvoll:

• Bilder in passenden Formaten und Größen ausliefern

• kritische Ressourcen priorisieren

• unnötiges JavaScript reduzieren

• Third-Party-Skripte prüfen und begrenzen

• Serverantwortzeiten verbessern

• Caching sauber konfigurieren

• Platz für Bilder, Banner und eingebettete Inhalte reservieren

• Fonts kontrolliert laden

• CMS-Pflegeprozesse für Medien und Inhalte verbessern

Entscheidend ist die Priorisierung. Nicht jede Optimierung lohnt sich im gleichen Maß. Eine Verbesserung auf stark frequentierten Landingpages oder wichtigen Shop-Templates kann deutlich mehr Wirkung entfalten als Detailarbeit an kaum besuchten Unterseiten.

Fazit: Core Web Vitals machen Nutzererfahrung messbar

Core Web Vitals sind keine reine SEO-Checkliste und kein Garant für bessere Rankings. Sie sind ein praktisches Messinstrument für zentrale Aspekte der Nutzererfahrung: Ladegeschwindigkeit, Interaktivität und visuelle Stabilität.

Genau deshalb sind sie für digitale Projekte so wertvoll. Sie übersetzen ein oft diffuses Gefühl in konkrete Werte. Eine Seite fühlt sich langsam an. Ein Button reagiert verzögert. Inhalte springen beim Laden. Core Web Vitals helfen dabei, solche Probleme sichtbar zu machen, zu priorisieren und gezielt zu verbessern.

Für Unternehmen liegt der eigentliche Nutzen nicht darin, einzelne Kennzahlen kosmetisch zu optimieren. Der Nutzen entsteht, wenn Performance als Teil der Gesamtqualität verstanden wird: technisch, redaktionell, gestalterisch und wirtschaftlich.

Wer Core Web Vitals ernst nimmt, verbessert nicht nur die Voraussetzungen für SEO. Er verbessert auch die Erfahrung echter Nutzer. Und genau dort entscheidet sich am Ende, ob eine Website nur erreichbar ist oder tatsächlich gut performt.