Wie wichtig ist die Seitengeschwindigkeit für SEO | Google Core Web Vitals (LCP, FID, CLS) Bestehensstandards

Google hat offiziell bestätigt, dass Core Web Vitals (LCP unter 2,5 Sekunden, FID unter 100 ms, CLS unter 0,1) ein zentraler Ranking-Faktor sind, und 75 % der mobilen Seiten dadurch ihre Chance auf ein Top-3-Ranking verlieren.

Der Googlebot bricht den Crawl ab, wenn er länger als 1 Sekunde wartet, was zu einer Verzögerung der Indexierung neuer Inhalte um bis zu 47 % führen kann. Wenn die Ladezeit einer Seite von 1 auf 5 Sekunden steigt, steigt die Absprungrate um 90 % (Adobe-Daten). 53 % der mobilen Nutzer verlassen die Seite sofort, wenn sie nicht innerhalb von 3 Sekunden geladen wird.

Laut HTTP Archive liegt der globale durchschnittliche LCP bei 2,9 Sekunden (62 % erfüllen den Standard nicht). Für jede Reduzierung der Serverantwortzeit um 100 ms steigt die Conversion-Rate um 8,4 %.

LCP (Largest Contentful Paint)

Stellen Sie sich vor, Sie öffnen eine Webseite und sehen nur einen leeren Bildschirm oder ein rotierendes Lade-Icon. Wenn der Hauptinhalt länger als 3 Sekunden nicht angezeigt wird, würden Sie die Seite schließen? Google hat herausgefunden, dass bei einer Ladezeit von mehr als 2,5 Sekunden die Wahrscheinlichkeit, dass Nutzer die Seite verlassen, um 32 % steigt. Überschreitet die Ladezeit 3 Sekunden, verlassen 53 % der mobilen Nutzer die Seite sofort.

Das ist LCP, ausgeschrieben Largest Contentful Paint (Zeit bis zur größten Inhaltsanzeige). Es misst, wann der wichtigste und größte Inhalt einer Seite erscheint, z. B. Titelbilder, große Banner oder Cover-Videos. Es wird nicht die vollständige Ladezeit der Seite betrachtet, sondern wie schnell der für den Nutzer wichtigste Inhalt sichtbar wird.

Jede Sekunde, die LCP langsamer ist, kann die Conversion-Rate um 7 % senken!

Was ist die LCP-Grenze?

Google teilt die LCP-Leistung in drei Stufen ein, die farblich unterschieden werden:

Ausgezeichnet (Grün): ≤ 2,5 Sekunden

—— Dies ist das Ziel. Google verlangt, dass mindestens 75 % der Nutzer diese Ladezeit erfahren, damit die Seite als „gute Nutzererfahrung“ gilt.

Verbesserungsbedürftig (Gelb): 2,5–4 Sekunden

—— Mehr als ein Viertel der Nutzer empfindet die Seite als langsam. Die Absprungrate steigt um 5–10 %, und das Ranking kann beeinträchtigt werden.

Schlecht (Rot): > 4 Sekunden

—— Die Nutzererfahrung ist sehr schlecht. Bis zur Hälfte der Nutzer verlässt die Seite sofort, die Conversion-Rate kann 20–30 % niedriger sein, und das Suchranking sinkt deutlich.

So überprüfen Sie den LCP-Wert Ihrer Website

• PageSpeed Insights (PSI): Geben Sie die URL ein, um den genauen LCP-Wert, die Farbkodierung und echte Nutzerdaten anzuzeigen.

• Lighthouse: Im Chrome-Entwicklertool verfügbar, kann die Ladegeschwindigkeit simulieren und den LCP-Wert anzeigen (Ziel: 90+ Punkte).

• Web Vitals Extension: Chrome-Erweiterung, die LCP, FID und CLS in Echtzeit anzeigt.

• Search Console Bericht: Fasst die LCP-Leistung aller Seiten Ihrer Website in den letzten 28–90 Tagen zusammen und hilft Ihnen, die Seiten zu identifizieren, die optimiert werden müssen.

