Die drei Core Web Vitals im Benchmark
Google bewertet Websites anhand von drei Metriken: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) und Cumulative Layout Shift (CLS). Jede Metrik hat einen klar definierten Schwellenwert, und nur wenn alle drei gleichzeitig eingehalten werden, gilt die Seite als bestanden. Die Bewertung basiert auf der 75. Perzentile der Felddaten aus dem Chrome User Experience Report (CrUX), also den tatsächlichen Erfahrungen realer Nutzer (Google).
Im Folgenden betrachten wir die aktuellen Benchmarkdaten, die auf Auswertungen von HTTP Archive, CrUX und eigenen XICTRAQ-Messdaten basieren. Die Werte beziehen sich auf die Medianwerte deutscher Websites, sofern nicht anders angegeben.
LCP: Largest Contentful Paint im Vergleich
Der LCP misst, wie lange es dauert, bis das größte sichtbare Inhaltselement im Viewport gerendert ist. Der Schwellenwert liegt bei 2,5 Sekunden. Der deutsche Durchschnitt liegt bei 3,2 Sekunden, also deutlich über der Schwelle. Die besten 10 % der Websites erreichen LCP-Werte von 1,4 Sekunden oder weniger (HTTP Archive).
Die Hauptursachen für schlechte LCP-Werte in Deutschland sind übergrosse Hero-Bilder ohne moderne Formate wie WebP oder AVIF, fehlende Server-seitige Caches bei WordPress-Installationen, langsame Shared-Hosting-Infrastrukturen mit hohem TTFB und render-blockierende CSS- und JavaScript-Ressourcen. Besonders WordPress-Websites, die rund 40 % des deutschen Marktes ausmachen (W3Techs), schneiden bei LCP unterdurchschnittlich ab, wenn keine gezielte Optimierung stattfindet.
Auf Mobilgeräten liegt der durchschnittliche LCP in Deutschland bei 3,8 Sekunden, auf Desktop bei 2,4 Sekunden (CrUX). Da Google Mobile-First indexiert, ist der mobile Wert für Rankings maßgeblich. Mehr zur mobilen Optimierung im Artikel über mobile Website-Geschwindigkeit.
LCP-Benchmarks nach Branche
| Branche | Median LCP | Bewertung |
|---|---|---|
| Unternehmens-Websites | 2.8s | Verbesserungsbedürftig |
| E-Commerce | 3.6s | Schlecht |
| Medien / Nachrichten | 3.9s | Schlecht |
| SaaS / Tech | 2.1s | Gut |
| Behörden / öffentlich | 4.2s | Schlecht |
| Handwerk / KMU | 3.4s | Verbesserungsbedürftig |
SaaS- und Technologie-Unternehmen schneiden am besten ab, weil sie häufig moderne Frameworks wie SvelteKit, Next.js oder Astro einsetzen, die Server-Side Rendering und statische Generierung von Haus aus unterstützen. E-Commerce-Websites leiden unter der Last von Produktbildern, Tracking-Scripts und komplexen Seitenstrukturen. Medienseiten laden oft Dutzende Third-Party-Scripts, die den LCP erheblich verzögern.
INP: Interaction to Next Paint im Vergleich
INP hat im März 2024 die First Input Delay (FID) als Core Web Vital abgelöst und misst die Reaktionsgeschwindigkeit einer Seite auf Nutzerinteraktionen. Der Schwellenwert liegt bei 200 Millisekunden. Der deutsche Durchschnitt liegt bei 287 Millisekunden, was eine deutliche Verfehlung darstellt. Nur rund 55 % der Websites weltweit halten den INP-Schwellenwert ein (HTTP Archive).
INP ist die schwierigste der drei Metriken, weil sie nicht nur die erste Interaktion, sondern alle Interaktionen während des gesamten Seitenaufenthalts bewertet. Eine einzelne langsame Reaktion, etwa beim Öffnen eines Dropdown-Menüs oder beim Abschicken eines Formulars, kann den gesamten INP-Wert verschlechtern. Hauptverursacher sind umfangreiche JavaScript-Bundles, die den Main Thread blockieren, sowie schlecht optimierte Event-Handler.
- JavaScript-Last reduzieren: Entfernen Sie ungenutzten Code durch Tree Shaking und Code Splitting. Jedes Kilobyte JavaScript muss nicht nur heruntergeladen, sondern auch geparst und ausgeführt werden.
- Long Tasks aufbrechen: Aufgaben, die länger als 50 Millisekunden den Main Thread blockieren, sollten mit
requestIdleCallback,setTimeoutoder dem Scheduler API in kleinere Einheiten aufgeteilt werden. - Rendering-Updates minimieren: Vermeiden Sie erzwungene Layout-Neuberechnungen (Forced Reflows) in Event-Handlern. Lesen Sie Layout-Eigenschaften nicht unmittelbar nach DOM-Änderungen.
- Web Worker nutzen: Rechenintensive Operationen wie Datenverarbeitung oder Bildmanipulation sollten in Web Worker ausgelagert werden, um den Main Thread freizuhalten.
Die Core-Web-Vitals-Optimierung im Detail zeigt weitere Strategien zur INP-Verbesserung. Mit dem Performance-Monitoring von XICTRAQ können Sie die INP-Entwicklung Ihrer Website kontinuierlich verfolgen.
CLS: Cumulative Layout Shift im Vergleich
CLS misst die visuelle Stabilität einer Seite und erfasst unerwartete Layout-Verschiebungen während des Seitenaufenthalts. Der Schwellenwert liegt bei 0,1. Der deutsche Durchschnitt liegt bei 0,18, was auf systematische Probleme mit nicht definierten Bildabmessungen, nachladenden Werbebannern und Web-Font-Wechseln hindeutet.
CLS ist die Metrik, die sich am einfachsten verbessern lässt, weil die Ursachen fast immer auf fehlende Abmessungsangaben zurückzuführen sind. Bilder und Videos ohne explizite width- und height-Attribute, iframes ohne definiertes Seitenverhältnis und dynamisch eingefügte Inhalte oberhalb des sichtbaren Bereichs sind die häufigsten Verursacher.
- Alle Bilder und Videos mit expliziten width/height-Attributen versehen
- CSS aspect-ratio für responsive Medienelemente nutzen
- Werbebanner und dynamische Inhalte mit reservierten Platzhaltern versehen
- Web Fonts mit font-display: swap und metrisch ähnlicher Fallback-Schrift laden
- Cookie-Consent-Banner als Overlay statt als eingefügtes Element implementieren
- Skeleton-Loading-States für asynchron geladene Inhalte verwenden
Benchmark nach Technologie: CMS und Frameworks im Vergleich
Die eingesetzte Technologie hat erheblichen Einfluss auf die Performance-Ausgangslage. Moderne Frameworks, die auf Server-Side Rendering oder Static Site Generation setzen, erreichen deutlich bessere Werte als traditionelle CMS-Installationen mit Plugin-Last.
| Technologie | LCP (Median) | INP (Median) | CLS (Median) | Bestanden (alle 3) |
|---|---|---|---|---|
| WordPress (ohne Cache) | 4.1s | 340ms | 0.22 | 12 % |
| WordPress (mit Cache+CDN) | 2.6s | 210ms | 0.12 | 35 % |
| Shopware CE | 3.3s | 280ms | 0.15 | 22 % |
| TYPO3 | 3.0s | 250ms | 0.14 | 28 % |
| SvelteKit / Astro | 1.6s | 85ms | 0.03 | 92 % |
| Next.js / Nuxt | 2.0s | 130ms | 0.06 | 75 % |
| Statische HTML-Seiten | 1.2s | 45ms | 0.01 | 98 % |
Die Daten zeigen eindrücklich: Reine statische HTML-Seiten und moderne Frameworks wie SvelteKit oder Astro erreichen nahezu perfekte CWV-Werte. WordPress kann mit gezielter Optimierung, Full-Page-Caching und CDN in den grünen Bereich gebracht werden, erfordert aber deutlich mehr Konfigurationsaufwand. Mehr zur Ladezeitoptimierung im vollständigen Ladezeit-Guide.
TTFB: Die vergessene Basiskennzahl
Time to First Byte (TTFB) ist zwar kein offizieller Core Web Vital, aber die Grundlage für alle anderen Metriken. Wenn der Server erst nach einer Sekunde antwortet, kann LCP unmöglich unter 2,5 Sekunden liegen. Der deutsche TTFB-Durchschnitt liegt bei 680 Millisekunden, wobei Shared-Hosting-Anbieter oft Werte über einer Sekunde aufweisen (HTTP Archive).
Der TTFB wird maßgeblich durch die Server-Infrastruktur bestimmt: Hosting-Qualität, Server-Software, Datenbankoptimierung und Caching-Strategien. Ein dedizierter Server oder Managed-Cloud-Hosting erreicht TTFB-Werte unter 200 Millisekunden, während ein überladenes Shared-Hosting regelmäßig über 800 Millisekunden liegt. Der umfassende Guide zur TTFB-Optimierung zeigt alle Stellschrauben im Detail.
Redis oder Varnish als Full-Page-Cache reduziert TTFB um 70-90 %. Einmal generierte Seiten werden direkt aus dem Arbeitsspeicher ausgeliefert.
Ein CDN platziert Inhalte auf Servern nahe beim Nutzer und reduziert die physische Distanz. Für DACH-Besucher sinkt die Latenz auf unter 20 Millisekunden.
Das QUIC-Protokoll eliminiert den TCP-Handshake und verkürzt den Verbindungsaufbau um einen Round-Trip. Besonders auf mobilen Netzwerken spürbar.
Indizierte Abfragen, Query-Caching und Connection Pooling verhindern, dass die Datenbank zum Flaschenhals wird. Object Cache (Redis) speichert häufige Abfragen.
Branchenvergleich: Wo steht Ihre Branche?
Performance-Anforderungen variieren stark nach Branche. E-Commerce-Websites müssen besonders schnell sein, weil jede Sekunde Verzögerung die Conversion-Rate um durchschnittlich 7 % senkt (Aberdeen Group). Dienstleister profitieren von schnellen Seiten durch mehr Kontaktanfragen. Medien-Websites kämpfen mit hohen Anzeigenlasten, die die Performance systematisch verschlechtern.
Der wirtschaftliche Hebel der Performance variiert ebenfalls: Für einen Online-Shop mit 500.000 Euro Jahresumsatz bedeutet eine Verdoppelung der Ladezeit potenziell 35.000 Euro weniger Umsatz pro Jahr (Aberdeen Group). Für eine Handwerker-Website mit 20 Anfragen pro Woche kann eine schnelle Seite den Unterschied zwischen einer und zwei zusätzlichen Anfragen pro Woche ausmachen. Der Downtime-Kostenrechner hilft, den wirtschaftlichen Wert der Verfügbarkeit zu beziffern.
Mobile vs. Desktop: Der Performance-Graben
Der Unterschied zwischen mobiler und Desktop-Performance ist in Deutschland besonders ausgeprägt. Auf dem Desktop bestehen 52 % der Websites alle drei CWV, auf Mobilgeräten nur 31 % (CrUX). Der Hauptgrund: Mobilgeräte haben langsamere Prozessoren, weniger Arbeitsspeicher und oft instabilere Netzwerkverbindungen. Zudem werden viele Websites primär für Desktop-Bildschirme optimiert und erst nachträglich für Mobilgeräte angepasst.
Da Google seit 2021 vollständig auf Mobile-First-Indexierung umgestellt hat (Google), sind die mobilen CWV-Werte für Rankings maßgeblich. Eine Website, die auf dem Desktop hervorragend abschneidet, aber auf dem Smartphone versagt, wird in den Suchergebnissen entsprechend abgewertet. Der ausführliche Guide zur mobilen Website-Geschwindigkeit zeigt, wie Sie die mobile Performance gezielt verbessern.
Eigene Werte messen und einordnen
Um Ihre eigene Website im Benchmark einzuordnen, benötigen Sie zuverlässige Messdaten. Einmalige Tests mit Lighthouse oder PageSpeed Insights geben einen ersten Eindruck, spiegeln aber nicht die reale Nutzererfahrung wider. Felddaten aus dem Chrome User Experience Report (CrUX) zeigen die tatsächliche Performance, erfordern aber ausreichend Traffic für statistisch belastbare Werte.
- Baseline ermitteln: Messen Sie Ihre aktuellen CWV mit PageSpeed Insights (Felddaten, sofern verfügbar) und Lighthouse (Labordaten) für alle wichtigen Seiten.
- Branchenvergleich anstellen: Vergleichen Sie Ihre Werte mit den oben genannten Branchenbenchmarks und identifizieren Sie die größten Abweichungen.
- Schwachstellen priorisieren: Konzentrieren Sie sich zuerst auf die Metrik mit der größten Abweichung vom Schwellenwert. In den meisten Fällen ist das LCP.
- Maßnahmen umsetzen: Nutzen Sie die Lighthouse-Empfehlungen und die konkreten Optimierungsanleitungen im Lighthouse-Guide als Roadmap.
- Kontinuierlich überwachen: Richten Sie automatisiertes Monitoring ein, um Fortschritte zu messen und Verschlechterungen sofort zu erkennen.
XICTRAQ ermöglicht diesen gesamten Prozess aus einer Plattform: Performance-Monitoring, Lighthouse-Audits, SEO-Tracking und Trendanalysen zeigen Ihnen jederzeit, wo Ihre Website im Vergleich steht. Die cookieless Analytics liefern dabei echte Nutzerdaten ohne DSGVO-Probleme.
Konkrete Optimierungsstrategie für den Aufstieg in die Top 10 %
Der Weg von durchschnittlicher Performance zu den Top 10 % erfordert keine revolutionären Änderungen, sondern die konsequente Umsetzung bewährter Maßnahmen. Die folgende Strategie ist nach Wirksamkeit priorisiert und deckt die häufigsten Probleme deutscher Websites ab.
- TTFB unter 200 ms bringen: Server-seitiges Full-Page-Caching einrichten, CDN aktivieren und Hosting evaluieren. Dieser eine Schritt verbessert LCP oft um 1-2 Sekunden.
- LCP-Element priorisieren: Das größte sichtbare Element identifizieren, mit fetchpriority=high und preload priorisieren, in WebP/AVIF ausliefern.
- JavaScript-Last halbieren: Ungenutzten Code entfernen, Third-Party-Scripts evaluieren und nur die wirklich nötigen behalten. Code Splitting für seitenspezifische Bundles nutzen.
- Layout-Stabilität sichern: Alle Bilder und Medien mit expliziten Abmessungen versehen, CSS aspect-ratio nutzen, Web Fonts mit font-display: swap laden.
- Komprimierung aktivieren: Brotli für statische Assets, Gzip als Fallback. Allein dieser Schritt reduziert die Transfergröße um 60-80 %.
- HTTP/2 oder HTTP/3 aktivieren: Die Umstellung ist bei modernen Webservern eine reine Konfigurationsänderung und beschleunigt paralleles Laden spürbar.
Performance als kontinuierlicher Prozess
Benchmarks sind keine einmalige Momentaufnahme, sondern ein fortlaufender Vergleichspunkt. Jedes CMS-Update, jedes neue Plugin und jede Design-Änderung kann die Performance verändern. Ohne kontinuierliche Überwachung bemerken Sie eine schleichende Verschlechterung erst, wenn die Rankings bereits gesunken sind.
XICTRAQ macht diesen Prozess automatisch. Das Uptime- und Performance-Monitoring misst Ihre Kernmetriken rund um die Uhr, vergleicht sie mit Branchenbenchmarks und warnt Sie bei Verschlechterungen. In Kombination mit dem Security-Scan, der DSGVO-Compliance-Prüfung und dem SEO-Monitoring erhalten Sie ein vollständiges Bild der Website-Gesundheit.
Starten Sie jetzt mit einer kostenlosen Demo oder registrieren Sie sich direkt, um Ihre Website-Performance dauerhaft im Blick zu behalten und systematisch zu verbessern.
Was sind gute Core Web Vitals Werte für 2026?
Wie viele deutsche Websites bestehen die Core Web Vitals?
Welche Metrik sollte ich zuerst optimieren?
Warum schneidet meine WordPress-Website schlecht ab?
Wie oft sollte ich Performance-Benchmarks prüfen?
Beeinflusst die Performance wirklich mein Google-Ranking?
Dieser Artikel basiert auf Daten von: (Aberdeen Group), Core Web Vitals (Google), (HTTP Archive), (W3Techs).