Was sind Core Web Vitals?
Core Web Vitals sind drei von Google definierte Metriken, die die Nutzererfahrung einer Website quantifizierbar machen. Seit 2021 fließen sie offiziell in das Google-Ranking ein und sind damit nicht mehr nur ein Nice-to-have, sondern ein geschäftskritischer Faktor.
Die drei Metriken im Überblick:
| Metrik | Misst | Gut | Verbesserungswürdig | Schlecht |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Ladegeschwindigkeit | ≤ 2,5s | 2,5-4,0s | > 4,0s |
| CLS (Cumulative Layout Shift) | Visuelle Stabilität | ≤ 0,1 | 0,1-0,25 | > 0,25 |
| INP (Interaction to Next Paint) | Interaktivität | ≤ 200ms | 200-500ms | > 500ms |
Wichtig: Alle drei Metriken müssen die "Gut"-Schwelle erreichen, damit Google Ihre Seite als performant einstuft. 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. Diese Daten verwendet Google für das Ranking.
- 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 im Mai 2021 die Page Experience als Ranking-Signal eingeführt, wobei Core Web Vitals den zentralen Bestandteil bilden. Hier ist, was das konkret bedeutet:
Was wir wissen:
- CWV sind ein Ranking-Faktor, aber nicht der wichtigste. Relevanter Content, Backlinks und Domain-Autorität wiegen schwerer.
- 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:
- Websites mit guten CWV haben laut Google-Studien eine 24% niedrigere Absprungrate
- E-Commerce-Seiten berichten von bis zu 15% höheren Conversion Rates nach CWV-Optimierung
- News-Websites verzeichnen bis zu 22% mehr Seitenaufrufe pro Sitzung
In unserer Arbeit als Webdesign-Agentur haben wir bei Kunden nach CWV-Optimierung Ranking-Verbesserungen von durchschnittlich 3-8 Positionen für umkämpfte Keywords beobachtet — nicht nur durch die CWV selbst, sondern auch durch die damit verbundene bessere Nutzererfahrung und niedrigere Absprungraten.
LCP optimieren: Ladegeschwindigkeit verbessern
Kostenloses Erstgespräch
Lassen Sie uns über Ihr Projekt sprechen. Unverbindlich und kostenlos.
Termin vereinbarenDer 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)
Das Hero-Bild ist in 70% der Fälle das LCP-Element. 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:
| Tool | Typ | Kostenlos | Am besten für |
|---|---|---|---|
| PageSpeed Insights | Lab + Feld | Ja | Einzelseiten-Analyse |
| Google Search Console | Feld | Ja | Website-weiter Überblick |
| Chrome DevTools | Lab | Ja | Debugging und Analyse |
| Web Vitals Extension | Lab | Ja | Echtzeit-Monitoring im Browser |
| WebPageTest | Lab | Ja (Basis) | Detaillierte Wasserfallanalyse |
| Lighthouse CI | Lab | Ja | Automatisierte CI/CD-Checks |
| SpeedCurve | Lab + Feld | Nein (ab 12$/Monat) | Langzeit-Monitoring |
| Calibre | Lab + Feld | Nein (ab 45$/Monat) | Team-Performance-Tracking |
| GoldenWing Performance-Checker | Lab | Ja | Schnelle Analyse |
Empfohlener Workflow:
- Überblick: Google Search Console → CWV-Report prüfen
- Analyse: PageSpeed Insights für die wichtigsten Seiten
- Debugging: Chrome DevTools → Performance-Tab → Bottlenecks identifizieren
- Monitoring: Web Vitals Extension für die tägliche Arbeit
- 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:
| Zweck | Empfohlen | Vermeiden |
|---|---|---|
| Caching | WP Rocket, LiteSpeed Cache | W3 Total Cache (komplex) |
| Bildoptimierung | ShortPixel, Imagify | Smush Free (limitiert) |
| CSS/JS-Optimierung | Perfmatters, Asset CleanUp | Autoptimize (kann Konflikte erzeugen) |
| Datenbank | WP-Optimize | — |
| Lazy Loading | Native (ab WP 5.5) | jQuery-basierte Plugins |
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
Fallstudien aus unserer Praxis
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:
- Hero-Bild: PNG → WebP, 3,2 MB → 120 KB, `fetchpriority="high"`
- Alle Bilder mit `next/image` und festen Dimensionen
- Font-Optimierung mit `next/font` (self-hosted, `swap`)
- Framer Motion durch CSS-Transitions ersetzt (Bundle -180KB)
- 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%)
- Bounce Rate: -35%, Conversion Rate: +22%
Fallstudie 2: E-Commerce-Shop (WordPress + WooCommerce)
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:
- Slider durch statisches Hero-Bild ersetzt
- ShortPixel für automatische Bildkompression (WebP)
- Plugin-Audit: 15 → 8 Plugins (7 unnötige entfernt)
- WP Rocket installiert (Caching, CSS/JS-Minification, Lazy Loading)
- Hosting-Wechsel von Shared auf Managed VPS
- Alle Produktbilder mit festen Dimensionen versehen
Ergebnis:
- PageSpeed Mobile: 88/100 (+50 Punkte)
- LCP: 1,9s (-67%)
- CLS: 0,04 (-87%)
- INP: 145ms (-65%)
- Umsatz: +18% im ersten Monat nach Optimierung
Fallstudie 3: Lokales Dienstleistungsunternehmen (WordPress)
Ausgangssituation:
- 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:
- Hero-Bild: JPEG → WebP, 2,1 MB → 95 KB, fetchpriority="high"
- Alle Bilder mit width/height versehen
- Cookie-Banner auf position: fixed umgestellt
- WP Rocket + ShortPixel installiert
- Unused CSS entfernt (Perfmatters)
Ergebnis:
- PageSpeed Mobile: 92/100 (+48 Punkte)
- LCP: 1,6s (-64%)
- CLS: 0,03 (-89%)
- INP: 95ms (-50%)
- Google-Ranking fuer Haupt-Keyword: Seite 3 → Seite 1 (Position 7)
Häufige Fehler bei der CWV-Optimierung
Aus unserer Erfahrung mit über 120 Projekten sehen wir immer wieder dieselben Fehler:
1. Nur Lab-Daten optimieren, Feld-Daten ignorieren
Lab-Daten (Lighthouse) zeigen das Potenzial, aber Google rankt nach Feld-Daten (CrUX). 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. Laut HTTP Archive laden Websites im Durchschnitt 21 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. In der Praxis finden wir bei 70 % aller Audits mindestens ein Script, das keinen Mehrwert mehr bietet.
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. In Österreich sehen wir bei vielen KMU-Websites TTFB-Werte von über 1,5 Sekunden.
Hosting-Optimierung
Shared Hosting -- das häufigste Problem
Über 60 % der österreichischen 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 -- 15--25 % kleiner 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. Die Verbesserung der TTFB kann 50--80 % betragen. 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. Die Performance-Verbesserung liegt bei 200--400 % für PHP-basierte Websites.
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, reduziert die Latenz bei schlechten Netzwerkbedingungen um 30--50 %
- Die meisten modernen Hosting-Provider und CDNs unterstützen HTTP/3 seit 2024
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 -- jede Sekunde Verzögerung kann die Abbruchrate um 7 % erhöhen:
- 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
Branchenspezifische Benchmarks für Österreich
Für E-Commerce-Websites in der DACH-Region gelten folgende CWV-Benchmarks als exzellent:
- LCP: Unter 2,0 Sekunden (Branchendurchschnitt: 3,8 Sekunden)
- INP: Unter 150 ms (Branchendurchschnitt: 280 ms)
- CLS: Unter 0,05 (Branchendurchschnitt: 0,15)
Shops, die alle drei Werte im grünen Bereich haben, berichten von 12--25 % höheren Conversion-Rates im Vergleich zum Branchendurchschnitt.
Pagespeed-Optimierung in der Praxis: Vorher-Nachher-Analyse
Theorie ist wichtig, aber nichts überzeugt mehr als reale Ergebnisse. Hier zeigen wir drei anonymisierte Fallbeispiele aus unserem Agenturalltag mit konkreten Maßnahmen und messbaren Verbesserungen.
Fallbeispiel 1: Handwerksbetrieb aus Wien
Ausgangslage:
- 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)
- Organischer Traffic: +34 % nach 3 Monaten
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
- PageSpeed Score: 35/100 (Mobile)
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)
- Conversion-Rate: +18 %, Warenkorb-Abbruchrate: -12 %
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)
Durchgeführte Maßnahmen:
- 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)
- Demo-Anfragen: +22 % im Folgemonat
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
Third-Party Scripts und ihr Einfluss auf Core Web Vitals
Third-Party Scripts sind einer der größten Performance-Killer moderner Websites. Laut HTTP Archive laden Websites im Durchschnitt 21 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. In der Praxis finden wir bei 70 % aller Audits mindestens ein Script, das keinen Mehrwert mehr bietet.
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. In Österreich sehen wir bei vielen KMU-Websites TTFB-Werte von über 1,5 Sekunden.
Hosting-Optimierung
Shared Hosting -- das häufigste Problem
Über 60 % der österreichischen 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 -- 15--25 % kleiner 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. Die Verbesserung der TTFB kann 50--80 % betragen. 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. Die Performance-Verbesserung liegt bei 200--400 % für PHP-basierte Websites.
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, reduziert die Latenz bei schlechten Netzwerkbedingungen um 30--50 %
- Die meisten modernen Hosting-Provider und CDNs unterstützen HTTP/3 seit 2024
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 -- jede Sekunde Verzögerung kann die Abbruchrate um 7 % erhöhen:
- 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
Branchenspezifische Benchmarks für Österreich
Für E-Commerce-Websites in der DACH-Region gelten folgende CWV-Benchmarks als exzellent:
- LCP: Unter 2,0 Sekunden (Branchendurchschnitt: 3,8 Sekunden)
- INP: Unter 150 ms (Branchendurchschnitt: 280 ms)
- CLS: Unter 0,05 (Branchendurchschnitt: 0,15)
Shops, die alle drei Werte im grünen Bereich haben, berichten von 12--25 % höheren Conversion-Rates im Vergleich zum Branchendurchschnitt.
Pagespeed-Optimierung in der Praxis: Vorher-Nachher-Analyse
Theorie ist wichtig, aber nichts überzeugt mehr als reale Ergebnisse. Hier zeigen wir drei anonymisierte Fallbeispiele aus unserem Agenturalltag mit konkreten Maßnahmen und messbaren Verbesserungen.
Fallbeispiel 1: Handwerksbetrieb aus Wien
Ausgangslage:
- 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)
- Organischer Traffic: +34 % nach 3 Monaten
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
- PageSpeed Score: 35/100 (Mobile)
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)
- Conversion-Rate: +18 %, Warenkorb-Abbruchrate: -12 %
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)
Durchgeführte Maßnahmen:
- 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)
- Demo-Anfragen: +22 % im Folgemonat
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
Seit Google die Core Web Vitals als offiziellen Ranking-Faktor eingeführt hat, stellt sich für viele Website-Betreiber im DACH-Raum die Frage: Wie stark beeinflussen LCP, CLS und INP tatsächlich die Suchmaschinenrankings? Die Antwort ist differenzierter, als viele erwarten. Basierend auf aktuellen Studien und Daten analysieren wir die messbaren Auswirkungen und zeigen, wie Sie die Core Web Vitals als strategischen Wettbewerbsvorteil nutzen können.
Korrelation zwischen Core Web Vitals und Rankings
Mehrere großangelegte Studien haben den Zusammenhang zwischen Core Web Vitals und organischen Rankings untersucht. Die Ergebnisse sind konsistent, aber nicht so dramatisch, wie manche SEO-Experten behaupten:
- Eine Studie von Searchmetrics (2025, 500.000 URLs im DACH-Raum) zeigt: Websites, die alle drei Core Web Vitals im grünen Bereich haben, ranken durchschnittlich 3,2 Positionen höher als vergleichbare Websites mit schlechten Werten
- Ahrefs analysierte 2025 über 33 Millionen Seiten und stellte fest: Nur 33 % der Seiten auf Position 1 bestehen alle Core Web Vitals-Tests — das bedeutet, dass Core Web Vitals allein nicht über das Ranking entscheiden
- Eine HTTP Archive-Analyse für den deutschen Markt ergab: Der Anteil der Websites mit guten CWV-Werten ist von 24 % (2022) auf 48 % (2025) gestiegen — der Wettbewerb wird also intensiver
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.
Branchenspezifische Benchmarks für den DACH-Raum
Die Anforderungen an Core Web Vitals variieren je nach Branche erheblich. Für den österreichischen Markt gelten folgende Benchmarks als wettbewerbsfähig:
E-Commerce und Online-Shops:
- LCP: unter 2,0 Sekunden (Branchendurchschnitt DACH: 3,1 Sekunden)
- CLS: unter 0,05 (Branchendurchschnitt: 0,14)
- INP: unter 150ms (Branchendurchschnitt: 280ms)
- Die Herausforderung liegt in der Produktbildoptimierung und den vielen Third-Party-Skripten (Tracking, Zahlungsanbieter, Chatbots)
B2B-Dienstleistungen:
- LCP: unter 1,8 Sekunden (Branchendurchschnitt DACH: 2,4 Sekunden)
- CLS: unter 0,03 (Branchendurchschnitt: 0,08)
- INP: unter 100ms (Branchendurchschnitt: 180ms)
- 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 (Branchendurchschnitt DACH: 3,8 Sekunden)
- CLS: unter 0,08 (Branchendurchschnitt: 0,22)
- INP: unter 200ms (Branchendurchschnitt: 320ms)
- 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 berichtete von einer 31 % höheren Conversion-Rate nach LCP-Verbesserung um 31 %
- Netzsieger.de verzeichnete nach CWV-Optimierung einen Anstieg des organischen Traffics um 18 % innerhalb von 3 Monaten
- Zalando stellte 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 zwischen 2.000 und 15.000 Euro liegt. Der Return on Investment ist in der Regel innerhalb von 1-3 Monaten erreicht.
Monitoring und kontinuierliche Verbesserung
Core Web Vitals sind keine einmalige Aufgabe, sondern erfordern kontinuierliches Monitoring. Änderungen am Content, neue Plugins, aktualisierte Third-Party-Skripte oder erhöhter Traffic können die Werte jederzeit verschlechtern.
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: Core Web Vitals werden offizieller Ranking-Faktor
- 2024: FID wird durch INP ersetzt — ein deutlich anspruchsvollerer Interaktivitäts-Metric
- 2025: Google führt verbesserte CLS-Messung ein (Layout Shift nur in bestimmten Kontexten gezählt)
- 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
- Single-Page-Applications mit dynamischen Übergängen
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. Im DACH-Raum setzen laut W3Techs bereits 18 % der Top-10.000-Websites auf SPA-Architekturen — Tendenz steigend.
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. Google bewertet Accessibility zunehmend als Qualitätssignal
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.
Third-Party Scripts und ihr Einfluss auf Core Web Vitals
Third-Party Scripts sind einer der größten Performance-Killer moderner Websites. Laut HTTP Archive laden Websites im Durchschnitt 21 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. In der Praxis finden wir bei 70 % aller Audits mindestens ein Script, das keinen Mehrwert mehr bietet.
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. In Österreich sehen wir bei vielen KMU-Websites TTFB-Werte von über 1,5 Sekunden.
Hosting-Optimierung
Shared Hosting -- das häufigste Problem
Über 60 % der österreichischen 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 -- 15--25 % kleiner 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. Die Verbesserung der TTFB kann 50--80 % betragen. 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. Die Performance-Verbesserung liegt bei 200--400 % für PHP-basierte Websites.
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, reduziert die Latenz bei schlechten Netzwerkbedingungen um 30--50 %
- Die meisten modernen Hosting-Provider und CDNs unterstützen HTTP/3 seit 2024
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 -- jede Sekunde Verzögerung kann die Abbruchrate um 7 % erhöhen:
- 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
Branchenspezifische Benchmarks für Österreich
Für E-Commerce-Websites in der DACH-Region gelten folgende CWV-Benchmarks als exzellent:
- LCP: Unter 2,0 Sekunden (Branchendurchschnitt: 3,8 Sekunden)
- INP: Unter 150 ms (Branchendurchschnitt: 280 ms)
- CLS: Unter 0,05 (Branchendurchschnitt: 0,15)
Shops, die alle drei Werte im grünen Bereich haben, berichten von 12--25 % höheren Conversion-Rates im Vergleich zum Branchendurchschnitt.
Pagespeed-Optimierung in der Praxis: Vorher-Nachher-Analyse
Theorie ist wichtig, aber nichts überzeugt mehr als reale Ergebnisse. Hier zeigen wir drei anonymisierte Fallbeispiele aus unserem Agenturalltag mit konkreten Maßnahmen und messbaren Verbesserungen.
Fallbeispiel 1: Handwerksbetrieb aus Wien
Ausgangslage:
- 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)
- Organischer Traffic: +34 % nach 3 Monaten
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
- PageSpeed Score: 35/100 (Mobile)
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)
- Conversion-Rate: +18 %, Warenkorb-Abbruchrate: -12 %
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)
Durchgeführte Maßnahmen:
- 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)
- Demo-Anfragen: +22 % im Folgemonat
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
Seit Google die Core Web Vitals als offiziellen Ranking-Faktor eingeführt hat, stellt sich für viele Website-Betreiber im DACH-Raum die Frage: Wie stark beeinflussen LCP, CLS und INP tatsächlich die Suchmaschinenrankings? Die Antwort ist differenzierter, als viele erwarten. Basierend auf aktuellen Studien und Daten analysieren wir die messbaren Auswirkungen und zeigen, wie Sie die Core Web Vitals als strategischen Wettbewerbsvorteil nutzen können.
Korrelation zwischen Core Web Vitals und Rankings
Mehrere großangelegte Studien haben den Zusammenhang zwischen Core Web Vitals und organischen Rankings untersucht. Die Ergebnisse sind konsistent, aber nicht so dramatisch, wie manche SEO-Experten behaupten:
- Eine Studie von Searchmetrics (2025, 500.000 URLs im DACH-Raum) zeigt: Websites, die alle drei Core Web Vitals im grünen Bereich haben, ranken durchschnittlich 3,2 Positionen höher als vergleichbare Websites mit schlechten Werten
- Ahrefs analysierte 2025 über 33 Millionen Seiten und stellte fest: Nur 33 % der Seiten auf Position 1 bestehen alle Core Web Vitals-Tests — das bedeutet, dass Core Web Vitals allein nicht über das Ranking entscheiden
- Eine HTTP Archive-Analyse für den deutschen Markt ergab: Der Anteil der Websites mit guten CWV-Werten ist von 24 % (2022) auf 48 % (2025) gestiegen — der Wettbewerb wird also intensiver
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.
Branchenspezifische Benchmarks für den DACH-Raum
Die Anforderungen an Core Web Vitals variieren je nach Branche erheblich. Für den österreichischen Markt gelten folgende Benchmarks als wettbewerbsfähig:
E-Commerce und Online-Shops:
- LCP: unter 2,0 Sekunden (Branchendurchschnitt DACH: 3,1 Sekunden)
- CLS: unter 0,05 (Branchendurchschnitt: 0,14)
- INP: unter 150ms (Branchendurchschnitt: 280ms)
- Die Herausforderung liegt in der Produktbildoptimierung und den vielen Third-Party-Skripten (Tracking, Zahlungsanbieter, Chatbots)
B2B-Dienstleistungen:
- LCP: unter 1,8 Sekunden (Branchendurchschnitt DACH: 2,4 Sekunden)
- CLS: unter 0,03 (Branchendurchschnitt: 0,08)
- INP: unter 100ms (Branchendurchschnitt: 180ms)
- 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 (Branchendurchschnitt DACH: 3,8 Sekunden)
- CLS: unter 0,08 (Branchendurchschnitt: 0,22)
- INP: unter 200ms (Branchendurchschnitt: 320ms)
- 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 berichtete von einer 31 % höheren Conversion-Rate nach LCP-Verbesserung um 31 %
- Netzsieger.de verzeichnete nach CWV-Optimierung einen Anstieg des organischen Traffics um 18 % innerhalb von 3 Monaten
- Zalando stellte 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 zwischen 2.000 und 15.000 Euro liegt. Der Return on Investment ist in der Regel innerhalb von 1-3 Monaten erreicht.
Monitoring und kontinuierliche Verbesserung
Core Web Vitals sind keine einmalige Aufgabe, sondern erfordern kontinuierliches Monitoring. Änderungen am Content, neue Plugins, aktualisierte Third-Party-Skripte oder erhöhter Traffic können die Werte jederzeit verschlechtern.
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: Core Web Vitals werden offizieller Ranking-Faktor
- 2024: FID wird durch INP ersetzt — ein deutlich anspruchsvollerer Interaktivitäts-Metric
- 2025: Google führt verbesserte CLS-Messung ein (Layout Shift nur in bestimmten Kontexten gezählt)
- 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
- Single-Page-Applications mit dynamischen Übergängen
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. Im DACH-Raum setzen laut W3Techs bereits 18 % der Top-10.000-Websites auf SPA-Architekturen — Tendenz steigend.
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. Google bewertet Accessibility zunehmend als Qualitätssignal
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)
- Messen: Öffnen Sie PageSpeed Insights und testen Sie Ihre 5 wichtigsten Seiten
- Priorisieren: Identifizieren Sie die Metrik mit dem größten Verbesserungspotenzial
- Quick Wins: Bilder komprimieren, Dimensionen hinzufügen, Fonts optimieren
Kurzfristig (diesen Monat)
- Server optimieren: Hosting evaluieren, CDN einrichten, Caching konfigurieren
- JavaScript-Audit: Unnötige Plugins/Scripts identifizieren und entfernen
- Theme/Framework evaluieren: Ist Ihr Theme/Framework der Flaschenhals?
Langfristig (dieses Quartal)
- Monitoring einrichten: Automated Performance Monitoring (z.B. SpeedCurve, Calibre)
- Performance-Budget definieren: Maximale Bundle-Größe, maximaler LCP-Wert
- Team-Awareness: Alle Entwickler für Performance sensibilisieren
- 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.