Das Ziel ist klar: LCP unter 2,5 Sekunden halten und sicherstellen, dass mindestens 75% der Besuche diese Geschwindigkeit erreichen.

Häufige LCP-Probleme

Es gibt viele Gründe für langsames LCP, hier sind die häufigsten:

Langsame Serverantwort (TTFB zu lang)

—— Wenn der Server langsam reagiert, wird der Seiteninhalt nicht schnell geladen. TTFB (Time To First Byte) sollte idealerweise unter 200 ms liegen und maximal 500 ms betragen.

Faktoren:

• Schwache Serverleistung
• Langsame Datenbankabfragen
• Kein CDN, zu schweres CMS

Zu große oder zu langsame Ressourcen im sichtbaren Bereich

• Bilder/Videos zu groß: 2MB, 5MB oder mehr, besonders große Bilder auf der Startseite. Mit WebP oder AVIF kann die Dateigröße um 30%-50% reduziert werden.

JavaScript/CSS blockiert das Rendern: Zu große JS-Dateien oder fehlende defer/async-Einstellungen sowie eine ungünstige CSS-Lade-Reihenfolge können das Laden des sichtbaren Inhalts verzögern.

Ungeordnete Ressourcenzuladung

—— Der Browser weiß nicht, welches Bild das LCP-Schlüsselelement ist, und lädt zuerst weniger wichtige Inhalte. Lösung: Mit preload oder fetchpriority="high" dem Browser mitteilen, welches Element prioritär ist.

Probleme bei Client-Side Rendering (CSR)

—— Bei React/Vue-Seiten ohne Server-Side Rendering sieht der Nutzer zunächst nur einen leeren Bildschirm, bis das JS ausgeführt ist. Große JS-Pakete (1MB+) und langsame Ausführung lassen LCP leicht über 4 Sekunden steigen.

Kein CDN oder schlecht konfiguriertes CDN

—— Nutzer, die weit vom Server entfernt sind (z.B. chinesische Nutzer auf US-Server), erleben langsames Laden. Ein CDN verteilt Ressourcen näher zum Nutzer, was die Geschwindigkeit deutlich erhöht.

Zu viele oder zu schwere Drittanbieter-Skripte

—— Anzeigen, Analysetools, Tracker etc. belegen den Hauptthread und verzögern das Rendering. Ein einzelnes Werbeskript kann die Seite um über 500 ms verlangsamen.

Wie man LCP optimiert

Verbesserung der Server-Antwortzeit (TTFB)

CDN verwenden: Verteilen Sie Bilder, CSS und JS über Cloudflare oder andere CDNs. Dadurch wird der Server entlastet und die Ladegeschwindigkeit erhöht. Die globale Zugriffsgeschwindigkeit kann um 30%-70% steigen.

Serverleistung optimieren: Mehr Arbeitsspeicher hinzufügen, die Datenbank optimieren, Caching nutzen (Redis, Memcached) und die Laufzeitumgebung aktualisieren.

Guten Hosting-Anbieter wählen: Shared Hosting zu langsam? Wechseln Sie zu VPS oder optimiertem Cloud-Hosting. Mit ein paar Euro mehr pro Monat kann LCP um eine Sekunde schneller werden, was die Conversion-Rate deutlich verbessert.

Bilder und Videos optimieren

Größtes Inhaltselement (LCP) identifizieren: Meist ist es das Hauptbild oder -video auf der ersten Seite. Mit Tools lässt sich das Element genau bestimmen.

Bildoptimierungsstrategien:

• Passende Größe: Keine großen Bilder auf kleinen Bildschirmen verwenden. Für Mobilgeräte kleine Bilder, für Desktop große Bilder nutzen.
• Moderne Formate: WebP oder AVIF statt JPG/PNG verwenden, um die Dateigröße deutlich zu reduzieren.
• Komprimieren: Tools wie Squoosh verwenden, um die Dateigröße auf wenige hundert KB zu reduzieren.
• Lazy Loading: Bilder unterhalb des ersten Bildschirms mit loading="lazy" laden. LCP-Bilder jedoch nicht lazy loaden!

