Was sind Core Web Vitals?

Core Web Vitals sind eine Reihe spezifischer, messbarer Metriken, die Google verwendet, um die reale Nutzererfahrung einer Webseite zu bewerten. Sie konzentrieren sich auf drei grundlegende Aspekte, wie sich eine Seite für Besucher anfühlt: wie schnell der Hauptinhalt erscheint, wie schnell die Seite auf Interaktionen reagiert und wie stabil das Layout während des Ladens ist. Google verwendet Core Web Vitals seit Juni 2021 als offizielles Ranking-Signal in den Suchergebnissen, was bedeutet, dass diese Metriken direkt beeinflussen, wo deine WordPress-Seite in der Suche erscheint.

Die drei Core Web Vitals im Detail

Jede Core Web Vital misst eine andere Dimension der Nutzererfahrung, und jede hat einen spezifischen Schwellenwert, der "gut," "verbesserungsbedürftig" und "schlecht" definiert.

Largest Contentful Paint (LCP)

LCP misst, wie lange es dauert, bis das größte sichtbare Inhaltselement vollständig auf dem Bildschirm gerendert ist. Das ist typischerweise ein Hero-Bild, ein großer Textblock oder ein Video-Poster. Die Uhr startet, wenn der Nutzer die Seite aufruft, und stoppt, wenn das größte Element fertig gerendert ist.

Gut: 2,5 Sekunden oder weniger
Verbesserungsbedürftig: Zwischen 2,5 und 4,0 Sekunden
Schlecht: Mehr als 4,0 Sekunden

LCP ist die Metrik, die am direktesten die wahrgenommene Ladegeschwindigkeit widerspiegelt. Eine Seite kann eine schnelle Time to First Byte (TTFB) haben, aber trotzdem schlechtes LCP, wenn das größte Element lange zum Rendern braucht, sei es durch große Bilder, render-blockierende Ressourcen oder langsame Serverantworten für kritische Assets.

Interaction to Next Paint (INP)

INP hat First Input Delay (FID) im März 2024 als Core Web Vital abgelöst. Während FID nur die Verzögerung der allerersten Interaktion gemessen hat, misst INP die Reaktionsfähigkeit aller Interaktionen während des gesamten Lebenszyklus der Seite. Es verfolgt Klicks, Taps und Tastatureingaben und erfasst die Zeit von der Interaktion bis der Browser den Bildschirm tatsächlich aktualisiert. Der endgültige INP-Wert ist typischerweise die schlechteste beobachtete Interaktion (mit einigen Ausreißer-Anpassungen).

Gut: 200 Millisekunden oder weniger
Verbesserungsbedürftig: Zwischen 200 und 500 Millisekunden
Schlecht: Mehr als 500 Millisekunden

INP ist schwieriger zu optimieren als FID, weil es jede Interaktion abdeckt, nicht nur die erste. Eine Seite kann schnell auf den ersten Klick reagieren, aber später träge werden, wenn schweres JavaScript läuft.

Cumulative Layout Shift (CLS)

CLS misst, wie stark sich sichtbarer Inhalt unerwartet verschiebt, während die Seite lädt und während der Sitzung des Nutzers. Jedes Mal, wenn ein Element seine Position ändert, ohne dass der Nutzer es initiiert hat (zum Beispiel durch Klicken eines Buttons), trägt diese Verschiebung zum CLS-Wert bei. Der Wert wird berechnet, indem der Impact-Anteil (wie viel des Viewports betroffen ist) mit dem Distanz-Anteil (wie weit sich das Element bewegt hat) multipliziert wird.

Gut: 0,1 oder weniger
Verbesserungsbedürftig: Zwischen 0,1 und 0,25
Schlecht: Mehr als 0,25

CLS ist besonders frustrierend für Nutzer. Stell dir vor, du willst einen Button klicken, aber kurz bevor dein Klick landet, lädt eine Werbeanzeige darüber und schiebt den Button nach unten. Du klickst stattdessen auf die Werbung. Genau diese Art von Erfahrung misst CLS.

Wie Google Core Web Vitals als Ranking-Signal nutzt

Core Web Vitals sind Teil von Googles breiteren "Page Experience" Ranking-Signalen, die auch Mobilfreundlichkeit, HTTPS und das Fehlen aufdringlicher Zwischenseiten umfassen. Google bewertet Core Web Vitals anhand realer Nutzerdaten aus dem Chrome User Experience Report (CrUX). Das bedeutet, Google verwendet tatsächliche Felddaten von echten Chrome-Nutzern, die deine Seite besuchen, nicht Labordaten aus einem einzelnen Test. Die Ranking-Auswirkung gilt sowohl für mobile als auch für Desktop-Suchergebnisse. Während Inhaltsrelevanz der stärkste Rankingfaktor bleibt, können Core Web Vitals das Zünglein an der Waage sein, wenn Seiten mit ähnlicher Inhaltsqualität verglichen werden.

