Core Web Vitals und Web-Performance: Ladezeiten messen und optimieren
Eine langsame Website kostet Sie Besucher, Umsatz und Sichtbarkeit bei Google. Web-Performance ist längst kein technisches Nischenthema mehr, sondern ein direkter Geschäftsfaktor. Mit den Core Web Vitals hat Google konkrete, messbare Kennzahlen etabliert, an denen sich die Nutzererfahrung Ihrer Seite festmachen lässt. In diesem Artikel erkläre ich Ihnen, was hinter LCP, INP und CLS steckt, welche Schwellenwerte gelten, mit welchen Werkzeugen Sie Ihre Ladezeiten zuverlässig messen und mit welchen Techniken Sie sie technologieübergreifend verbessern.
Warum Web-Performance heute zählt
Performance wirkt sich auf drei zentrale Bereiche aus: die Nutzererfahrung, die Sichtbarkeit in Suchmaschinen und Ihre Conversion-Rate. Diese drei Faktoren hängen eng zusammen und verstärken sich gegenseitig. Wer das eine vernachlässigt, verliert auch bei den anderen.
Aus Sicht der Nutzererfahrung ist der Zusammenhang offensichtlich: Besucher erwarten heute, dass Inhalte praktisch sofort erscheinen. Jede zusätzliche Sekunde Wartezeit erhöht die Wahrscheinlichkeit, dass jemand abspringt, bevor er überhaupt mit Ihrer Seite interagiert hat. Eine träge reagierende Oberfläche, bei der Klicks ins Leere zu laufen scheinen, frustriert genauso wie Inhalte, die beim Laden noch herumspringen.
Beim Thema SEO ist Performance seit Juni 2021 ein offizieller Rankingfaktor. Google hat die Core Web Vitals zunächst für mobile Suchergebnisse eingeführt und im Februar 2022 auf die Desktop-Suche ausgeweitet. Sie sind Teil des sogenannten Page-Experience-Signals. Bei zwei inhaltlich gleichwertigen Seiten kann die bessere Performance den Ausschlag geben, welche Seite weiter oben erscheint. Performance ist also kein alleiniger Garant für gute Rankings, aber ein handfester Vorteil im Wettbewerb.
Und schließlich die Conversion: Schnellere Seiten führen messbar zu mehr abgeschlossenen Käufen, Anmeldungen und Kontaktanfragen. Performance ist damit eine der wenigen technischen Maßnahmen, die sich direkt in barer Münze auszahlen. Eine Investition in schnellere Ladezeiten ist eine Investition in Ihren Umsatz.
Was sind Core Web Vitals?
Die Core Web Vitals sind eine von Google definierte Auswahl von Kennzahlen, die die tatsächliche Nutzererfahrung einer Webseite quantifizieren. Sie konzentrieren sich auf drei Aspekte, die für den Eindruck einer Seite entscheidend sind: Wie schnell erscheint der Hauptinhalt, wie schnell reagiert die Seite auf Eingaben und wie stabil bleibt das Layout während des Ladens. Für jeden dieser Aspekte gibt es genau eine Hauptmetrik.
Die drei Core Web Vitals sind Largest Contentful Paint (LCP) für die Ladegeschwindigkeit, Interaction to Next Paint (INP) für die Reaktionsfähigkeit und Cumulative Layout Shift (CLS) für die visuelle Stabilität. Diese Auswahl ist nicht in Stein gemeißelt. Google passt sie an, wenn neue Messmethoden bessere Aussagekraft bieten. Das prominenteste Beispiel dafür ist die Ablösung von First Input Delay durch INP.
Hinweis: Am 12. März 2024 hat Google die Metrik First Input Delay (FID) endgültig durch Interaction to Next Paint (INP) ersetzt. INP ist deutlich aussagekräftiger, weil es nicht nur die allererste Interaktion misst, sondern die Reaktionsfähigkeit über den gesamten Seitenbesuch hinweg betrachtet. Wenn Sie irgendwo noch von FID lesen, handelt es sich um veraltete Information.
Wichtig zu verstehen: Google bewertet diese Metriken am sogenannten 75. Perzentil der realen Besucher. Das bedeutet, dass mindestens 75 Prozent Ihrer tatsächlichen Nutzer einen guten Wert erleben müssen, damit eine Seite als „gut“ eingestuft wird. Ein guter Durchschnittswert reicht nicht. Es geht um die Erfahrung der großen Mehrheit, nicht um den Idealfall unter Laborbedingungen.
Die drei Metriken im Detail
Um Performance gezielt zu verbessern, müssen Sie verstehen, was jede Metrik genau misst und welche Faktoren sie beeinflussen. Erst dann lassen sich die richtigen Hebel finden. Schauen wir uns die drei Kennzahlen einzeln an.
Largest Contentful Paint (LCP)
LCP misst, wie lange es dauert, bis das größte sichtbare Inhaltselement im sichtbaren Bereich gerendert ist. Das ist typischerweise ein großes Bild, ein Video-Vorschaubild oder ein umfangreicher Textblock. Diese Metrik beantwortet die Frage: Wann sieht der Nutzer den wesentlichen Inhalt der Seite? Ein guter LCP liegt bei 2,5 Sekunden oder weniger. Werte zwischen 2,5 und 4,0 Sekunden gelten als verbesserungswürdig, alles darüber als schlecht.
Die häufigsten Ursachen für einen schlechten LCP sind eine langsame Serverantwortzeit, große und unoptimierte Bilder, render-blockierendes CSS oder JavaScript sowie clientseitiges Rendering, das den Hauptinhalt erst spät aufbaut. Wer den LCP verbessern will, beginnt fast immer beim LCP-Element selbst und beim Weg, den die Daten bis dorthin nehmen.
Interaction to Next Paint (INP)
INP misst die Reaktionsfähigkeit der Seite über den gesamten Besuch hinweg. Konkret erfasst die Metrik, wie lange es nach einer Nutzerinteraktion wie einem Klick, einem Tippen oder einem Tastendruck dauert, bis der Browser die nächste visuelle Aktualisierung darstellt. Anders als das alte FID berücksichtigt INP den kompletten Ablauf: die Eingabeverzögerung, die Verarbeitungszeit und die Darstellungsverzögerung. Ein guter INP liegt bei 200 Millisekunden oder weniger. Werte zwischen 200 und 500 Millisekunden sind verbesserungswürdig, darüber liegt der schlechte Bereich.
INP ist die Metrik, an der die meisten Seiten scheitern. Der Hauptgrund ist fast immer zu viel JavaScript, das den Hauptthread blockiert. Wenn der Browser damit beschäftigt ist, große Skriptmengen auszuführen, kann er nicht gleichzeitig auf Nutzereingaben reagieren. Lange Tasks, ineffiziente Event-Handler und schwere Drittanbieter-Skripte sind die typischen Verdächtigen.
Cumulative Layout Shift (CLS)
CLS misst die visuelle Stabilität einer Seite, also wie stark sich Elemente während des Ladens unerwartet verschieben. Jeder kennt das ärgerliche Erlebnis, einen Button anklicken zu wollen, der im letzten Moment durch ein nachgeladenes Werbebanner verrutscht. Genau das erfasst CLS. Anders als die beiden anderen Metriken ist CLS kein Zeitwert, sondern ein dimensionsloser Wert. Ein guter CLS liegt bei 0,1 oder weniger, Werte zwischen 0,1 und 0,25 sind verbesserungswürdig, darüber liegt der schlechte Bereich.
Typische Auslöser für Layout-Verschiebungen sind Bilder ohne festgelegte Breiten- und Höhenangaben, dynamisch nachgeladene Inhalte wie Banner oder Einbettungen sowie Webfonts, die beim Laden einen Schriftwechsel verursachen. Die gute Nachricht: CLS ist die am leichtesten zu beherrschende der drei Metriken, weil sich die Ursachen meist klar benennen und beheben lassen.
Die Schwellenwerte im Überblick
Die folgende Tabelle fasst die Schwellenwerte für alle drei Core Web Vitals sowie zwei wichtige unterstützende Metriken zusammen. Sie ist Ihr Referenzpunkt für jede Performance-Bewertung.
| Metrik | Gut | Verbesserungswürdig | Schlecht |
|---|---|---|---|
| LCP (Ladegeschwindigkeit) | ≤ 2,5 s | 2,5 s bis 4,0 s | > 4,0 s |
| INP (Reaktionsfähigkeit) | ≤ 200 ms | 200 ms bis 500 ms | > 500 ms |
| CLS (visuelle Stabilität) | ≤ 0,1 | 0,1 bis 0,25 | > 0,25 |
| TTFB (Serverantwort) | ≤ 800 ms | 800 ms bis 1.800 ms | > 1.800 ms |
| FCP (erster Inhalt) | ≤ 1,8 s | 1,8 s bis 3,0 s | > 3,0 s |
Alle diese Werte werden, wie erwähnt, am 75. Perzentil der realen Nutzer gemessen. Ein einzelner schneller Testlauf auf Ihrem leistungsstarken Entwicklungsrechner sagt also wenig darüber aus, wie Ihre Seite tatsächlich bewertet wird.
Weitere wichtige Performance-Metriken
Die Core Web Vitals sind die Kennzahlen, auf die Google sein Ranking stützt. Für die Diagnose brauchen Sie aber weitere Metriken, die Ihnen verraten, wo genau ein Problem entsteht. Zwei davon haben Sie bereits in der Tabelle gesehen.
Time to First Byte (TTFB) misst die Zeit, bis der Browser das erste Byte der Serverantwort erhält. Diese Metrik bildet das Fundament aller anderen. Ist Ihr TTFB schlecht, können Sie das Frontend noch so sehr optimieren, der LCP wird trotzdem leiden. Als Faustregel gilt: TTFB unter 800 Millisekunden. Ein hoher TTFB deutet auf langsame Datenbankabfragen, fehlendes Caching oder eine überlastete Serverinfrastruktur hin.
First Contentful Paint (FCP) misst, wann der erste beliebige Inhalt sichtbar wird, sei es Text, ein Bild oder ein Hintergrund. FCP liegt zeitlich vor dem LCP und ist ein guter Frühindikator. Ein guter FCP liegt bei 1,8 Sekunden oder weniger. Daneben gibt es noch Total Blocking Time (TBT), die im Labor gemessen wird und eng mit dem INP korreliert, sowie Speed Index, der angibt, wie schnell der Inhalt visuell aufgebaut wird.
Wie man Performance richtig misst
Bevor Sie optimieren, müssen Sie messen. Dabei ist ein Konzept entscheidend, das viele übersehen: der Unterschied zwischen Labordaten und Felddaten. Wer beide verwechselt, zieht falsche Schlüsse.
Labordaten gegen Felddaten
Labordaten entstehen unter kontrollierten, simulierten Bedingungen: ein definiertes Gerät, eine festgelegte Netzwerkgeschwindigkeit, kein Cache, keine Browser-Erweiterungen. Werkzeuge wie Lighthouse erzeugen solche Daten. Der Vorteil: Die Tests sind reproduzierbar und eignen sich hervorragend, um konkrete Probleme zu finden und Optimierungen zu prüfen. Der Nachteil: Sie spiegeln nicht wider, was echte Nutzer auf echten Geräten erleben.
Felddaten dagegen stammen von realen Besuchern unter realen Bedingungen, mit unterschiedlichsten Geräten, Netzwerken und Standorten. Genau diese Daten verwendet Google für das Ranking. Sie werden im Chrome User Experience Report (CrUX) gesammelt. Entscheidend ist: Die Core-Web-Vitals-Bewertung im Ranking basiert ausschließlich auf Felddaten, nicht auf dem Lighthouse-Score. Ein Lighthouse-Wert von 100 bedeutet also nicht automatisch, dass Sie die Core Web Vitals bestehen.
Praxis-Tipp: Nutzen Sie Labordaten zum Diagnostizieren und Optimieren, aber bewerten Sie Ihren Erfolg immer an den Felddaten. Wenn Labor und Feld stark auseinanderlaufen, liegt das oft an INP. Diese Metrik lässt sich im Labor nur näherungsweise simulieren, weil echte Interaktionen fehlen.
Die wichtigsten Messwerkzeuge
Mein Rat: Wählen Sie ein Hauptwerkzeug für das fortlaufende Monitoring, in der Regel die Search Console für die Felddaten und PageSpeed Insights für Einzelprüfungen. Die übrigen Werkzeuge setzen Sie gezielt für die Tiefenanalyse ein, wenn Sie ein konkretes Problem eingrenzen müssen.
Typische Performance-Bremsen
In nahezu jedem Projekt, das ich auf Performance untersuche, tauchen dieselben Verdächtigen auf. Wer diese Muster kennt, findet die größten Hebel schnell. Die häufigsten Bremsen sind unoptimierte Bilder, die oft den Löwenanteil des übertragenen Datenvolumens ausmachen, sowie aufgeblähtes JavaScript, das den Browser ausbremst.
Hinzu kommen render-blockierende Ressourcen im Seitenkopf, die das erste Rendern verzögern, fehlendes oder falsch konfiguriertes Caching, das jeden Besucher die volle Ladezeit erleben lässt, und schwere Drittanbieter-Skripte für Tracking, Werbung oder Chat-Widgets. Gerade diese Drittanbieter-Skripte sind tückisch, weil sie sich Ihrer direkten Kontrolle entziehen und trotzdem voll auf Ihre Metriken durchschlagen. Eine langsame Serverinfrastruktur ohne CDN rundet das Bild ab.
Optimierungsstrategien im Detail
Kommen wir zum praktischen Teil. Die folgenden Strategien sind technologieübergreifend anwendbar, egal ob Ihre Seite auf WordPress, einem React-Frontend, einem klassischen PHP-Backend oder einem statischen Generator läuft. Ich gehe sie nach Themenbereichen sortiert durch.
Bilder optimieren
Bilder sind der größte Hebel für den LCP. Setzen Sie auf moderne Formate: AVIF bietet bei gleicher Qualität bis zu 50 Prozent kleinere Dateien als JPEG, WebP ist ein etwas konservativerer, aber breit unterstützter Kompromiss. Eine bewährte Strategie ist, AVIF als bevorzugtes Format anzubieten, WebP als Rückfall und JPEG als letzte Option, gesteuert über das picture-Element. Liefern Sie Bilder zusätzlich responsiv über das srcset-Attribut aus, damit mobile Geräte nicht die Desktop-Version laden.
Beim Lazy Loading ist eine Regel entscheidend: Bilder unterhalb des sichtbaren Bereichs werden mit dem Attribut loading=“lazy“ verzögert geladen, aber das LCP-Bild niemals. Wer sein wichtigstes Bild verzögert lädt, ruiniert seinen LCP-Wert. Das LCP-Element sollten Sie im Gegenteil oft mit fetchpriority=“high“ priorisieren, damit der Browser es so früh wie möglich anfordert.
JavaScript verschlanken
JavaScript ist der Hauptverursacher schlechter INP-Werte. Die wichtigste Maßnahme ist Code Splitting: Statt ein einziges riesiges Bundle auszuliefern, teilen Sie den Code in kleinere Stücke auf, die nur bei Bedarf geladen werden, etwa pro Route. Als Orientierung haben sich Chunk-Größen zwischen 100 und 200 KB gzip-komprimiert bewährt. Ergänzend entfernt Tree Shaking ungenutzten Code aus dem finalen Bundle.
Nicht kritische Skripte gehören mit den Attributen defer oder async versehen, damit sie das Rendern nicht blockieren. Drittanbieter-Skripte sollten Sie verzögert nachladen und kritisch hinterfragen, ob Sie jedes davon wirklich brauchen. Lange Aufgaben, die den Hauptthread blockieren, lassen sich in kleinere Häppchen aufteilen, sodass der Browser zwischendurch auf Nutzereingaben reagieren kann. Wenn Sie an clientseitige Zwischenspeicherung denken, können auch serverseitige Caching-Strategien zusätzliche Reserven heben.
CSS optimieren
CSS im Seitenkopf blockiert das Rendern vollständig: Der Browser zeigt nichts an, bevor das CSS geladen und verarbeitet ist. Die Lösung heißt kritisches CSS. Dabei extrahieren Sie genau die Stilregeln, die für den sichtbaren Bereich nötig sind, und betten sie direkt im head ein. Den Rest laden Sie asynchron nach. Das spart einen kompletten Roundtrip und verbessert FCP und LCP typischerweise um mehrere Hundert Millisekunden. Halten Sie das kritische CSS schlank, viele Seiten kommen mit 5 bis 15 KB komprimiert aus.
Schriften optimieren
Webfonts können sowohl den LCP als auch den CLS verschlechtern. Setzen Sie font-display: swap, damit der Text sofort mit einer Ersatzschrift erscheint und nicht unsichtbar bleibt, bis die Webschrift geladen ist. Laden Sie kritische Schriften mit preload vor und reduzieren Sie deren Umfang durch Subsetting, also das Entfernen nicht benötigter Zeichen. Variable Schriften bündeln mehrere Schnitte in einer Datei und sparen so weitere Requests. Um Layout-Verschiebungen durch den Schriftwechsel zu vermeiden, hilft eine sorgfältig abgestimmte Ersatzschrift.
Caching und CDN
Caching ist die wirkungsvollste Maßnahme gegen einen schlechten TTFB. Auf Serverseite vermeidet ein Page-Cache, dass jede Anfrage die volle Verarbeitung durchläuft. Ein Objekt-Cache entlastet die Datenbank. Im Browser sorgen korrekte Cache-Header dafür, dass wiederkehrende Besucher Ressourcen nicht erneut laden müssen. Ein Content Delivery Network (CDN) liefert statische Inhalte von einem Server in der Nähe des Besuchers aus, was Latenzen drastisch reduziert und die globale Auslieferung beschleunigt. Für jede Seite mit überregionalem Publikum ist ein CDN praktisch Pflicht.
Layout-Verschiebungen vermeiden
Den CLS bekommen Sie mit wenigen, klaren Regeln in den Griff. Geben Sie allen Bildern und Videos feste Breiten- und Höhenangaben oder ein definiertes Seitenverhältnis, damit der Browser den Platz reserviert, bevor das Medium geladen ist. Reservieren Sie auch für dynamisch nachgeladene Inhalte wie Banner oder Einbettungen festen Raum. Vermeiden Sie es, Inhalte oberhalb bereits sichtbarer Elemente einzufügen. Mit diesen Maßnahmen lässt sich ein CLS-Wert von 0,1 fast immer sicher einhalten.
Performance-Budget festlegen
Performance ist kein einmaliges Projekt, sondern eine Daueraufgabe. Ohne klare Leitplanken schleicht sich mit jedem neuen Feature und jedem zusätzlichen Skript wieder Ballast ein. Genau hier hilft ein Performance-Budget. Dabei legen Sie verbindliche Obergrenzen fest, etwa für die maximale JavaScript-Größe pro Seite, für das Gesamtgewicht einer Seite oder direkt für die Zielwerte der Core Web Vitals.
Der eigentliche Wert entsteht, wenn Sie dieses Budget automatisiert überwachen. In einer CI/CD-Pipeline lässt sich beispielsweise mit Lighthouse CI bei jedem Build prüfen, ob die Grenzen eingehalten werden. Überschreitet ein Pull Request das Budget, schlägt der Build fehl, und das Problem wird behoben, bevor es überhaupt in Produktion geht. So wird Performance vom nachträglichen Aufräumen zu einem festen Bestandteil des Entwicklungsprozesses.
Praxis-Tipp: Starten Sie mit einem realistischen Budget, das Sie aktuell knapp einhalten, und ziehen Sie die Grenzen schrittweise enger. Ein Budget, das von Anfang an unerreichbar ist, wird ignoriert. Ein Budget, das Sie gerade so schaffen, motiviert dazu, es zu halten.
Meine Praxis-Empfehlung
Wenn ich eine bestehende Seite optimiere, gehe ich immer in derselben Reihenfolge vor, weil sich so der größte Effekt bei geringstem Aufwand erzielen lässt. Diese Reihenfolge hat sich über viele Projekte bewährt.
Diese Vorgehensweise gilt unabhängig von der eingesetzten Technologie. Ob Sie auf eine moderne Architektur wie ein Headless CMS setzen, ein React-Frontend mit Next.js betreiben oder eine klassische Anwendung optimieren, die Prinzipien bleiben dieselben. Performance ist keine Frage des Frameworks, sondern der Sorgfalt. Betreiben Sie eine WordPress-Website, finden Sie die konkrete Umsetzung mit den passenden Plugins, Caching- und Hosting-Einstellungen in meinem Leitfaden zur WordPress-Performance-Optimierung.
Fazit
Die Core Web Vitals machen Web-Performance messbar und vergleichbar. LCP steht für die Ladegeschwindigkeit, INP für die Reaktionsfähigkeit und CLS für die visuelle Stabilität, jeweils mit klaren Schwellenwerten und gemessen an echten Nutzern am 75. Perzentil. Wer diese Kennzahlen versteht, kann gezielt optimieren statt blind an Stellschrauben zu drehen.
Meine Empfehlung: Messen Sie zuerst die Felddaten, arbeiten Sie sich vom Serverfundament über die Bilder bis zum JavaScript vor und sichern Sie das Ergebnis mit einem Performance-Budget ab. Performance ist kein einmaliges Projekt, sondern eine Disziplin, die sich in besseren Rankings, zufriedeneren Nutzern und höheren Conversion-Rates auszahlt. Der Aufwand lohnt sich, denn schnelle Seiten sind ein echter Wettbewerbsvorteil.
Ihre Website ist zu langsam?
Ich analysiere Ihre Core Web Vitals, finde die größten Performance-Bremsen und optimiere Ihre Ladezeiten gezielt. Lassen Sie uns gemeinsam Ihre Website schneller machen.