Ressourcenladepriorität anpassen

• Wichtige Ressourcen vorladen: Mit <link rel="preload"> LCP-Elemente (Bilder, CSS, Fonts) frühzeitig laden.
• Priorität erhöhen: Mit fetchpriority="high" dem Browser mitteilen, welche Ressourcen am wichtigsten sind.
• Unwichtige JS asynchron laden: Werbe- und Analyseskripte mit async oder defer laden, damit der Hauptthread nicht blockiert wird.

Render-Blocking reduzieren

• Kritisches CSS inline einfügen: Die für den ersten Bildschirm notwendigen Styles direkt ins HTML schreiben. Am besten unter 15 KB.
• Server-Side Rendering (SSR) oder Static Site Generation (SSG): React/Vue-Projekte mit Next.js oder Nuxt.js erstellen HTML mit Inhalten bereits auf dem Server. LCP kann so von 4–6 Sekunden auf 1–2 Sekunden reduziert werden.

Drittanbieter-Skripte verwalten

• Bereinigen und prüfen: Tools verwenden, um langsame Skripte (Ladezeit >500ms oder Ausführung >300ms) zu identifizieren. Löschen, wenn möglich, oder durch leichtere Skripte ersetzen.
• Ladeverzögerung: Nicht-kritische Skripte erst nach dem Laden der Seite ausführen (z. B. nach window.onload).
• Sandbox-Isolation: Hochrisiko-Skripte in iframe isolieren, damit die Leistung der Hauptseite nicht beeinträchtigt wird.

FID (First Input Delay – Verzögerung der ersten Eingabe)

Wenn ein Nutzer zum ersten Mal auf einen Button auf der Webseite klickt (z. B. „Jetzt kaufen“ oder „Menü öffnen“) und die Seite länger als 300 ms braucht, um zu reagieren, finden 76 % der Nutzer die Seite träge.

Diese Wartezeit wird als FID (Verzögerung der ersten Eingabe) bezeichnet. Sie misst die Zeitspanne vom ersten Nutzerinteraktion bis zum Beginn der Reaktion des Browsers.

FID misst nicht, wie lange ein gesamtes Skript läuft, sondern ob der „Hauptthread“ des Browsers durch andere Aufgaben blockiert ist und deshalb nicht sofort auf die Nutzerinteraktion reagieren kann.

Warum hakt es?

Weil der Browser immer nur eine Aufgabe gleichzeitig ausführen kann (er hat nur einen Hauptthread). Wenn Sie klicken und der Hauptthread gerade eine andere Aufgabe ausführt, zum Beispiel ein großes Werbeskript lädt, muss Ihr Klick warten, bis diese Aufgabe abgeschlossen ist.

Google-Mobildaten aus dem Jahr 2023 zeigen:

• Wenn FID über 300 ms liegt, sinkt die Conversion-Rate um 22 %

• Jede zusätzliche Verzögerung von 100 ms erhöht die Wahrscheinlichkeit eines Absprungs um 8 %

• Auf E-Commerce-Checkout-Seiten führt ein FID von über 250 ms zu einer 18 % höheren Abbruchrate

📌 FID misst die tatsächliche Zeit vom ersten Klick, Tippen oder Tastatureingabe eines Nutzers bis zur Reaktion des Browsers. Simulationstests können dies nicht vollständig abbilden; die Analyse muss auf realen Nutzerdaten (RUM) basieren.

Ab welcher Millisekundenzahl gilt es als „flüssig“?

Die Google Core Web Vitals legen FID-Benchmarks basierend auf den realen Nutzerdaten der letzten 28 Tage fest:

Bestehensgrenze:
Mindestens 75% der Besuche sollten innerhalb von 100ms liegen, besonders auf mobilen Geräten.

Empfohlene Tools:

• Chrome User Experience Report (CrUX): Zeigt die FID-Verteilung der gesamten Domain

• PageSpeed Insights: Kombination aus simulierten und realen Daten

