Core Web Vitals sind LCP, CLS und INP. Websites, die auf dem 75. Perzentil in allen drei Metriken im „Good“-Bereich liegen, verschaffen sich messbare Vorteile bei Nutzererlebnis und Suchsichtbarkeit. Die aktuellen Schwellenwerte lauten: LCP unter 2,5 Sekunden, INP unter 200 Millisekunden, CLS unter 0,1. Wer alle drei Werte konstant erreicht, verbessert nicht nur seine technische Grundlage, sondern auch die Ausgangslage im Wettbewerb um Sichtbarkeit.
Kurz gesagt:
- Eine Optimierung auf dem 75. Perzentil in den Core Web Vitals LCP unter 2,5 Sekunden, CLS unter 0,1 und INP unter 200 Millisekunden ist entscheidend für bessere Nutzererfahrungen und Sichtbarkeit.
- Bei LCP sind unoptimierte Bilder, langsame Serverantworten und render-blockierendes CSS die häufigsten Ursachen für schlechte Werte.
- INP misst die langsamste Nutzerinteraktion in der Sitzung und erfordert strukturelle Architekturverbesserungen, wenn es im roten Bereich liegt.
- Verbesserungen bei LCP und CLS sind meist kurzfristig durch Bild- und Rendering-Optimierungen realisierbar, INP-Optimierungen benötigen oft Wochen für echte Wirkung.
- Kontinuierliches Monitoring und der Einsatz von Labordaten sowie Felddaten helfen, die Maßnahmen effizient zu steuern und dauerhaft zu sichern.
Inhaltsverzeichnis
- Die drei Core Web Vitals im Detail: Messgegenstand, Symptome, Ursachen
- Wie misst man Core Web Vitals: Felddaten oder Labordaten?
- Welche Optimierungsschritte bringen den grössten Effekt?
- Was bringt die Optimierung von Core Web Vitals wirtschaftlich?
- Wie integriert man Performance-Monitoring dauerhaft in den Entwicklungsprozess?
- Outwork-Perspektive: Was in Projekten tatsächlich den Unterschied macht
- Core Web Vitals nachhaltig verbessern mit einem erfahrenen Entwicklungspartner
- Quellen
Die drei Core Web Vitals im Detail: Messgegenstand, Symptome, Ursachen
Der Largest Contentful Paint (LCP) misst, wie lange es dauert, bis das grösste sichtbare Element einer Seite geladen ist, meist ein Hero-Bild oder eine Überschrift. Schlechte Werte entstehen fast immer durch dieselben drei Ursachen: unoptimierte Bilder, eine langsame Time to First Byte (TTFB) oder render-blockierendes CSS und JavaScript im Ladepfad.
Cumulative Layout Shift (CLS) erfasst, wie stark sich Inhalte während des Ladens verschieben. Typische Auslöser sind Werbeanzeigen ohne reservierten Platz, nachträglich eingefügte DOM-Elemente und Web-Fonts, die erst spät nachladen und dabei den Textfluss verschieben.
Interaction to Next Paint (INP) hat 2024 den First Input Delay abgelöst und misst nicht mehr nur die erste, sondern die langsamste Interaktion über die gesamte Sitzung. Genau das macht INP 2026 zur unbequemsten Metrik: Ein einziger teurer Event-Handler kann den p75-Wert einer ganzen Seite ruinieren, selbst wenn alle anderen Interaktionen sauber laufen.
Wichtig für die Interpretation aller drei Werte:
- Google bewertet nicht den Durchschnitt, sondern das 75. Perzentil über echte Nutzer hinweg.
- Mobile und Desktop werden getrennt ausgewertet, oft mit deutlich unterschiedlichen Ergebnissen.
- Eine schlechte TTFB verhindert praktisch immer einen guten LCP-Wert, selbst bei optimierten Assets.
Wie misst man Core Web Vitals: Felddaten oder Labordaten?
Felddaten stammen aus dem Chrome User Experience Report (CrUX) und fliessen direkt in den Core Web Vitals Report der Search Console ein, der auf einem rollierenden 28-Tage-Fenster basiert und URLs nach Status gruppiert: Good, Verbesserungswürdig, Poor. Labordaten dagegen entstehen in kontrollierten Testumgebungen wie Lighthouse oder WebPageTest, ohne echte Nutzerstreuung.
Der entscheidende Unterschied: Felddaten sind retrospektiv und nicht in Echtzeit verfügbar, Labordaten dagegen sofort. Für die tägliche Arbeit ergibt sich daraus eine klare Reihenfolge:
- Nutzen Sie Lighthouse, PageSpeed Insights oder WebPageTest für sofortiges Debugging direkt nach einer Code-Änderung.
- Prüfen Sie nach einem Deployment die Search Console, um zu sehen, wie sich echte Nutzer verhalten, nicht nur ein synthetischer Testlauf.
- Rechnen Sie mit bis zu 28 Tagen, bis eine Verbesserung in den CrUX-Daten und damit im Ranking-Signal sichtbar wird.
- Ergänzen Sie beides mit der
web-vitals-JavaScript-Bibliothek, um eigene Real User Monitoring (RUM)-Daten direkt aus Ihrer Anwendung zu sammeln.
Priorisieren Sie mobile Messwerte. Die meisten Websites erhalten dort schlechtere Werte als auf Desktop, und Google bewertet beide Plattformen getrennt.
Welche Optimierungsschritte bringen den grössten Effekt?
Die Reihenfolge der Massnahmen entscheidet über den Return on Invest der nächsten Sprints. Ist INP deutlich im roten Bereich, sollte diese Metrik zuerst angegangen werden, weil sie am ehesten strukturelle Probleme in der Anwendungsarchitektur offenlegt. Ist INP dagegen unauffällig, lohnt sich die klassische Reihenfolge: zuerst LCP, dann CLS, erst danach Feinarbeit an INP.
Massnahmen für LCP:
- Bilder in AVIF oder WebP ausliefern statt in JPEG oder PNG
- Responsive
srcset-Attribute nutzen, damit mobile Geräte keine überdimensionierten Bilder laden - Kritisches CSS inline einbetten und den Rest asynchron nachladen
- Assets über ein CDN oder Edge-Netzwerk ausliefern
- TTFB der Serverantwort separat prüfen, bevor man Bildoptimierung als alleinige Lösung betrachtet
Massnahmen für CLS:
- Feste Breiten- und Höhenangaben für Bilder und Videos setzen
- Platzhalter für Werbeflächen und iframes reservieren, bevor der Inhalt lädt
- Web-Fonts mit
font-display: optionaloder vorab geladenen Font-Dateien einsetzen - DOM-Injektionen oberhalb bestehender Inhalte vermeiden
Massnahmen für INP:
- Lange Tasks im JavaScript identifizieren und in kleinere Einheiten aufteilen
- Code-Splitting einsetzen, damit nicht die gesamte Anwendung beim ersten Laden ausgeführt wird
- Rechenintensive Operationen in Web Worker auslagern
scheduler.yield()nutzen, um dem Haupt-Thread Luft zum Atmen zu geben- Third-Party-Skripte konsequent auditieren, da externe Tags oft die teuersten Handler verursachen
Profi-Tipp: Führen Sie vor jedem grösseren Release ein Long-Task-Profiling in den Chrome DevTools durch. Ein einzelner schlecht geschriebener Click-Handler in einem Drittanbieter-Skript reicht aus, um den gesamten INP-Wert einer Seite zu kippen, ganz gleich wie sauber der Rest des Codes ist.
Bildoptimierung und CDN-Anpassungen liefern häufig die schnellsten Erfolge, während Verbesserungen bei INP oft echte Architekturänderungen erfordern, etwa das Aufbrechen langer Tasks oder das Neuordnen von Event-Handlern. Rechnen Sie bei LCP- und CLS-Fixes mit Tagen, bei INP-Refactorings eher mit Wochen.
Was bringt die Optimierung von Core Web Vitals wirtschaftlich?
Fallstudien auf web.dev zeigen wiederholt, dass Verbesserungen bei den Core Web Vitals zu messbaren Steigerungen bei Conversion-Raten, organischem Traffic und Engagement führen. Wichtig für die Erwartungshaltung: Conversion-Effekte zeigen sich oft unmittelbar nach dem Deployment, während der organische Sichtbarkeitseffekt erst nach dem CrUX-Rollforward von vier bis acht Wochen messbar wird.
Für eine grobe ROI-Rechnung reichen wenige Inputs:
- Aktuelle Conversion-Rate und durchschnittlicher Bestellwert oder Lead-Wert
- Geschätzter Conversion-Lift nach LCP- oder INP-Verbesserung, konservativ angesetzt
- Monatlicher organischer Traffic als Basis für den Sichtbarkeitseffekt
- Zeithorizont von acht bis zwölf Wochen für die vollständige Wirkung
Wer diese Zahlen ins gleiche Dashboard wie die Geschäfts-KPIs einspeist, kann Performance-Arbeit gegenüber der Geschäftsleitung in Franken statt in Millisekunden begründen. Ein Performance-Budget in der CI-Pipeline, kombiniert mit monatlichen Reviews der Search-Console-Daten, verhindert, dass mühsam erkämpfte Verbesserungen beim nächsten Release wieder verschwinden. Wer die Auswirkungen auf die Leadgenerierung sauber nachverfolgen will, sollte Performance-Kennzahlen von Anfang an mit den Vertriebszahlen verknüpfen.
Wie integriert man Performance-Monitoring dauerhaft in den Entwicklungsprozess?
Eine belastbare Toolkette kombiniert die Search Console für Felddaten, Real User Monitoring für eigene Ereignisse, WebPageTest für tiefes Debugging und Lighthouse oder PageSpeed Insights für schnelle Checks vor jedem Release.
- Binden Sie die
web-vitals-JavaScript-Bibliothek ein und senden Sie die Ereignisse an Ihr Analytics-Tool. - Definieren Sie Performance-Budgets direkt in der CI-Pipeline, sodass ein Build fehlschlägt, wenn LCP oder INP über den Schwellenwert steigen.
- Legen Sie Rollback-Schwellen fest und testen Sie neue Releases zuerst gegen diese Werte, bevor sie live gehen.
- Richten Sie Alerts ein, die bei einer Verschlechterung der Felddaten automatisch das Entwicklungsteam informieren.
Eine zuverlässige Datengrundlage entsteht dabei nur, wenn Ereignisse serverseitig sauber erfasst werden. Ein technisches Audit deckt an dieser Stelle oft auf, wo Messwerte durch fehlerhaftes Tracking verfälscht werden.
Outwork-Perspektive: Was in Projekten tatsächlich den Unterschied macht
In der Praxis zeigt sich immer wieder dasselbe Muster: Teams investieren viel Zeit in Bildoptimierung, während der eigentliche Bremsklotz ein einzelnes Drittanbieter-Skript mit einem teuren Event-Handler ist. INP-Probleme lassen sich selten mit einem schnellen Fix lösen, sie verlangen ein ehrliches Audit der Architektur. Der wirksamste Ablauf bleibt einfach: erst ein Audit, das Field- und Labordaten gegenüberstellt, dann gezielte Implementierung, danach kontinuierliches Monitoring, damit der nächste Release die Fortschritte nicht wieder zunichtemacht.
— Outwork
Core Web Vitals nachhaltig verbessern mit einem erfahrenen Entwicklungspartner
Viele Unternehmen versuchen zuerst, Performance-Probleme intern mit Bordmitteln zu lösen, stossen aber bei INP-Refactorings oder Edge-Deployments schnell an Grenzen, die eigene Entwicklerkapazität nicht abdeckt. Outwork übernimmt die technische Umsetzung von der ersten Diagnose bis zum laufenden Monitoring: Performance-Audit, gezielte Implementierung von Massnahmen bei LCP, CLS und INP sowie der Aufbau eines Monitoring-Playbooks mit Performance-Budgets in der CI-Pipeline.
Das Ergebnis sind Websites, die nicht nur einmalig gute Werte erreichen, sondern sie über Releases hinweg halten, was sich direkt in Rankings und Conversion-Zahlen niederschlägt. Für Projekte, bei denen Performance-Probleme tief in der Architektur stecken, lohnt sich ein Blick auf individuelle Softwareentwicklung, etwa wenn ein bestehendes System grundlegend überarbeitet werden muss statt nur optimiert. Wer ein konkretes Projekt plant, kann über die Leistungsübersicht von Outwork ein unverbindliches Erstgespräch anfragen und erhält dabei eine erste Einschätzung, wo die grössten Hebel für die eigene Website liegen.
Quellen
Für die eigene Vertiefung eignen sich vor allem Web.dev für offizielle Definitionen, die Search Console für Felddaten und WebPageTest für detailliertes Lab-Debugging mit Waterfall-Analyse.