Core Web Vitals messen

Es gibt verschiedene Tools zur Messung von Core Web Vitals, und sie fallen in zwei Kategorien: Felddaten (echte Nutzermessungen) und Labordaten (simulierte Tests).

PageSpeed Insights: Googles Tool, das sowohl Felddaten (aus CrUX) als auch Labordaten (aus Lighthouse) anzeigt. Der Felddaten-Bereich zeigt die tatsächlichen Core-Web-Vitals-Werte basierend auf echten Nutzern der letzten 28 Tage. Das ist der wichtigste Bereich, weil er widerspiegelt, was Google fürs Ranking verwendet.
Google Search Console: Der Core-Web-Vitals-Bericht gruppiert deine URLs nach Status (gut, verbesserungsbedürftig, schlecht) basierend auf echten Nutzerdaten. Er hilft dir, Muster über deine gesamte Seite zu erkennen.
Chrome User Experience Report (CrUX): Der Rohdatensatz, der PageSpeed Insights und Search Console speist. Du kannst ihn direkt über die CrUX-API oder BigQuery abfragen.
Lighthouse: Ein Labortesttool in den Chrome DevTools. Es simuliert Seitenladevorgänge über eine gedrosselte Verbindung und meldet LCP und CLS (INP erfordert echte Nutzerinteraktion und kann unter Laborbedingungen nicht zuverlässig gemessen werden). Nützlich zum Debuggen, spiegelt aber nicht die echte Nutzererfahrung wider.
Web Vitals Chrome-Erweiterung: Eine Browser-Erweiterung, die Echtzeit-Core-Web-Vitals-Werte beim Surfen anzeigt, was das Erkennen von Problemen während Entwicklung und Testing erleichtert.

Echte Nutzerdaten vs Labordaten

Diese Unterscheidung ist wichtiger, als viele Seitenbetreiber denken. Labordaten (aus Lighthouse oder ähnlichen Tools) simulieren einen Seitenladevorgang unter kontrollierten Bedingungen: ein bestimmtes Gerät, eine bestimmte Netzwerkgeschwindigkeit und ein bestimmter Standort. Sie sind nützlich zum Debuggen und Identifizieren technischer Probleme, spiegeln aber nicht wider, was echte Besucher erleben. Echte Nutzerdaten (Felddaten) kommen von tatsächlichen Chrome-Nutzern, die deine Seite besuchen. Sie erfassen die volle Bandbreite an Geräten, Netzwerkgeschwindigkeiten und geografischen Standorten deiner Besucher. Googles Ranking-Algorithmus verwendet Felddaten, nicht Labordaten. Eine Seite kann 95 in Lighthouse erreichen, aber trotzdem schlechte Core Web Vitals im Feld haben, weil echte Nutzer auf langsameren Geräten eine andere Erfahrung machen.

Häufige WordPress-Probleme beim LCP

WordPress-Seiten haben häufig LCP-Probleme aufgrund mehrerer typischer Ursachen:

Große, unoptimierte Hero-Bilder: Ein 3 MB Hero-Bild braucht viel länger zum Herunterladen und Rendern als eine korrekt komprimierte 200 KB WebP-Version. Komprimiere Bilder immer, verwende moderne Formate (WebP oder AVIF) und liefere passend dimensionierte Bilder für den Bildschirm des Besuchers.
Render-blockierendes CSS und JavaScript: Wenn der Browser CSS- oder JavaScript-Dateien im <head> findet, muss er sie herunterladen und parsen, bevor er Inhalte rendern kann. Zu viele oder zu große Stylesheets verzögern LCP erheblich. Inline kritisches CSS und verschiebe nicht-essentielle Stylesheets.
Langsame Serverantwortzeit (TTFB): Wenn dein Hosting-Server 2 Sekunden braucht, nur um das HTML zu generieren, kann dein LCP unmöglich unter 2,5 Sekunden liegen. Upgrade dein Hosting, aktiviere serverseitiges Caching und nutze ein CDN.
Zu viele Plugins: Jedes Plugin fügt potenziell CSS und JavaScript zu jeder Seite hinzu. Seiten mit 30+ aktiven Plugins haben oft Dutzende render-blockierender Ressourcen, die um Bandbreite konkurrieren.
Fehlendes fetchpriority-Attribut: Das LCP-Element sollte fetchpriority="high" haben, um dem Browser zu signalisieren, es zuerst herunterzuladen.

Häufige WordPress-Probleme beim INP

INP-Probleme in WordPress lassen sich meist auf JavaScript-Ausführung zurückführen:

Schweres JavaScript von Plugins: Slider, Popups, Analysetools, Chat-Widgets und Social-Sharing-Plugins fügen alle JavaScript hinzu, das auf dem Main Thread läuft. Wenn ein Nutzer irgendwo klickt, muss der Browser möglicherweise erst andere Skripte fertig ausführen, bevor er reagieren kann.
Drittanbieter-Skripte: Google Analytics, Facebook Pixel, Werbeskripte und Live-Chat-Tools führen oft lange Aufgaben aus, die den Main Thread blockieren. Das Laden dieser Skripte mit async oder defer hilft, aber sie verbrauchen trotzdem Rechenzeit.
Übermäßige DOM-Größe: Seiten mit Tausenden von DOM-Elementen (häufig bei Page Buildern wie Elementor oder Divi) brauchen länger, bis der Browser bei Interaktionen Aktualisierungen durchführen kann. Ein Klick, der eine CSS-Klasse ändert, kann teure Style-Neuberechnungen über Tausende von Elementen auslösen.
Lange Main-Thread-Aufgaben: Jede JavaScript-Aufgabe, die länger als 50 Millisekunden läuft, gilt als "lange Aufgabe," die die Reaktionsfähigkeit blockiert. Das Aufteilen großer Aufgaben in kleinere Teile kann helfen.

Häufige WordPress-Probleme beim CLS

Layoutverschiebungen auf WordPress-Seiten werden typischerweise verursacht durch:

Bilder ohne Breiten- und Höhenangaben: Wenn ein Bild ohne explizite Dimensionen lädt, weiß der Browser nicht, wie viel Platz er reservieren soll. Der Inhalt darunter verschiebt sich, wenn das Bild schließlich gerendert wird. Setze immer width- und height-Attribute auf Bilder (WordPress macht das automatisch für Bilder, die über die Mediathek hinzugefügt werden).
Web-Font-Loading: Benutzerdefinierte Schriftarten, die nach dem initialen Rendern laden, können dazu führen, dass Text umfließt, wenn die Schriftart eingewechselt wird. Verwende font-display: swap kombiniert mit Font-Preloading, um diesen Effekt zu minimieren, oder erwäge font-display: optional für nicht-kritische Schriftarten.
Werbeeinblendungen: Werbeanzeigen, die dynamisch laden, verschieben Inhalte. Reserviere Platz für Werbeplätze mit Containern fester Größe, auch bevor die Werbung lädt.
Dynamisch eingefügter Inhalt: Cookie-Consent-Banner, Newsletter-Popups und Benachrichtigungsleisten, die nach dem Seitenladen erscheinen, können Inhalte verschieben, wenn sie in den Dokumentenfluss eingefügt werden statt darüber gelegt zu werden.
Einbettungen und iframes ohne Dimensionen: YouTube-Videos, Tweets und andere eingebettete Inhalte ohne explizite Dimensionen verursachen Verschiebungen beim Laden.

Core Web Vitals für WordPress verbessern

Hier ist ein praktischer Ansatz zur Verbesserung jeder Metrik auf einer WordPress-Seite:

Für LCP: Bilder optimieren und komprimieren (WebP/AVIF verwenden), ein CDN nutzen, serverseitiges Caching aktivieren, kritisches CSS inline setzen, nicht-essentielles JavaScript verschieben und fetchpriority="high" zum LCP-Bild hinzufügen. Entferne ungenutzte Plugins, die render-blockierende Ressourcen hinzufügen.
Für INP: Unnötiges JavaScript auditieren und entfernen, Drittanbieter-Skripte verschieben, DOM-Größe reduzieren (leichtere Page Builder oder native WordPress-Blöcke erwägen) und lange JavaScript-Aufgaben in kleinere Teile aufbrechen. Nutze den Performance-Tab in den Chrome DevTools, um zu identifizieren, welche Skripte den Main Thread blockieren.
Für CLS: Explizite Dimensionen auf allen Bildern, Videos und iframes setzen. Schriftarten vorladen und font-display: swap verwenden. Platz für Werbung und dynamische Inhalte reservieren. Vermeide das Einfügen von Inhalten über bestehendem Inhalt nach dem Seitenladen.

Was InspectWP prüft

InspectWP analysiert mehrere Faktoren, die Core-Web-Vitals-Werte direkt beeinflussen. Es prüft HTTP-Komprimierung (die LCP beeinflusst), HTTP/2-Nutzung (die paralleles Laden von Ressourcen ermöglicht), die Anzahl der JavaScript- und CSS-Dateien (die Render-Blocking verursachen und sowohl LCP als auch INP beeinflussen können), Bildoptimierungsmöglichkeiten, HTML-Dokumentgröße und andere performance-relevante Indikatoren. Das gibt dir ein klares Bild davon, was verbessert werden muss, um bessere Core-Web-Vitals-Werte zu erreichen.