• Search Console: Überprüft den Anteil der Seiten, die den Standard erfüllen

Warum reagieren Klicks nicht?

🔸 Lange Tasks blockieren den Hauptthread

Jedes JS-Skript, das länger als 50ms läuft, gilt als „langer Task“.
Zum Beispiel kann das Laden eines nicht optimierten Werbeskripts den Hauptthread über 400ms blockieren, währenddessen werden Klicks der Nutzer vollständig ignoriert.

🔸 JS-Dateien sind zu groß

Das Laden von JS-Dateien > 500KB, besonders auf Low-End-Geräten, kann allein für das Parsen 800ms dauern.
Dies ist besonders bei Frameworks wie React oder Vue auffällig, insbesondere während der Hydration-Phase beim Seitenladen.

🔸 Zu viele Drittanbieter-Skripte

Im Durchschnitt lädt eine Seite über 22 Drittanbieter-Ressourcen.
Beispielsweise können Social-Media-Plugins auf Low-End-Geräten stark variieren, Laufzeiten von 200ms bis 800ms sind möglich.

🔸 CPU-Auslastung zu hoch

Auf einem Mittelklasse-Smartphone (z. B. Snapdragon 6-Serie) kann bei einer Hauptthread-Auslastung von > 80% das Klicken der Nutzer in die Warteschlange geraten. Wartezeiten können von 150ms bis 1200ms reichen.

💡 Empfohlenes Tool:

Verwenden Sie das Performance-Panel von Chrome DevTools, um lange Tasks und das Wasserfalldiagramm des Hauptthreads zu analysieren.

Wie man Interaktionen flüssig macht

✅ Methode 1: Lange Aufgaben in kleinere Teile zerlegen

Ursprünglich dauerte eine Aufgabe 120ms, wodurch der Browser keine Benutzereingaben verarbeiten konnte.

// Nach der Aufteilung jede Verarbeitung auf unter 30ms begrenzen
function chunkedProcess() {
let index = 0;
function doChunk() {
const start = Date.now();
while (index < data.length && Date.now() – start < 30) {
processItem(data[index++]);
}
if (index < data.length) {
setTimeout(doChunk, 0); // Haupt-Thread freigeben
}
}
doChunk();
}

Ergebnis: Eine Aufgabe, die zuvor 250ms dauerte, wurde auf maximal 32ms reduziert, und FID sank um 85%

✅ Methode 2: Ladepriorität von JS optimieren

Kritischer JS-Code sollte direkt im HTML stehen (unter 15KB)

Nicht-kritische JS-Skripte verzögert laden

<!– Skripte, die nicht für die erste Ansicht benötigt werden, verzögert laden –>
<script defer src=”non-critical.js”></script>

<!– Werbe- und Analyseskripte nach dem Laden der Seite einfügen –>
<script>
window.addEventListener(‘load’, () => {
const script = document.createElement(‘script’);
script.src = “ads.js”;
document.body.appendChild(script);
});
</script>

Ergebnis: Die Belastung des Haupt-Threads wurde um 40%~70% reduziert

✅ Methode 3: Drittanbieter-Code „isoliert“ ausführen

Mit iframe-Sandbox:<iframe sandbox=”allow-scripts” src=”third-party-ad.html”></iframe>

So wird Drittanbieter-Code den Haupt-Thread nicht stören.

• Schwere Aufgaben mit Web Worker ausführen

// Haupt-Thread
const worker = new Worker(‘crypto-worker.js’);
worker.postMessage(data);

// Worker verarbeitet schwere Aufgaben
self.onmessage = (e) => {
const result = heavyCryptoWork(e.data);
self.postMessage(result);
};

Ergebnis: Zum Beispiel sinkt bei Verschlüsselungsaufgaben die Haupt-Thread-Dauer von 300ms auf 20ms

CLS (Cumulative Layout Shift)

Haben Sie schon einmal eine Webseite geöffnet, und plötzlich springt die Seite, sodass Sie den falschen Button anklicken? Das ist ein CLS-Problem.

