Core Web Vitals optimieren – praktischer Leitfaden

Was sind Core Web Vitals?

Core Web Vitals sind drei von Google definierte Metriken, die die Nutzererfahrung einer Website quantifizierbar machen. Seit dem Page-Experience-Update 2021 nutzt Google sie in seinen Ranking-Systemen. Sie sind damit mehr als ein Nice-to-have, aber nur ein Signal unter mehreren.

Die drei Metriken im Überblick:

Wichtig: Alle drei Metriken müssen die "Gut"-Schwelle erreichen, damit Ihre Seite die Core-Web-Vitals-Bewertung besteht (gemessen am 75. Perzentil der Feld-Daten). Es reicht nicht, wenn nur eine oder zwei grün sind. Testen Sie Ihre Website jetzt mit unserem Performance-Checker und sehen Sie, wo Sie stehen.

Wie werden CWV gemessen?

Google unterscheidet zwischen Feld-Daten (echte Nutzer) und Lab-Daten (simuliert):

• Feld-Daten stammen vom Chrome UX Report (CrUX) und basieren auf anonymisierten Daten echter Chrome-Nutzer. Auf diesen Daten beruhen die Core-Web-Vitals-Berichte der Search Console.
• Lab-Daten werden von Tools wie Lighthouse, PageSpeed Insights oder WebPageTest in einer kontrollierten Umgebung gemessen. Sie sind ideal für die Diagnose und Optimierung.

Der wichtigste Unterschied: Feld-Daten zeigen, wie Ihre Website tatsächlich performt; Lab-Daten zeigen, wie sie unter idealen Bedingungen performt. Optimieren Sie für Lab-Daten, aber messen Sie den Erfolg an Feld-Daten.

Wie Google CWV für Rankings nutzt

Google hat 2021 mit dem Page-Experience-Update die Core Web Vitals in seine Ranking-Signale aufgenommen. Laut Google gibt es heute kein einzelnes Page-Experience-Signal, die Ranking-Systeme nutzen mehrere Signale, darunter die Core Web Vitals. Hier ist, was das konkret bedeutet:

Was wir wissen:

• CWV sind ein Ranking-Faktor, aber nicht der wichtigste. Relevanter Content wiegt schwerer, und gute Werte garantieren laut Google keine Top-Platzierung.
• Bei ansonsten gleichwertigen Seiten können CWV den entscheidenden Unterschied machen — besonders auf der ersten Seite der Suchergebnisse.
• Google nutzt die 75. Perzentile der Feld-Daten: Wenn 75% Ihrer Nutzer gute Werte erleben, gilt die Seite als bestanden.
• CWV werden pro URL bewertet, nicht pro Domain. Einzelne langsame Seiten beeinflussen nicht die gesamte Website.

Der Business-Impact:

• Vodafone steigerte den Umsatz um 8 %, nachdem der LCP um 31 % verbessert wurde (A/B-Test)
• Nykaa verbesserte den LCP um 40 % und erhielt 28 % mehr organischen Traffic aus Städten der Kategorien T2 und T3
• NIKKEI STYLE verbesserte den LCP um 18 % und erzielte 9 % mehr Seitenaufrufe pro Sitzung

In unserer Arbeit als Webdesign-Agentur sehen wir, dass sich Core Web Vitals je nach Konkurrenz und Inhalt unterschiedlich stark auf Rankings auswirken. Google betont, dass gute Werte keine Top-Platzierung garantieren.

LCP optimieren: Ladegeschwindigkeit verbessern

Der Largest Contentful Paint misst, wann das größte sichtbare Element im Viewport fertig geladen ist — typischerweise ein Hero-Bild, ein Video oder ein großer Textblock. Ziel: unter 2,5 Sekunden.

Die häufigsten LCP-Probleme und Lösungen

1. Unoptimierte Bilder (häufigstes Problem)

Bei rund 73 % der mobilen Seiten ist ein Bild das LCP-Element (HTTP Archive Web Almanac 2024), meist das Hero-Bild. Wenn es 2 MB groß ist und erst geladen wird, nachdem CSS und JavaScript verarbeitet wurden, ist ein guter LCP-Wert unmöglich.

Lösung:

2. Langsame Server-Response-Zeit (TTFB)

Wenn der Server über 800ms braucht, um die HTML-Datei auszuliefern, starten alle nachfolgenden Ressourcen verspätet.

Lösung:

• Wechsel zu besserem Hosting (Managed VPS statt Shared Hosting)
• CDN einrichten (Cloudflare, Fastly, AWS CloudFront)
• Server-Side Caching aktivieren (Varnish, Redis, Nginx Microcaching)
• Datenbank-Queries optimieren (Indexe, Query-Caching)

3. Render-blockierendes CSS und JavaScript

CSS und synchrones JavaScript im <head> blockieren das Rendering der Seite.

Lösung:

4. Third-Party-Scripts verzögern

Analytics, Chat-Widgets, Social-Media-Embeds und Werbung können den LCP erheblich verschlechtern.

Lösung: Laden Sie Third-Party-Scripts erst nach dem LCP-Event:

CLS optimieren: Layout-Verschiebungen verhindern

Der Cumulative Layout Shift misst, wie stark sich Elemente während des Ladevorgangs unerwartet verschieben. Jeder hat es schon erlebt: Sie wollen einen Button klicken, und im letzten Moment springt er weg, weil ein Werbebanner eingeblendet wird. Ziel: unter 0,1.

