So beheben Sie Core-Web-Vitals-Probleme: LCP, INP und CLS erklärt
Teste AuditMe live — kostenloser Sofort-Scan
Füge unten eine beliebige URL ein und erhalte in ca. 60 Sekunden ein echtes SEO-Ergebnis. Keine Registrierung nötig — dieselbe Engine, die in diesem Artikel beschrieben wird.
Was sind Core Web Vitals? (Und warum sie wirklich wichtig sind)
Core Web Vitals sind eine Reihe von Echtwelt-Metriken von Google, die die Nutzererfahrung auf Ihrer Website messen. Seit 2022 sind sie direkte Ranking-Faktoren. Im Jahr 2026 sind sie weiterhin entscheidend — sowohl für SEO als auch dafür, dass Nutzer nicht frustriert von Ihrer Seite abspringen.
Was ich jedem Kunden sage: Google ist es egal, wie hübsch Ihre Website ist. Google kümmert sich darum, wie schnell sie lädt, wie stabil sie sich anfühlt und wie schnell sie reagiert, wenn jemand auf eine Schaltfläche tippt. Genau diese drei Dinge messen die Core Web Vitals.
Die drei Metriken, um die Sie sich kümmern müssen, sind:
- LCP (Largest Contentful Paint) — Ladeleistung (wie schnell Ihr Hauptinhalt erscheint)
- INP (Interaction to Next Paint) — Interaktivität (wie reaktionsschnell sich Ihre Seite anfühlt)
- CLS (Cumulative Layout Shift) — Visuelle Stabilität (wie viel herumspringt, während die Seite lädt)
Es gibt auch FCP und TTFB, die wichtige unterstützende Metriken sind, aber LCP, INP und CLS sind die großen Drei, die Google tatsächlich für Rankings verwendet. Ich habe die letzten zwei Jahre damit verbracht, diese Metriken für Kunden zu beheben, und ich werde Ihnen genau zeigen, was funktioniert — keine Theorie, sondern das, was tatsächlich etwas bewegt hat.
LCP beheben (Ziel: Unter 2,5 s)
LCP misst, wie lange das größte sichtbare Element zum Rendern braucht. Bei den meisten Websites ist das das Hero-Bild oder ein großer Überschriftenblock. Google möchte es unter 2,5 Sekunden. Alles darüber hinaus kostet Sie sowohl Rankings als auch Nutzer. Für eine vollständige Aufschlüsselung der Diagnose und Behebung von LCP im Speziellen sehen Sie sich unseren LCP-Deep-Dive-Leitfaden an.
Ich habe letztes Jahr drei Wochen damit verbracht, den LCP eines WooCommerce-Shops eines Kunden zu verbessern. Die Produktseiten luden auf dem Handy in 6,8 Sekunden. Wir haben es auf 2,1 Sekunden reduziert. Genau so.
1. Bilder optimieren (Hier liegen die meisten Erfolge)
Bilder sind der Killer Nummer eins für LCP. Punkt. Ich habe noch nie eine Website mit schlechtem LCP-Score gesehen, die kein Bildproblem hatte.
- Konvertieren Sie in WebP- oder AVIF-Format. WebP liefert 40-80% kleinere Dateien als JPEG bei praktisch gleicher Qualität. AVIF ist sogar besser, aber die Browser-Unterstützung holt noch auf.
- Verwenden Sie responsive Bilder mit srcset, damit Handynutzer keine 4000px-Hero-Bilder auf einem 375px-Bildschirm herunterladen. Das ist reine Verschwendung.
- Lazy-loaden Sie Bilder unterhalb der Falz. Laden Sie das Footer-Bild nicht, bis jemand tatsächlich dorthin scrollt.
- Liefern Sie Bilder in passender Größe für den Viewport. Ein 1200px-breites Bild ist für den Desktop in Ordnung. Für das Handy reichen 400px völlig aus.
Was ich tatsächlich geändert habe: In diesem WooCommerce-Shop lieferten wir dieselben 2400px-Produktbilder an jedes Gerät aus. Wir verwendeten `html<img srcset="product-400.webp 400w, product-800.webp 800w, product-1200.webp 1200w" sizes="(max-width: 600px) 400px, (max-width: 1024px) 800px, 1200px" src="product-800.webp" alt="Product name">` und konvertierten alles nach WebP. Allein das senkte den LCP um 2,3 Sekunden.
2. Render-blockierende Ressourcen beseitigen
Ihr <head> lädt wahrscheinlich CSS und JavaScript, die das Rendern blockieren. Jede render-blockierende Ressource fügt Ihrem LCP Millisekunden hinzu.
- Deferen Sie nicht-kritisches CSS und JavaScript. Wenn es nicht für Inhalte oberhalb der Falz benötigt wird, deferen Sie es.
- Fügen Sie kritisches CSS für Styles oberhalb der Falz direkt im <head> ein. Das eliminiert eine render-blockierende Anfrage vollständig.
- Verwenden Sie rel="preload" für Ihr Hero-Bild und kritische Schriften. Sagen Sie dem Browser, diese sofort herunterzuladen, statt zu warten.
Was ich tatsächlich geändert habe: Ich fand drei CSS-Dateien im <head>, die render-blockierend waren. Zwei davon waren für einen Slider, der nur auf der Startseite erschien. Wir verschoben sie zu <link rel="preload" as="style" onload="this.rel='stylesheet'"> und fügten das kritische CSS oberhalb der Falz inline ein. Der LCP sank weitere 0,8 Sekunden.
3. Server-Antwortzeit verbessern
Wenn Ihr Server langsam ist, kämpft alles andere, was Sie tun, gegen einen starken Gegenwind.
- Verwenden Sie ein CDN (Cloudflare, Vercel Edge, Fastly). Es gibt 2026 keine Ausrede dagegen.
- Aktivieren Sie HTTP/2 oder HTTP/3. Mehrere Anfragen können über eine einzige Verbindung multiplexed werden.
- Optimieren Sie Datenbankabfragen im Backend. Aus meiner Erfahrung sind WooCommerce-Websites betroffen, bei denen eine einzelne Seite über 200 Datenbankabfragen auslöste.
- Implementieren Sie Caching-Strategien. Page Caching, Object Caching, Browser-Caching — nutzen Sie alle.
Was ich tatsächlich geändert habe: Derselbe WooCommerce-Kunde war auf Shared Hosting für 5 $/Monat. Allein sein TTFB betrug 1,8 Sekunden. Wir wechselten zu einem verwalteten WooCommerce-Host mit Server-Level-Caching und einem Cloudflare-CDN. Der TTFB sank auf 180 ms. Das war die größte einzelne LCP-Verbesserung, die wir erzielten.
4. Web-Schriften optimieren
Benutzerdefinierte Schriften sind schön, aber sie können Ihren LCP absolut ruinieren, wenn Sie nicht vorsichtig sind.
- Verwenden Sie font-display: swap, damit Text sofort mit einer Fallback-Schrift sichtbar ist und später durch die benutzerdefinierte Schrift ersetzt wird.
- Subsetten Sie Schriften, sodass sie nur die Zeichen enthalten, die Sie benötigen. Die meisten Websites brauchen keine kyrillischen, griechischen und vietnamesischen Zeichensätze.
- Laden Sie kritische Schriften mit <link rel="preload"> vor, damit der Browser sie früh holt.
Was ich tatsächlich geändert habe: Der Kunde lud drei verschiedene Schnitte einer Schriftfamilie (400, 600, 700) plus zwei verschiedene Schriftfamilien. Wir subsetteteten jede auf nur lateinische Zeichen und entfernten den leichten Schnitt. Die Schriftdateigrößen sanken von insgesamt 380 KB auf 85 KB.
Das endgültige LCP-Ergebnis
Nach all diesen Änderungen reduzierten wir den LCP auf dem Handy von 6,8 auf 2,1 Sekunden. Das ist eine Verbesserung von 70%. Der organische Traffic auf Produktseiten stieg in den nächsten zwei Monaten um 34%. Kein Zufall.
INP beheben (Ziel: Unter 200 ms)
INP (Interaction to Next Paint) ersetzte 2024 das First Input Delay (FID), und ehrlich gesagt ist es eine viel schwierigere Metrik, die man treffen muss. FID maß nur die Verzögerung vor der ersten Interaktion. INP misst, wie schnell Ihre Seite auf jede Interaktion während der gesamten Session reagiert. Wenn Sie einen einzigen langsamen Handler im Code versteckt haben, erwischt INP ihn.
Was Ihnen niemand über INP sagt: Die meisten Websites scheitern wegen JavaScript, das sie nicht selbst geschrieben haben. Third-Party-Skripte, Analyse-Tools, Chat-Widgets — das sind die stillen INP-Killer.
1. Lange Tasks aufteilen
Der Haupt-Thread des Browsers kann immer nur eine Sache gleichzeitig tun. Wenn ein JavaScript-Task länger als 50 ms dauert, blockiert er alles — Scrollen, Klicken, Rendern. Nutzer erleben das als Ruckeln.
- Teilen Sie die JavaScript-Ausführung mit requestIdleCallback oder setTimeout in Chunks unter 50 ms auf.
- Verwenden Sie requestIdleCallback für nicht dringende Arbeiten wie Analytik, Prefetching oder nicht-kritische UI-Updates.
- Implementieren Sie Code-Splitting und Lazy Loading, damit Nutzer nur das herunterladen, was sie für die aktuelle Seite benötigen.
Was ich tatsächlich geändert habe: Ich fand eine Produktseite, die beim Seitenladen einen 340-ms-JavaScript-Task ausführte — einen komplexen Preiskalkulator, der Steuern für 12 verschiedene Regionen berechnete. Niemand interagierte beim Laden damit. Wir verpackten ihn in requestIdleCallback und verschoben ihn, bis der Browser im Leerlauf war. Der INP sank von 420 ms auf 85 ms.
2. Event-Handler optimieren
Jeder Klick, jedes Tippen, Scrollen und Tastendrücken löst einen Event-Handler aus. Wenn dieser Handler zu viel Arbeit leistet, fühlt sich Ihre Seite träge an.
- Debouncen Sie Scroll- und Resize-Handler. Komplexe Logik bei jedem Scroll-Event auszuführen ist fast immer unnötig.
- Vermeiden Sie komplexe DOM-Manipulationen in Event-Callbacks. Bündeln Sie DOM-Reads und -Writes.
- Verwenden Sie passive Event-Listener, wo möglich (`htmladdEventListener('scroll', handler, { passive: true })`). Das lässt den Browser scrollen, während Ihr Handler läuft.
Was ich tatsächlich geändert habe: Ein Kunde hatte einen Sticky-Header, der seine Position bei jedem einzelnen Scroll-Event neu berechnete — ohne Debounce, ohne Throttle. Das sind hunderte Male pro Sekunde. Das Hinzufügen eines einfachen Debounce mit 16 ms Verzögerung behob es sofort. Der INP ging von 380 ms auf 120 ms.
3. Arbeit des Haupt-Threads reduzieren
Je weniger JavaScript Sie den Browser ausführen lassen, desto schneller kann er auf Interaktionen reagieren.
- Minimieren Sie die JavaScript-Bundle-Größe. Verwenden Sie Tree-Shaking, entfernen Sie ungenutzte Exports und analysieren Sie Ihr Bundle mit Tools wie webpack-bundle-analyzer.
- Entfernen Sie ungenutzte Polyfills und Legacy-Code. Wenn Sie IE11 nicht unterstützen, hören Sie auf, Polyfills dafür auszuliefern.
- Verwenden Sie Web Workers für schwere Berechnungen wie Datenverarbeitung, Bildbearbeitung oder komplexe Kalkulationen.
Was ich tatsächlich geändert habe: Nach einer Prüfung einer SaaS-Landingpage fand ich 400 KB JavaScript, die nie ausgeführt wurden. Es war eine Legacy-A/B-Testing-Bibliothek, die ersetzt, aber nie entfernt worden war. Das Löschen reduzierte das Bundle um 40%, und der INP verbesserte sich von 290 ms auf 110 ms.
Das endgültige INP-Ergebnis
Die meisten meiner Kunden landen nach der Optimierung bei einem INP zwischen 80 und 150 ms. Unter 200 ms ist bestanden, aber ich ziele auf unter 150 ms, um einen Sicherheitspuffer zu haben. Denken Sie daran: INP wird im 98. Perzentil gemessen — Ihre schlechtesten Interaktionen zählen mehr als Ihre durchschnittlichen.
CLS beheben (Ziel: Unter 0,1)
CLS misst die visuelle Stabilität — wie stark sich Ihr Seitenlayout nach dem Start des Ladens verschiebt. Denken Sie an den Moment, in dem Sie auf einen Link klicken wollen und darüber eine Anzeige lädt, die alles nach unten drückt. Das ist CLS, und Nutzer hassen es absolut.
Das größte CLS-Problem, das ich je sah, wurde durch eine Nachrichten-Website mit 14 verschiedenen Anzeigenblöcken verursacht, die asynchron geladen wurden. Die Seite verschob sich drei- oder viermal, bevor sie sich beruhigte. Ihr CLS-Score lag bei 0,45. Wir brachten ihn auf 0,03.
1. Explizite Abmessungen setzen
Wenn Sie dem Browser nicht sagen, wie groß ein Element sein wird, muss er raten. Und wenn der echte Inhalt lädt, verschiebt sich alles.
- Setzen Sie immer Breite und Höhe auf Bilder und Videos. Auch wenn Sie CSS für Responsiveness verwenden, braucht der Browser die intrinsischen Abmessungen, um das Seitenverhältnis zu berechnen.
- Verwenden Sie die CSS-Eigenschaft aspect-ratio für responsive Elemente: `htmlaspect-ratio: 16 / 9;`
- Reservieren Sie Platz für Anzeigen und Embeds. Ich verwende ein Platzhalter-Div mit den erwarteten Abmessungen, das die Anzeige beim Laden füllt.
Was ich tatsächlich geändert habe: Der Blog eines Kunden bettete YouTube-Videos nur mit dem iframe ein — ohne angegebene Abmessungen. Wir umschlossen jedes iframe mit einem Container mit aspect-ratio: 16 / 9; width: 100%; und setzten explizite width- und height-Attribute auf dem iframe. Der CLS sank von 0,28 auf 0,05.
2. Spät ladende Inhalte vermeiden
Alles, was nach dem ersten Seitenladen erscheint und Inhalt verschiebt, trägt zum CLS bei.
- Injizieren Sie nach dem Laden keinen Inhalt oberhalb bestehender Inhalte. Wenn es sein muss, reservieren Sie Platz dafür.
- Reservieren Sie Platz für dynamische Elemente wie Banner, Cookie-Hinweise und Chat-Widgets.
- Verwenden Sie Skeleton-Screens mit festen Abmessungen, damit sich das Layout nicht verschiebt, wenn echte Inhalte laden.
Was ich tatsächlich geändert habe: Die erwähnte Nachrichten-Website hatte ein Eilmeldungs-Banner, das 2-3 Sekunden nach dem Seitenladen erschien. Es schob den gesamten Artikel um 120px nach unten. Wir gaben dem Banner Platz über einen CSS-Platzhalter: `html<div class="banner-slot" style="height: 120px;"></div>` — der Platz war immer da, er blieb nur leer, bis das Banner geladen wurde.
3. Font Display Swap (strategisch) verwenden
Benutzerdefinierte Schriften können Layout-Verschiebungen verursachen, wenn sie laden — die Fallback-Schrift könnte eine andere Größe haben, sodass Text umfließt.
- Verwenden Sie font-display: swap für Fließtext. Der Text erscheint sofort in einer Fallback-Schrift und wechselt dann zur benutzerdefinierten Schrift.
- Verwenden Sie font-display: optional für nicht-kritische Schriften. Das eliminiert die Layout-Verschiebung vollständig — der Browser nutzt entweder die benutzerdefinierte Schrift oder bleibt bei der Fallback-Schrift, ohne Swap.
- Gleichen Sie die Metriken Ihrer Fallback-Schrift an. Verwenden Sie Tools wie fontaine, um Systemschriften zu finden, die Ihren Web-Schriften nahe kommen.
Was ich tatsächlich geändert habe: Ein Kunde hatte drei benutzerdefinierte Schriften, die allein durch Text-Reflow einen CLS von 0,12 verursachten. Wir verwendeten font-display: optional für die Überschriftenschrift (sie wurde nur in großen Größen verwendet, wo der Unterschied kaum auffiel) und gleichten die Fallback-Schriftmetriken mit CSS size-adjust an. Der CLS durch Schriftladen sank auf null.
Das endgültige CLS-Ergebnis
Die meisten CLS-Probleme stammen von Anzeigen, Bildern und dynamisch injizierten Inhalten. Beheben Sie diese drei Kategorien, und Sie landen in der Regel unter 0,1. Ich habe bei jedem Kunden, mit dem ich gearbeitet habe, den CLS bestanden — es ist meist die einfachste der drei Metriken, sobald man weiß, worauf man achten muss.
Was ich tatsächlich geändert habe (Zusammenfassung)
Die Realität ist — ich habe Ihnen gerade viel technischen Rat gegeben. Lassen Sie mich das auf das reduzieren, was wirklich einen Unterschied macht, in der Reihenfolge der Wirkung:
- Bilder — Konvertieren Sie zu WebP, setzen Sie explizite Abmessungen, verwenden Sie srcset, lazy-loaden Sie unterhalb der Falz. Das behebt LCP und CLS gleichzeitig.
- JavaScript — Entfernen Sie ungenutzten Code, deferen Sie nicht-kritische Skripte, teilen Sie lange Tasks auf. Das behebt INP.
- Server — Verwenden Sie ein CDN, aktivieren Sie Caching, upgraden Sie das Hosting bei Bedarf. Das behebt LCP und FCP.
- Schriften — Subsetten, vorladen und font-display strategisch einsetzen. Das behebt LCP und CLS.
- Layout-Stabilität — Setzen Sie überall Abmessungen, reservieren Sie Platz für dynamische Inhalte. Das behebt CLS.
Wenn Sie nur eine Sache tun, beheben Sie Ihre Bilder. Es ist die Änderung mit der höchsten Wirkung für den geringsten Aufwand. Aus meiner Erfahrung verbessert allein die Bildoptimierung den LCP um 2+ Sekunden bei bildlastigen Websites.
Tools zur Messung von Core Web Vitals
Sie können nicht beheben, was Sie nicht messen. Hier sind die Tools, die ich täglich verwende:
- Google PageSpeed Insights — Lab- und Felddaten. Kostenlos, zuverlässig und das, was Google tatsächlich verwendet.
- Chrome User Experience Report (CrUX) — Echtnutzer-Metriken von tatsächlichen Chrome-Nutzern. Das ist der Goldstandard für Felddaten.
- Search Console Core-Web-Vitals-Bericht — Zeigt URL-bezogene Probleme auf Ihrer gesamten Website. Ideal, um Seiten zu finden, die Aufmerksamkeit brauchen.
- AuditMe — Automatisierte CWV-Analyse mit konkreten Fix-Empfehlungen. Es sagt Ihnen nicht nur, was kaputt ist — es sagt Ihnen genau, was Sie ändern sollen.
- Chrome-DevTools-Performance-Panel — Für tiefe Einblicke in spezifische Interaktionen und das Identifizieren langer Tasks.
Mein Rat? Beginnen Sie mit PageSpeed Insights für einen schnellen Überblick und nutzen Sie dann die Search Console, um die größten Übeltäter Ihrer Website zu finden. Sobald Sie Problemseiten identifiziert haben, verwenden Sie das DevTools-Performance-Panel, um genau zu ermitteln, was das Problem verursacht. Für WordPress-Websites im Speziellen deckt unser Leitfaden zur Core-Web-Vitals-Optimierung für WordPress Plugin-für-Plugin-Fixes ab.
Verwandte Artikel
- Technische SEO-Checkliste 2026: Crawl, Index, Render, Rank
- Core Web Vitals für WordPress: Plugin-für-Plugin-Optimierungsleitfaden
- LCP-Deep-Dive: Die schwierigste Core Web Vital diagnostizieren und beheben
Testen Sie jetzt Ihre Core Web Vitals
Hören Sie auf zu raten und beginnen Sie zu messen. Führen Sie eine kostenlose Core-Web-Vitals-Analyse für jede URL durch. Sie erhalten eine Ampelbewertung für alle fünf Metriken plus konkrete, nach Wirkung sortierte Optimierungsschritte. Keine Anmeldung erforderlich — fügen Sie einfach Ihre URL ein und sehen Sie genau, wo Sie stehen.
Eduard Tymchenko
SEO Expert & Founder of AuditMe
“I built AuditMe after 10+ years of manual SEO audits — every check in this report is one I used to run by hand.”
Specializes in technical SEO, Core Web Vitals, and WordPress optimization.
Starte dein kostenloses SEO-Audit
Erhalte in 60 Sekunden eine vollständige SEO-Analyse beliebiger URLs. Keine Registrierung erforderlich.
Oder öffne das vollständige Analyse-Tool mit mehr Details
Deine Seite kostenlos analysierenKostenlose SEO-Tools
Verwandte Artikel
Lerne weiter mit diesen verwandten SEO-Anleitungen und Tutorials:
Your Website Was Seen 116,181 Times and Clicked 9 Times. Here's What Search Engines and AI Systems Are Actually Doing.
A first-party 2026 investigation from AuditMe into the Visibility Gap: how crawling, indexing, retrieval, ranking, AI citations, clicks, trust, and conversions form one measurable website intelligence system.
21 min read
How AI Systems Read the Web in 2026: Discovery, Retrieval, Citations and Agents
An evidence-first guide to AI search, GEO, retrieval, entity clarity, citations and agent-ready websites — with a practical framework, implementation patterns and a proposed open benchmark methodology.
45 min read
The New SEO: When Search Engines Stop Reading Websites and Start Using Them
Search is moving from ranking pages to running them as machine interfaces. This guide explains the six-dimension Website Intelligence framework — discoverability, understanding, verification, actionability, reliability, and observability — that makes your site machine-readable, verifiable, and actionable for AI search engines and agents.
23 min read
AI Readiness Guide: llms.txt, AI Bot Access & Semantic HTML for AI Search in 2026
Is your website ready for AI search? Complete guide to llms.txt, AI bot access, semantic HTML, and content architecture for ChatGPT, Claude, Perplexity, and Gemini in 2026.
24 min read