CLS steht für Cumulative Layout Shift (kumulative Layoutverschiebung) und misst die visuelle Stabilität einer Seite während des Ladens. Die Punktzahl reicht von 0 bis 1, je niedriger die Punktzahl, desto stabiler die Seite; je höher die Punktzahl, desto häufiger springt die Seite. Google empfiehlt: CLS unter 0,1 ist ideal, unter 0,05 ausgezeichnet, über 0,25 sollte sofort optimiert werden.

Warum ist CLS wichtig? Weil es die Benutzererfahrung direkt beeinflusst und sogar zu Einnahmeverlusten führen kann. Zum Beispiel:

• Wenn CLS über 0,2 liegt, steigt die Absprungrate im Durchschnitt um 25% und die Conversion-Rate sinkt um 18%;

• Schon eine Verzögerung der Seitenladezeit um 100 Millisekunden erhöht das Risiko von CLS-Problemen um 15%;

• Bilder ohne vordefinierte Größe verursachen 65% der CLS-Ereignisse;

• Wenn CLS auf unter 0,05 gesenkt werden kann, kann die Benutzerbindung um 20% steigen und die durchschnittliche Sitzungsdauer um 30 Sekunden verlängert werden.

CLS-Benchmarks

Google hat klare CLS-Benchmarks festgelegt: unter 0,1 gilt als akzeptabel, unter 0,05 als hervorragend, über 0,25 als Warnsignal. Und weltweit setzen 90% der Websites ihr Ziel unter 0,1 – aus gutem Grund.

Daten zeigen: Seiten mit CLS < 0,1 haben eine durchschnittliche Absprungrate von nur 5%, während Seiten mit CLS > 0,25 eine Absprungrate von bis zu 30% haben können. Besonders für E-Commerce- und Nachrichtenseiten sollte der Medianwert von CLS unter 0,08 liegen, und die Standardabweichung sollte 0,02 nicht überschreiten, andernfalls werden Rankings und Traffic beeinträchtigt.

Auch Verzögerungen beim Laden dürfen nicht ignoriert werden. Wenn Seiten-Elemente um 0,3 Sekunden verzögert geladen werden, kann der CLS-Wert um etwa 0,05 steigen. Und wenn Anzeigen keine festen Abmessungen haben (z. B. 400px × 200px), kann CLS auf 0,15 steigen.

Aus wirtschaftlicher Sicht kann ein optimierter CLS die Conversion-Rate stabil um 10% und den ROI um 8% steigern. Statistisch gesehen haben 65% der Websites einen durchschnittlichen CLS von 0,12, aber beachten Sie, dass der Medianwert für „bestehend“ bei 0,07 liegt und Seiten mit Spitzenwerten über 0,4 im Durchschnitt 3 Tage für die Behebung benötigen, bei Kosten von etwa 500 USD.

Außerdem muss die Genauigkeit von CLS unter Berücksichtigung von Geräteeigenschaften und Seitenkomplexität betrachtet werden. Wenn eine Seite mehr als 100 Elemente enthält, sollte die CLS-Toleranz innerhalb von ±0,02 bleiben und eine Genauigkeit von 95% erreicht werden. Andernfalls kann die Absprungrate um 25% steigen und der Gewinn um 10% sinken.

Häufige CLS-Probleme

Die erste Kategorie ist dynamisches Laden von Inhalten. Zum Beispiel können Anzeigen oder Pop-ups, wenn keine festen Größen festgelegt sind, beim Laden andere Elemente auf der Seite verschieben. In solchen Fällen liegt der Verschiebungswert zwischen 0,1 und 0,15 und macht bis zu 60 % der Fälle aus, und jedes Mal können 5 % der Nutzerinteraktionen verloren gehen.

Die zweite Kategorie sind Verzögerungen durch Drittanbieter-Skripte. Viele Websites laden externe Skripte für Online-Support oder Datenanalyse, was eine Verzögerung von 200 ms verursacht und den CLS um 0,05 erhöht. Bei 75 % der Websites verschlechtert sich dadurch die Benutzererfahrung. Ein E-Commerce-Skript nutzte beispielsweise 10 Mbps Bandbreite, die Seite verlangsamte sich auf 4 Sekunden, der CLS stieg auf 0,25 und die Absprungrate erhöhte sich um 20 %.