Die häufigsten CLS-Verursacher

1. Bilder und Videos ohne Dimensionen

Wenn der Browser die Größe eines Bildes nicht kennt, reserviert er keinen Platz. Sobald das Bild lädt, verschiebt sich der gesamte Content darunter.

Lösung:

2. Web-Fonts verursachen FOUT/FOIT

Wenn ein Web-Font geladen wird, kann der Text plötzlich seine Größe ändern (Flash of Unstyled Text) oder kurz verschwinden (Flash of Invisible Text).

Lösung:

Zusätzlich: Font-Dateien preloaden:

3. Dynamisch eingefügte Inhalte

Cookie-Banner, Newsletter-Popups und Lazy-geladene Elemente können Layout-Shifts verursachen, wenn kein Platz für sie reserviert ist.

Lösung:

4. Dynamische Werbung ohne Container-Größe

Lösung: Verwenden Sie feste Container-Größen für Werbeeinblendungen:

INP optimieren: Interaktivität beschleunigen

Interaction to Next Paint (INP) hat im März 2024 offiziell FID (First Input Delay) als Core Web Vital ersetzt. INP misst die Reaktionszeit auf alle Nutzer-Interaktionen (Klicks, Taps, Tastatureingaben) während des gesamten Seitenbesuchs — nicht nur die erste. Ziel: unter 200ms.

Warum INP anspruchsvoller ist als FID

FID maß nur die Verzögerung bei der ersten Interaktion. INP betrachtet jede Interaktion und nimmt den schlechtesten Wert (genauer: die 98. Perzentile). Das bedeutet: Auch wenn Ihre Seite beim ersten Klick schnell reagiert, aber beim zehnten Klick 500ms braucht, wird INP schlecht bewertet.

INP-Optimierungsstrategien

1. Long Tasks identifizieren und aufbrechen

JavaScript-Tasks, die länger als 50ms dauern, blockieren den Main Thread und verzögern Interaktionen.

Lösung mit `requestIdleCallback` und Task-Splitting:

2. Event-Handler optimieren

Teure Berechnungen in Event-Handlern (Scroll, Input, Resize) sollten gedebounct oder gethrottled werden.

3. Code-Splitting und Dynamic Imports

Laden Sie nur den Code, der tatsächlich gebraucht wird:

4. Web Workers für intensive Berechnungen

Tools zum Messen der Core Web Vitals

Die richtigen Tools sind entscheidend für eine erfolgreiche Optimierung. Hier unsere Tool-Empfehlungen:

Empfohlener Workflow:

1. Überblick: Google Search Console → CWV-Report prüfen
2. Analyse: PageSpeed Insights für die wichtigsten Seiten
3. Debugging: Chrome DevTools → Performance-Tab → Bottlenecks identifizieren
4. Monitoring: Web Vitals Extension für die tägliche Arbeit
5. Automatisierung: Lighthouse CI in die Build-Pipeline integrieren

Core Web Vitals Checkliste

Hier Ihre umfassende Checkliste, geordnet nach Priorität:

LCP-Checkliste

• [ ] Hero-Bild in WebP/AVIF komprimiert (unter 200KB)
• [ ] Hero-Bild mit fetchpriority="high" und Preload-Hint
• [ ] TTFB unter 800ms (gutes Hosting + CDN)
• [ ] Kritisches CSS inline im <head>
• [ ] Render-blockierendes JavaScript eliminiert (defer/async)
• [ ] Third-Party-Scripts nach LCP geladen
• [ ] Font-Preloading für Headline-Fonts
• [ ] Kein Lazy Loading für Above-the-Fold-Bilder

CLS-Checkliste

• [ ] Alle Bilder haben width und height Attribute
• [ ] font-display: swap für alle Web-Fonts
• [ ] Font-Metriken-Override (size-adjust, ascent-override)
• [ ] Feste Container-Größen für Ads und Embeds
• [ ] Cookie-Banner als Overlay (nicht Push-Element)
• [ ] Keine dynamisch eingefügten Inhalte ohne Platzhalter
• [ ] CSS aspect-ratio für responsive Container
• [ ] Keine späten DOM-Manipulationen im sichtbaren Bereich

INP-Checkliste

• [ ] Keine Long Tasks über 50ms im Main Thread
• [ ] Event-Handler gedebounct (Search, Scroll, Resize)
• [ ] Code-Splitting für nicht-kritische Module
• [ ] requestAnimationFrame für visuelle Updates
• [ ] Web Workers für intensive Berechnungen
• [ ] Minimale Bundle-Größe (Tree-Shaking, Dead Code Elimination)
• [ ] Third-Party-Scripts asynchron oder deferred
• [ ] Keine synchronen XHR-Requests

WordPress-spezifische Optimierungen

WordPress-Websites haben spezifische Performance-Herausforderungen. Hier sind die effektivsten Optimierungen:

1. Plugin-Audit durchführen

Das größte Performance-Problem bei WordPress: zu viele Plugins. Jedes Plugin fügt CSS, JavaScript und Datenbank-Queries hinzu.

Empfohlene Vorgehensweise:

• Deaktivieren Sie alle Plugins und messen Sie die Baseline-Performance
• Aktivieren Sie Plugins einzeln und messen Sie den Impact
• Entfernen Sie alles unter 1% Nutzungsrate
• Ersetzen Sie schwere Plugins durch leichtgewichtige Alternativen