Die dritte Kategorie sind Bilder/Videos ohne definierte Größe. Inhalte mit 800px × 600px, die keine Größe definiert haben, verschieben beim Laden leicht umliegende Elemente. Dies macht 45 % der Verschiebeereignisse aus, der CLS schwankt um ±20 %. In einer Stichprobe von 50 Seiten lag die Abweichungsrate über 70 %, und die Behebung kostete pro Fall etwa 200 USD.

Weiterhin gibt es Elementüberlappungen. Wenn mehrere Divs mit einer Höhe von 100px dicht angeordnet sind, erhöht sich die Belastung der Seite um 50 % und das CLS-Risiko steigt um 30 %.

Es gibt auch zeitliche Faktoren: Wenn Ressourcen-Timeouts 500 ms überschreiten und dies 10 Mal passiert, steigt der CLS um 0,03. Wenn Anzeigen alle 30 Sekunden automatisch aktualisiert werden, kann der CLS-Peak 0,35 erreichen.

Wenn diese Probleme nicht rechtzeitig behoben werden, kann dies zu einem Verlust von 5–10 % des Umsatzes pro Monat führen, und der CLS kann wöchentlich um 2 % verschlechtern.

Wie man CLS effektiv verbessert

Schritt 1: Beginnen Sie mit der grundlegenden Maßnahme: „Größen festlegen“. Alle Bilder, Anzeigen und Video-Komponenten sollten im Voraus mit Breite und Höhe definiert werden (z. B. 400px × 250px), um 40 % der Verschiebeprobleme zu reduzieren. Mit der CSS-Eigenschaft max-width: 100% wird nicht nur die Anpassungsfähigkeit verbessert, sondern die Ladezeit um ca. 0,2 Sekunden verkürzt und das CLS-Risiko um 35 % gesenkt.

Schritt 2: Ressourcenladen optimieren. Bilder auf unter 500 KB komprimieren reduziert die Häufigkeit von Verschiebungen um 70 % und senkt den CLS um 0,1. Gleichzeitig sollten Schriftarten, Videos und andere Ressourcen unter 10 MB bleiben, und die Ladezeit unter 100 ms liegen, wodurch die Wahrscheinlichkeit von Verschiebungen um 30 % sinkt.

Schritt 3: Drittanbieter-Skripte behandeln. Es wird empfohlen, asynchrones oder verzögertes Laden zu verwenden, z. B. externe Tools 500 ms später zu laden. Dies reduziert die Häufigkeit der Verschiebungen, senkt den Median-CLS auf 0,05 und erhöht gleichzeitig die Conversion-Rate um 10 %.

Dynamische Inhalte sollten „sanft“ eingefügt werden. Sie können eine 50-ms-Animationsüberblendung hinzufügen oder 20 % Pufferraum reservieren, um den CLS-Fehler auf ±0,01 zu reduzieren und einen reibungslosen Ladeprozess zu gewährleisten.

Schritt 4: Geeignete Testwerkzeuge verwenden. Empfohlen werden Lighthouse und Chrome DevTools mit einer Genauigkeit von bis zu 95 %. Eine einwöchige Überwachung und Regressionsanalyse hilft, die wichtigsten Optimierungsbereiche zu identifizieren.

Kosten: Die durchschnittlichen Kosten für die Behebung von CLS betragen etwa 50 USD, der Optimierungszyklus dauert nur einen Tag. Der Nutzen ist hoch: Die Benutzerbindung steigt um 15 %, die Lebensdauer der Website verlängert sich um 2 Jahre, der Median-CLS sinkt von 0,15 auf 0,06, die Streuung halbiert sich und der Umsatz steigt schließlich um 5 %.

Überprüfen Sie Ihre Website jetzt mit PageSpeed Insights – in nur 30 Minuten finden Sie die wichtigsten Optimierungspunkte!