Plugin-Empfehlungen für Performance:

2. Theme-Optimierung

Viele WordPress-Themes laden Hunderte KB an ungenutztem CSS und JavaScript. Page-Builder wie Elementor oder Divi sind besonders schwer.

Optimierungsansätze:

• Wechsel zu leichtgewichtigen Themes (GeneratePress, Kadence, Astra)
• Unused CSS entfernen (Perfmatters oder PurgeCSS)
• Page-Builder nur verwenden, wenn der Kunde Seiten selbst gestalten muss
• Custom Theme Development für maximale Performance

3. Server-Level-Optimierung

# .htaccess — Browser-Caching aktivieren <IfModule mod_expires.c> ExpiresActive On ExpiresByType image/webp "access plus 1 year" ExpiresByType image/jpeg "access plus 1 year" ExpiresByType text/css "access plus 1 month" ExpiresByType application/javascript "access plus 1 month" </IfModule> # GZIP-Kompression <IfModule mod_deflate.c> AddOutputFilterByType DEFLATE text/html text/plain text/css AddOutputFilterByType DEFLATE application/javascript application/json </IfModule>

Next.js-spezifische Optimierungen

Für Projekte, die wir mit Next.js und Payload CMS umsetzen, gelten andere Optimierungsstrategien:

1. Image-Optimierung mit next/image

2. Font-Optimierung mit next/font

3. Route-basiertes Code-Splitting

Next.js macht Code-Splitting automatisch pro Route. Zusätzlich:

4. Server Components (App Router)

5. Metadata und Streaming

Beispielszenarien zur Veranschaulichung

Fallstudie 1: Corporate Website (Next.js + Payload CMS)

Ausgangssituation:

• PageSpeed Mobile: 52/100
• LCP: 4,1s (unoptimiertes PNG-Hero, 3,2 MB)
• CLS: 0,22 (Fonts ohne swap, Bilder ohne Dimensionen)
• INP: 310ms (schwere Animations-Library)

Maßnahmen:

1. Hero-Bild: PNG → WebP, 3,2 MB → 120 KB, fetchpriority="high"
2. Alle Bilder mit next/image und festen Dimensionen
3. Font-Optimierung mit next/font (self-hosted, swap)
4. Framer Motion durch CSS-Transitions ersetzt (Bundle -180KB)
5. Third-Party-Scripts nach LCP verzögert

Ergebnis:

• PageSpeed Mobile: 96/100 (+44 Punkte)
• LCP: 1,3s (-68%)
• CLS: 0,01 (-95%)
• INP: 85ms (-73%)

Ausgangssituation:

• PageSpeed Mobile: 38/100
• LCP: 5,8s (Slider mit 5 unkomprimierten JPEGs)
• CLS: 0,31 (Produktbilder ohne Dimensionen, nachladende Reviews)
• INP: 420ms (jQuery + 15 aktive Plugins)

Maßnahmen:

1. Slider durch statisches Hero-Bild ersetzt
2. ShortPixel für automatische Bildkompression (WebP)
3. Plugin-Audit: 15 → 8 Plugins (7 unnötige entfernt)
4. WP Rocket installiert (Caching, CSS/JS-Minification, Lazy Loading)
5. Hosting-Wechsel von Shared auf Managed VPS
6. Alle Produktbilder mit festen Dimensionen versehen

Ergebnis:

• PageSpeed Mobile: 88/100 (+50 Punkte)
• LCP: 1,9s (-67%)
• CLS: 0,04 (-87%)
• INP: 145ms (-65%)

Fallstudie 3: Lokales Dienstleistungsunternehmen (WordPress)

• PageSpeed Mobile: 44/100
• LCP: 4,5s (unoptimiertes Hero-JPEG, 2,1 MB)
• CLS: 0,28 (Bilder ohne Dimensionen, nachladeender Cookie-Banner)
• INP: 190ms

Maßnahmen:

1. Hero-Bild: JPEG → WebP, 2,1 MB → 95 KB, fetchpriority="high"
2. Alle Bilder mit width/height versehen
3. Cookie-Banner auf position: fixed umgestellt
4. WP Rocket + ShortPixel installiert
5. Unused CSS entfernt (Perfmatters)

Ergebnis:

• PageSpeed Mobile: 92/100 (+48 Punkte)
• LCP: 1,6s (-64%)
• CLS: 0,03 (-89%)
• INP: 95ms (-50%)

Häufige Fehler bei der CWV-Optimierung

Aus unserer Erfahrung mit über 200 Projekten sehen wir immer wieder dieselben Fehler:

Lab-Daten (Lighthouse) zeigen das Potenzial, aber maßgeblich sind die Feld-Daten (CrUX), auf denen auch die Search Console beruht. Eine Website kann in Lighthouse 100/100 haben und trotzdem schlechte Feld-Daten aufweisen, wenn echte Nutzer auf langsamen Geräten oder schlechtem Internet unterwegs sind.

2. Alle Bilder lazy-loaden

Lazy Loading ist großartig — aber nicht für Above-the-Fold-Bilder. Das Hero-Bild mit loading="lazy" zu versehen, verschlechtert den LCP-Wert dramatisch, weil der Browser das Bild erst lädt, wenn es im Viewport ist.

3. Zu viele Fonts laden

Jede Font-Datei kostet Ladezeit und kann CLS verursachen. Beschränken Sie sich auf 2-3 Font-Varianten (Regular, Bold, ggf. Italic) und laden Sie nur die benötigten Zeichensätze (latin statt latin-extended).

4. Performance-Plugins stapeln

Drei Caching-Plugins gleichzeitig machen die Sache nicht besser, sondern schlimmer. Konflikte zwischen Plugins sind die häufigste Ursache für unerklärliche Performance-Probleme. Ein gutes Caching-Plugin (z.B. WP Rocket) reicht.

5. Third-Party-Scripts ignorieren

Google Analytics, Facebook Pixel, Hotjar, Intercom, Drift — jedes zusätzliche Script kostet Performance. Fragen Sie sich bei jedem Script: Brauche ich das wirklich? Und wenn ja: Kann ich es verzögert laden?

6. Nur die Homepage optimieren

Google bewertet jede URL individuell. Die Produktseiten, Blog-Artikel und Kontaktseite müssen genauso optimiert sein wie die Startseite. Prüfen Sie in der Search Console den CWV-Report für alle Seitengruppen.

Performance-Monitoring einrichten

CWV-Optimierung ist kein einmaliges Projekt. Neue Features, Content-Änderungen und Third-Party-Updates können die Performance jederzeit verschlechtern. So richten Sie kontinuierliches Monitoring ein:

1. Google Search Console (kostenlos)

• Öffnen Sie den Bericht "Core Web Vitals" unter "Verbesserungen"
• Prüfen Sie monatlich die Anzahl der URLs mit "schlechtem" oder "verbesserungswürdigem" Status
• Setzen Sie Alerts für Verschlechterungen

2. Real User Monitoring (RUM)

3. Lighthouse CI in der Build-Pipeline

# .github/workflows/lighthouse.yml name: Lighthouse CI on: [push] jobs: lighthouse: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: treosh/lighthouse-ci-action@v11 with: urls: | https://example.com/ https://example.com/blog/ budgetPath: ./budget.json temporaryPublicStorage: true

4. Performance-Budgets definieren

Third-Party Scripts und ihr Einfluss auf Core Web Vitals

Third-Party Scripts sind einer der größten Performance-Killer moderner Websites. Websites laden häufig viele Third-Party-Ressourcen -- von Analytics über Chatbots bis zu Werbe-Pixeln. Diese externen Skripte können Ihre Core Web Vitals massiv verschlechtern.

Welche Third-Party Scripts die größten Probleme verursachen

Hoher Impact auf LCP und INP:

• Chat-Widgets (z. B. Intercom, Zendesk Chat): Laden oft 200--500 KB JavaScript und blockieren den Main Thread
• Social Media Embeds (Facebook, Instagram, Twitter): Ein einzelnes Facebook-Embed kann 1--3 MB zusätzliche Ressourcen laden
• Video-Embeds (YouTube, Vimeo): Ein YouTube-Iframe lädt ohne Optimierung 600 KB--1,5 MB

Moderater Impact:

• Analytics-Tools (Google Analytics, Hotjar, Matomo): Normalerweise 50--150 KB, aber Tracking-Pixel können sich summieren
• Cookie-Consent-Banner (Cookiebot, Usercentrics): 30--100 KB, aber oft render-blockierend
• Font-Services (Google Fonts, Adobe Fonts): 50--200 KB pro Schriftfamilie

Geringer Impact bei korrekter Einbindung:

• Tag Manager (Google Tag Manager): Ca. 80 KB, aber Container-Größe wächst mit jedem Tag
• Conversion-Pixel (Google Ads, Meta Pixel): Einzeln klein, aber kumulativer Effekt

Strategien zur Optimierung

1. Lazy Loading für Third-Party Scripts

Laden Sie Chat-Widgets, Social-Media-Embeds und andere nicht-kritische Scripts erst, wenn der Nutzer sie benötigt:

• Chat-Widget erst nach Scroll oder nach 5 Sekunden laden
• Social-Media-Embeds als Fassade (statisches Bild mit Click-to-Load) implementieren
• YouTube-Videos mit dem lite-youtube-embed Pattern einbinden -- spart bis zu 500 KB pro Video

2. Script-Priorisierung

Verwenden Sie die richtigen Ladeattribute:

• async: Script wird parallel geladen und sofort ausgeführt (für Analytics)
• defer: Script wird parallel geladen, aber erst nach dem HTML-Parsing ausgeführt (für die meisten Scripts)
• Kein Attribut: Script blockiert das Rendering -- vermeiden Sie dies unbedingt

3. Self-Hosting statt CDN-Einbindung

Hosten Sie häufig verwendete Third-Party-Ressourcen selbst:

• Google Fonts: Laden Sie die WOFF2-Dateien herunter und hosten Sie sie auf Ihrem Server. Das spart einen DNS-Lookup und eine zusätzliche Verbindung.
• Analytics-Scripts: Bei self-hosted Matomo entfällt der Third-Party-Request komplett

4. Regelmäßiges Audit

Führen Sie quartalsweise ein Third-Party-Audit durch. Entfernen Sie Scripts, die nicht mehr benötigt werden.

Messung des Third-Party-Impacts

Nutzen Sie folgende Tools, um den Einfluss einzelner Scripts zu messen:

• Chrome DevTools > Performance Tab: Zeigt, welche Scripts den Main Thread blockieren
• WebPageTest > "Block" Tab: Testen Sie die Ladezeit mit und ohne bestimmte Third-Party-Domains
• Lighthouse > Treemap: Visualisiert die JavaScript-Größe nach Script-Herkunft

Server-seitige Optimierungen: Hosting, CDN und Caching

Die beste Frontend-Optimierung nützt wenig, wenn der Server langsam antwortet. Die Time to First Byte (TTFB) sollte unter 800 Millisekunden liegen -- idealerweise unter 200 ms.

Hosting-Optimierung

Shared Hosting -- das häufigste Problem

Viele KMU-Websites laufen auf Shared Hosting. Das bedeutet: Hunderte Websites teilen sich einen Server. In Stoßzeiten steigt die TTFB massiv an.

Empfehlungen nach Website-Typ:

• Statische/JAMstack-Websites: Edge-Hosting (Vercel, Netlify, Cloudflare Pages) -- TTFB unter 50 ms weltweit
• WordPress-Websites: Managed WordPress Hosting (Raidboxes, Cloudways) -- TTFB 100--300 ms
• PHP-Anwendungen: VPS mit OPcache, PHP 8.2+ und FastCGI -- TTFB 150--400 ms
• Node.js-Anwendungen: Container-Hosting (Railway, Fly.io) oder VPS mit PM2

CDN richtig konfigurieren

Ein Content Delivery Network verteilt statische Inhalte auf Server weltweit. Für österreichische Websites mit DACH-Zielgruppe ist ein CDN mit Edge-Nodes in Frankfurt, Wien und Zürich optimal.

CDN-Konfiguration Best Practices:

• Statische Assets (CSS, JS, Bilder, Fonts) über das CDN ausliefern
• HTML-Seiten nur cachen, wenn sie sich selten ändern (z. B. Landing Pages)
• Cache-Control-Header korrekt setzen: 'public, max-age=31536000, immutable' für versionierte Assets
• Brotli-Komprimierung aktivieren -- erzeugt in der Regel kleinere Dateien als Gzip

Server-seitiges Caching

Page Caching:

Generieren Sie HTML-Seiten einmalig und liefern Sie die gecachte Version aus. Für WordPress eignen sich Plugins wie WP Super Cache oder W3 Total Cache. Für Next.js nutzen Sie Incremental Static Regeneration (ISR).

Object Caching mit Redis:

Redis speichert häufig abgefragte Datenbankresultate im Arbeitsspeicher. Das kann die TTFB deutlich senken. Für WordPress ist Redis Object Cache ein Game-Changer, besonders bei WooCommerce-Shops.

OPcache für PHP:

Aktivieren Sie OPcache mit ausreichend Speicher (mindestens 128 MB). OPcache kompiliert PHP-Dateien einmalig und speichert den Bytecode. Das beschleunigt PHP-basierte Websites in der Regel spürbar.

HTTP/2 und HTTP/3

Stellen Sie sicher, dass Ihr Server HTTP/2 oder idealerweise HTTP/3 (QUIC) unterstützt:

• HTTP/2: Multiplexing ermöglicht paralleles Laden mehrerer Ressourcen über eine Verbindung
• HTTP/3: Basiert auf UDP statt TCP, kann die Latenz bei schlechten Netzwerkbedingungen reduzieren
• Die meisten modernen Hosting-Provider und CDNs unterstützen HTTP/3 inzwischen

Core Web Vitals für E-Commerce-Websites

E-Commerce-Websites stehen vor besonderen Herausforderungen bei den Core Web Vitals. Produktbilder, Filtersysteme, dynamische Preisanzeigen und Checkout-Prozesse machen die Optimierung komplex -- aber umso lohnender.

LCP-Optimierung für Produktseiten

Das größte sichtbare Element auf Produktseiten ist typischerweise das Hauptproduktbild. Optimieren Sie es gezielt:

• Bild vorausladen mit '<link rel="preload" as="image">' im HTML-Head
• Placeholder verwenden: Low-Quality Image Placeholder (LQIP) oder Blur-Up-Technik
• Bildgröße begrenzen: Das Hauptbild sollte maximal 150 KB groß sein (WebP, Qualität 80)
• Kein Lazy Loading für das Hauptproduktbild -- es muss sofort geladen werden

CLS-Probleme bei Shops

Die häufigsten CLS-Ursachen in E-Commerce:

• Preisanzeigen, die nachladen: Personalisierte Preise oder Sale-Labels, die per JavaScript eingefügt werden
• Produktbewertungs-Sterne: Wenn das Rating-Widget asynchron geladen wird und den Content verschiebt
• Banner und Aktionshinweise: "Kostenloser Versand ab 50 Euro"-Banner, die nach dem Seitenaufbau erscheinen
• Produktempfehlungen: "Kunden kauften auch"-Carousels, die Platz einnehmen

Lösungen:

• Reservieren Sie feste Platzhalter (min-height/aspect-ratio) für alle dynamischen Elemente
• Laden Sie Preisinformationen serverseitig statt per Client-Side JavaScript
• Setzen Sie width und height Attribute auf alle Produktbilder

INP-Optimierung für Filter und Suche

Produktfilter und Suchfunktionen sind interaktiv -- und genau hier zeigt sich der INP-Wert:

• Debouncing für Sucheingaben: Warten Sie 300 ms nach dem letzten Tastendruck, bevor die Suche ausgelöst wird
• Virtuelle Scrolling-Listen für Kategorien mit hunderten Produkten
• Web Worker für aufwändige Filter-Berechnungen, um den Main Thread zu entlasten
• Optimistic UI: Zeigen Sie Filterergebnisse sofort an und aktualisieren Sie im Hintergrund

Checkout-Performance

Der Checkout-Prozess ist der kritischste Moment für E-Commerce -- schon kleine Verzögerungen kosten Umsatz: Bei Zalando steigerte eine um 100 ms kürzere Ladezeit den Umsatz pro Session um 0,7 %:

• Payment-Scripts (Stripe, PayPal, Klarna) erst auf der Checkout-Seite laden, nicht auf allen Seiten
• Formulare mit minimalem JavaScript: Native HTML-Validierung nutzen statt schwerer Bibliotheken
• Adress-Autovervollständigung spart dem Nutzer Zeit und reduziert die Wartezeit auf die nächste Interaktion

Eigene Zielwerte für E-Commerce

Für E-Commerce-Websites in der DACH-Region setzen wir als ambitionierte eigene Zielwerte strengere Werte als die Google-Schwellen an:

• LCP: Unter 2,0 Sekunden
• INP: Unter 150 ms
• CLS: Unter 0,05

Pagespeed-Optimierung in der Praxis: Vorher-Nachher-Analyse

Theorie ist wichtig, aber Beispiele machen Maßnahmen greifbar. Die folgenden drei Szenarien sind illustrative Beispiele mit typischen Maßnahmen und Messwerten, keine belegten Kundenergebnisse.

Fallbeispiel 1: Handwerksbetrieb aus Wien

• WordPress-Website mit 35 Seiten, Shared Hosting
• LCP: 6,2 Sekunden | CLS: 0,28 | INP: 420 ms
• PageSpeed Score: 28/100 (Mobile)

Durchgeführte Maßnahmen:

• Hosting-Wechsel zu Managed WordPress (Raidboxes)
• Bildkonvertierung zu WebP, Lazy Loading implementiert
• 8 ungenutzten Plugins deaktiviert und entfernt
• Critical CSS generiert, JavaScript-Ausführung verzögert
• Google Fonts lokal gehostet, auf 2 Schriftschnitte reduziert

Ergebnis nach 4 Wochen:

• LCP: 1,8 Sekunden (71 % verbessert) | CLS: 0,02 | INP: 95 ms
• PageSpeed Score: 92/100 (Mobile)

Fallbeispiel 2: Online-Shop für Sportbekleidung (Österreich)

Ausgangslage:

• WooCommerce mit 1.200 Produkten, VPS-Hosting
• LCP: 4,8 Sekunden | CLS: 0,22 | INP: 380 ms

Durchgeführte Maßnahmen:

• Redis Object Cache installiert und konfiguriert
• Produktbilder automatisiert auf WebP konvertiert (Shortpixel)
• Slider auf der Startseite durch statisches Hero-Image ersetzt
• WooCommerce-Cart-Fragments auf Nicht-Shop-Seiten deaktiviert
• Cloudflare CDN mit Brotli-Komprimierung aktiviert
• Checkout auf separate Subdomain mit minimaler CSS/JS-Last

Ergebnis nach 6 Wochen:

• LCP: 2,1 Sekunden (56 % verbessert) | CLS: 0,04 | INP: 140 ms
• PageSpeed Score: 78/100 (Mobile)

Fallbeispiel 3: SaaS-Landing-Page (Next.js)

Ausgangslage:

• Next.js 14 auf Vercel, 8 Landing Pages
• LCP: 3,1 Sekunden | CLS: 0,08 | INP: 250 ms
• PageSpeed Score: 62/100 (Mobile)

• Hero-Bild mit next/image und priority-Attribut optimiert
• Intercom-Chat-Widget mit Intersection Observer lazy geladen
• Animationsbibliothek (Framer Motion) durch CSS-Transitions ersetzt (Ersparnis: 120 KB)
• Bundle-Analyse mit @next/bundle-analyzer, ungenutzten Code entfernt
• Font-Display: swap und Font-Subsetting für die verwendete Schriftart

Ergebnis nach 2 Wochen:

• LCP: 1,4 Sekunden (55 % verbessert) | CLS: 0,01 | INP: 85 ms
• PageSpeed Score: 97/100 (Mobile)

Lessons Learned aus allen drei Projekten

• Die größten Gewinne kommen fast immer von Bildern und Third-Party Scripts
• Hosting-Upgrades sind oft die kosteneffizienteste Einzelmaßnahme
• Weniger ist mehr: Reduzieren Sie Plugins, Schriftschnitte und Animationen konsequent
• Messen vor und nach jeder Maßnahme: So identifizieren Sie, welche Änderungen den größten Impact haben

Core Web Vitals und SEO-Rankings: Die messbaren Auswirkungen

Korrelation zwischen Core Web Vitals und Rankings

Google betont, dass gute Core-Web-Vitals-Werte keine Top-Platzierung garantieren. Die folgenden Daten ordnen die Lage ein:

• Laut HTTP Archive Web Almanac hatten 2024 nur 43 % der mobilen Seiten gute Werte bei allen drei Core Web Vitals (2022 waren es 31 %, mit INP neu berechnet)
• Der Anteil der Seiten mit guten Werten steigt, gute Core Web Vitals werden damit eher zum Standard als zum Alleinstellungsmerkmal

Die Kernaussage: Core Web Vitals sind ein Tiebreaker-Faktor. Bei ansonsten gleicher Relevanz und Autorität entscheiden sie über die Positionierung. Sie können schwachen Content nicht auf Position 1 bringen, aber sie können den Unterschied zwischen Position 3 und Position 7 ausmachen.

Eigene Zielwerte nach Branche

Die Google-Schwellen gelten für alle Branchen gleich. Als eigene Orientierung für ambitionierte Ziele dienen je nach Branche folgende Werte (keine offiziellen Benchmarks):

E-Commerce und Online-Shops:

• LCP: unter 2,0 Sekunden
• INP: unter 150ms
• Die Herausforderung liegt in der Produktbildoptimierung und den vielen Third-Party-Skripten (Tracking, Zahlungsanbieter, Chatbots)

B2B-Dienstleistungen:

• LCP: unter 1,8 Sekunden
• CLS: unter 0,03
• INP: unter 100ms
• B2B-Websites haben typischerweise weniger Third-Party-Skripte und können daher leichter gute Werte erreichen

Nachrichtenportale und Content-Websites:

• LCP: unter 2,5 Sekunden
• CLS: unter 0,08
• INP: unter 200ms
• Die größte Herausforderung ist hier der hohe CLS-Wert durch nachladende Werbebanner und dynamische Inhalte

ROI-Berechnung: Was bringt die CWV-Optimierung?

Für Unternehmen im DACH-Raum stellt sich die Frage, ob sich die Investition in Core Web Vitals-Optimierung rechnet. Die Antwort hängt vom Geschäftsmodell ab, ist aber in den meisten Fällen eindeutig positiv:

Direkte Auswirkungen auf die Conversion-Rate:

• Vodafone steigerte den Umsatz um 8 %, nachdem der LCP um 31 % verbessert wurde (A/B-Test)
• Zalando stellte 2018 in einem A/B-Test fest, dass jede 100ms Verbesserung der Ladezeit den Umsatz pro Session um 0,7 % steigert

Berechnung für ein typisches österreichisches KMU:

Angenommen, Ihre Website hat 10.000 organische Besucher pro Monat bei einer Conversion-Rate von 2 % und einem durchschnittlichen Auftragsgewinn von 500 Euro. Eine CWV-Optimierung, die die Conversion-Rate um 15 % steigert (von 2 % auf 2,3 %), bringt:

• Zusätzliche Conversions pro Monat: 30
• Zusätzlicher Umsatz pro Monat: 15.000 Euro
• Zusätzlicher Umsatz pro Jahr: 180.000 Euro

Demgegenüber steht die einmalige Investition in die CWV-Optimierung, die je nach Komplexität der Website stark variiert. Ob und wann sie sich amortisiert, zeigt die Rechnung mit Ihren eigenen Zahlen.

Monitoring und kontinuierliche Verbesserung

Setzen Sie auf diese Monitoring-Strategie:

• Wöchentlich: Automatisierte Lighthouse-CI-Tests in der CI/CD-Pipeline
• Monatlich: CrUX-Daten (Chrome User Experience Report) in der Google Search Console überprüfen
• Vierteljährlich: Umfassender Performance-Audit mit Vergleich zur Konkurrenz
• Bei jedem Deployment: Automatisierte Performance-Budgets, die den Build stoppen, wenn Schwellenwerte überschritten werden

Zukunft der Core Web Vitals: Was kommt nach INP?

Google entwickelt die Core Web Vitals kontinuierlich weiter. Nach dem Wechsel von FID (First Input Delay) zu INP (Interaction to Next Paint) im März 2024 fragen sich viele SEO-Verantwortliche: Welche Metriken werden als nächstes eingeführt, und wie können Sie sich heute schon darauf vorbereiten?

Die Evolution der Core Web Vitals

Ein Blick auf die bisherige Entwicklung hilft, die zukünftige Richtung einzuschätzen:

• 2020: Einführung der Core Web Vitals mit LCP, FID und CLS
• 2021: Das Page-Experience-Update nimmt Core Web Vitals in die Ranking-Signale auf
• 2024: FID wird durch INP ersetzt — ein deutlich anspruchsvollerer Interaktivitäts-Metric
• 2026+: Mehrere neue Metriken befinden sich in der Erprobungsphase

Die klare Tendenz: Google bewegt sich weg von vereinfachten Metriken hin zu umfassenderen Messungen der tatsächlichen Nutzererfahrung.

Experimentelle Metriken, die Sie kennen sollten

Google und das Web Performance Community arbeiten an mehreren neuen Metriken, die potenziell in die Core Web Vitals aufgenommen werden könnten:

Smoothness (Animation Fluidity)

Diese Metrik misst, wie flüssig Animationen und Scroll-Interaktionen auf einer Website sind. Ziel ist die Erkennung von Frame Drops und Jank — also Rucklern, die die Nutzererfahrung beeinträchtigen. Besonders relevant für:

• Websites mit parallax-scrolling-Effekten
• E-Commerce-Shops mit Produktkarussells
• Websites mit komplexen CSS-Animationen

Responsiveness Beyond INP

Während INP die Verzögerung bis zur visuellen Aktualisierung nach einer Interaktion misst, gibt es Bestrebungen, die gesamte Interaktionskette zu erfassen. Dazu gehören:

• Die Zeit bis zum Abschluss aller durch die Interaktion ausgelösten Netzwerkanfragen
• Die Stabilität des Layouts nach der Interaktion
• Die Konsistenz der Interaktionszeiten über die gesamte Nutzungsdauer

Long Animation Frames (LoAF)

Diese API ermöglicht eine präzisere Analyse, warum eine Seite langsam reagiert. Im Gegensatz zu den bisherigen Long Tasks, die nur die Dauer messen, liefert LoAF detaillierte Informationen über die Ursache der Verzögerung — einschließlich der verantwortlichen Skripte und Funktionen.

Soft Navigations und Single-Page-Applications

Eine der größten Lücken in den aktuellen Core Web Vitals ist die Messung von Soft Navigations — also Seitenwechseln innerhalb von Single-Page-Applications (SPAs), die ohne vollständigen Seitenload erfolgen. Google arbeitet aktiv an einer Lösung, die CWV auch für SPAs fair und aussagekräftig macht.

Das ist besonders relevant für Websites, die auf Frameworks wie Next.js, Nuxt.js oder Angular basieren.

Was bedeutet das für Sie?

• Wenn Sie eine SPA betreiben, sollten Sie die Soft Navigation API im Auge behalten
• Implementieren Sie bereits jetzt Performance-Monitoring für clientseitige Navigationen
• Testen Sie Ihre SPA nicht nur auf den initialen Seitenload, sondern auch auf nachfolgende Navigationen

Vorbereitung auf zukünftige Metriken

Auch wenn die exakten zukünftigen Metriken noch nicht feststehen, können Sie sich heute schon vorbereiten:

• Performance-Budget einführen — Definieren Sie maximale JavaScript-Bundle-Größen, maximale Ladezeiten und maximale Layout Shifts. Diese Budgets schützen Sie vor Regressionen, unabhängig davon, welche Metriken Google einführt
• Real User Monitoring (RUM) implementieren — Erfassen Sie Performance-Daten von echten Nutzerinnen und Nutzern, nicht nur aus synthetischen Tests. Tools wie SpeedCurve, Web Vitals Library oder Vercel Analytics liefern wertvolle Echtzeitdaten
• JavaScript-Bundle analysieren — Reduzieren Sie ungenutzten Code, implementieren Sie Code-Splitting und Lazy Loading. Kleinere Bundles bedeuten bessere Performance — unabhängig von der spezifischen Metrik
• Server-Performance optimieren — Investieren Sie in schnelle Server, CDN-Konfiguration und Edge Computing. Eine solide Server-Infrastruktur ist die Basis für alle Performance-Metriken
• Accessibility als Performance-Faktor — Barrierefreie Websites sind oft auch performanter, da sie auf schlanken, semantischen HTML-Code setzen.

Der wichtigste Rat für den DACH-Markt: Verfolgen Sie einen nutzerzentrierten Ansatz statt einzelne Metriken zu optimieren. Wenn Ihre Website schnell lädt, zuverlässig auf Interaktionen reagiert und visuell stabil ist, werden Sie von allen zukünftigen Core Web Vitals-Updates profitieren — unabhängig davon, welche konkreten Metriken Google einführt.

Fazit und nächste Schritte

Core Web Vitals sind kein einmaliges Projekt, sondern ein fortlaufender Prozess. Neue Features, Content-Änderungen und Third-Party-Updates können die Performance jederzeit verschlechtern. Hier ist Ihr Aktionsplan:

Sofort-Maßnahmen (diese Woche)

1. Messen: Öffnen Sie PageSpeed Insights und testen Sie Ihre 5 wichtigsten Seiten
2. Priorisieren: Identifizieren Sie die Metrik mit dem größten Verbesserungspotenzial
3. Quick Wins: Bilder komprimieren, Dimensionen hinzufügen, Fonts optimieren

Kurzfristig (diesen Monat)

1. Server optimieren: Hosting evaluieren, CDN einrichten, Caching konfigurieren
2. JavaScript-Audit: Unnötige Plugins/Scripts identifizieren und entfernen
3. Theme/Framework evaluieren: Ist Ihr Theme/Framework der Flaschenhals?

Langfristig (dieses Quartal)

1. Monitoring einrichten: Automated Performance Monitoring (z.B. SpeedCurve, Calibre)
2. Performance-Budget definieren: Maximale Bundle-Größe, maximaler LCP-Wert
3. Team-Awareness: Alle Entwickler für Performance sensibilisieren
4. Regelmäßige Audits: Monatliche Performance-Reviews

Brauchen Sie Unterstützung?

Core Web Vitals Optimierung ist komplex und erfordert technisches Know-how. Bei GoldenWing optimieren wir die Core Web Vitals als festen Bestandteil jedes Webdesign- und SEO-Projekts. Von der Performance-Analyse bis zur Umsetzung — wir bringen Ihre Website auf grün.

Nutzen Sie unseren kostenlosen Performance Checker, um den aktuellen Stand Ihrer Website zu ermitteln, und kontaktieren Sie uns für ein unverbindliches Beratungsgespräch. Gemeinsam machen wir Ihre Website schnell, stabil und nutzerfreundlich.

Wenn Sie noch mehr über technisches SEO erfahren möchten, besuchen Sie unsere Lexikon-Einträge oder lesen Sie unsere weiteren Blog-Artikel zu den Themen Webdesign und Performance-Optimierung. Core Web Vitals sind fester Bestandteil unseres Webdesigns in Wien.