Core Web Vitals: Der komplette Performance Guide
Performance ist ein Kernfeature, kein Nachgedanke. Selbst kleine Verzögerungen senken messbar die Conversion — Portents Site-Speed-Studie von 2019 belegt, dass Seiten mit 1 Sekunde Ladezeit die 3-fache Conversion-Rate haben wie Seiten mit 5 Sekunden. Und seit 2021 nutzt Google Core Web Vitals als direktes Ranking-Signal — langsame Seiten ranken buchstäblich schlechter.
Dieser Guide deckt alles ab, was du für exzellente Scores brauchst: die drei Metriken, die Google misst, die architektonischen Entscheidungen, die Astro einzigartig schnell machen, und die konkreten Optimierungstechniken für Bilder, CSS, JavaScript, Fonts und Drittanbieter-Skripte.
Performance ist kein technisches Problem. Es ist eine Design-Einschränkung, die jede Entscheidung beeinflusst.
Core Web Vitals: Die drei Metriken erklärt
Google misst drei spezifische Metriken, die die Nutzererfahrung bei Laden, Interaktivität und visueller Stabilität repräsentieren. Seit März 2024 ist INP (Interaction to Next Paint) die offizielle Interaktivitäts-Metrik und hat FID (First Input Delay) abgelöst.
Misst, wie schnell das größte sichtbare Element (Hero-Bild, Überschrift, Video-Thumbnail) erscheint. Ziel: unter 2,5 Sekunden. Das ist die Metrik, die Nutzer am meisten spüren — sie bestimmt, wie schnell die Seite geladen aussieht.
Misst die Reaktionsfähigkeit auf Nutzereingaben (Klicks, Tippen, Tastatureingaben). Ziel: unter 200 Millisekunden. INP misst ALLE Interaktionen während des gesamten Seitenlebenszyklus, nicht nur die erste.
Misst die visuelle Stabilität — wie stark sich Inhalt während des Ladens verschiebt. Ziel: unter 0,1. Bilder ohne Dimensionen, spät ladende Fonts und eingefügte Werbung sind die Hauptschuldigen.
Warum Astro für Performance gebaut ist
Astros Architektur unterscheidet sich grundlegend von React, Next.js oder Nuxt. Es liefert standardmäßig null JavaScript aus. Jede Seite wird zur Build-Time als statisches HTML gerendert, ohne Hydration-Overhead.
| Framework | Standard-JS Recommended | Hydration | LCP-Einfluss |
|---|---|---|---|
| Astro (statisch) | 0 KB | Keine (statisches HTML) | Exzellent |
| Astro (Islands) | Pro Island | Selektiv | Exzellent |
| Next.js (App Router) | 85–120 KB | Ganze Seite | Gut |
| Nuxt 3 | 70–100 KB | Ganze Seite | Gut |
| Create React App | 150–250 KB | Ganze Seite | Schlecht |
| WordPress (Durchschnitt) | 200–400 KB | Plugin-abhängig | Schlecht |
Astros Island-Architektur bedeutet, dass interaktive Komponenten (ein Formular, ein Karussell, eine Suche) einzeln hydriert werden. Der Rest der Seite — Header, Footer, Inhalt, Navigation — bleibt als reines HTML. Deshalb erreichen Astro-Seiten konsistent 95–100 bei Lighthouse ohne jegliche Optimierungsarbeit.
LCP-Optimierung: Das größte Element schnell laden
Der Largest Contentful Paint ist meist die größte Herausforderung. Das LCP-Element ist typischerweise ein Hero-Bild, eine große Überschrift oder ein Video-Poster. Bilder sind das LCP-Element auf 70% aller Webseiten.
Identifiziere dein LCP-Element (meist Hero-Bild). Preloade es mit <link rel="preload">. Liefere es in WebP/AVIF. Setze explizite width/height. Lazy-loade das LCP-Bild niemals.
Kritisches CSS inline einbinden. Nicht-kritische Stylesheets deferren. Ungenutztes CSS entfernen. <link rel="preconnect"> für externe Origins verwenden.
CDN verwenden (Netlify, Vercel, Cloudflare). Kompression aktivieren (Brotli > gzip). Far-Future Cache-Header für statische Assets setzen.
font-display: swap verwenden. Kritische Font-Dateien preloaden. Fonts auf benötigte Zeichen subsetten. Self-hosten statt Google Fonts für weniger Verbindungen.
Bildoptimierung im Detail
Die korrekte Bildoptimierung hat den größten einzelnen Einfluss auf die wahrgenommene Performance. Hier die drei wichtigsten Patterns:
---
/* Astros eingebaute Image-Komponente übernimmt die Optimierung */
import { Image } from 'astro:assets';
import heroImage from '../assets/hero.jpg';
---
<!-- Automatisch WebP/AVIF, responsives srcset, width/height -->
<Image
src={heroImage}
alt="Hero-Bildbeschreibung"
widths={[400, 800, 1200]}
sizes="(max-width: 768px) 100vw, 1200px"
loading="eager"
fetchpriority="high"
/><!-- Im <head>: LCP-Bild preloaden für schnellste Auslieferung -->
<link
rel="preload"
as="image"
type="image/webp"
href="/images/hero-1200.webp"
imagesrcset="/images/hero-400.webp 400w,
/images/hero-800.webp 800w,
/images/hero-1200.webp 1200w"
imagesizes="(max-width: 768px) 100vw, 1200px"
fetchpriority="high"
/>INP-Optimierung: Reaktionsfähigkeit sicherstellen
Interaction to Next Paint misst, wie reaktionsfähig deine Seite sich anfühlt. Jeder Klick, jedes Tippen und jede Tastatureingabe wird ausgewertet. Die Hauptursache für schlechte INP-Werte ist zu viel JavaScript auf dem Main Thread.
JavaScript reduzieren: Astros Zero-JS-Standard löst das für die meisten Seiten. Für interaktive Islands: halte jede Island unter 50 KB. Nutze dynamische Imports: client:visible hydriert erst, wenn die Komponente ins Sichtfeld scrollt.
Main Thread freigeben: Lang laufendes JavaScript blockiert den Main Thread. Wenn eine Funktion 300ms braucht, kann der Browser in dieser Zeit nicht auf Klicks reagieren. Zerlege lange Tasks in kleinere Stücke mit requestAnimationFrame() oder setTimeout(0). Ziel: kein einzelner Task über 50ms.
Inputs debouncen: Suchfelder, Filtersteuerungen und Scroll-Handler feuern Events schnell. Debounce Input-Handler mit 150–300ms Verzögerung. Verwende requestAnimationFrame() für Scroll-Handler.
JavaScript-Budget
| Ressource | Budget | Einfluss Recommended |
|---|---|---|
| Gesamt-JS pro Route | < 170 KB gzipped | INP + LCP |
| Einzelne Island | < 50 KB gzipped | INP |
| Drittanbieter-Skripte | < 50 KB gesamt | INP + LCP |
| Main-Thread-Arbeit | < 50ms pro Task | INP |
| Total Blocking Time | < 200ms | INP (Lab-Proxy) |
CLS-Optimierung: Visuelle Stabilität gewährleisten
Layout-Verschiebungen passieren, wenn sichtbare Elemente nach dem initialen Render ihre Position ändern. Wie du mit reinen CSS-Animationen statt JavaScript-Bibliotheken Layout-Shifts komplett vermeidest, zeigt mein SVG-Artikel. Aus Nutzerperspektive sind sie das frustrierendste Performance-Problem.
Layout-Verschiebungen eliminieren
- Immer Bilddimensionen setzen
Jedes <img> und <video> muss explizite width- und height-Attribute haben (oder CSS aspect-ratio). Der Browser reserviert den korrekten Platz, bevor das Asset lädt — keine Verschiebungen.
- font-display: swap klug einsetzen
Swap verhindert unsichtbaren Text, aber der Font-Wechsel selbst kann eine Verschiebung verursachen. Nutze die CSS size-adjust-Eigenschaft in @font-face, um die Fallback-Font-Metriken anzugleichen.
- Platz für dynamischen Inhalt reservieren
Werbung, Embeds, Cookie-Banner und lazy-geladene Komponenten müssen eine definierte min-height oder aspect-ratio haben, bevor sie laden.
- Banner nicht oben einfügen
Ein Cookie-Consent-Banner, das die Seite nach unten drückt, verursacht einen massiven CLS-Spike. Verwende fixed/sticky Positionierung oder Overlay-Muster.
- Nur mit transform animieren
CSS-Eigenschaften wie top, left, width und height lösen Layout-Neuberechnungen aus. Nutze transform: translateX/Y und opacity für Animationen. Diese werden auf der GPU composited.
CSS-Performance-Strategie
CSS beeinflusst sowohl LCP als auch CLS. Ein effizienter CSS-Ansatz umfasst drei Ebenen:
Kritisches CSS inline einbinden: Styles für Above-the-Fold-Inhalt direkt im <style>-Tag im <head>. Unter 14 KB halten (ein TCP Round-Trip). Das umfasst Base-Reset, Layout, Header, Hero und Basis-Typografie.
<style>
:root { --color-bg: #f9fafb; --color-text: #111827; }
body { font-family: system-ui; color: var(--color-text); }
.header { display: flex; align-items: center; }
.hero { min-height: 60vh; }
</style>Nicht-kritisches CSS deferren: Stylesheets für Below-the-Fold-Inhalt mit dem media="print" Trick laden, um Render-Blocking zu vermeiden:
<link
rel="stylesheet"
href="/styles/below-fold.css"
media="print"
onload="this.media='all'"
/>
<noscript>
<link rel="stylesheet" href="/styles/below-fold.css" />
</noscript>Font-Loading mit Metrik-Overrides optimieren: Um den CLS-Impact von Font-Swaps zu minimieren:
@font-face {
font-family: 'Inter';
src: url('/fonts/inter-var.woff2') format('woff2');
font-weight: 100 900;
font-display: swap;
size-adjust: 107%;
ascent-override: 90%;
descent-override: 22%;
line-gap-override: 0%;
}Performance-Mess-Workflow
Zu wissen, was und wie man misst, ist die halbe Miete. Lab-Tools liefern reproduzierbare Ergebnisse zum Debuggen — aber nur Felddaten zeigen, was echte Nutzer erleben.
Lab-Tools (zum Debuggen): Lighthouse (Chrome DevTools, CI) für synthetische Tests unter kontrollierten Bedingungen. Im Inkognito-Modus ausführen, ohne Erweiterungen, mit gedrosselter Verbindung (Slow 4G). WebPageTest liefert Filmstreifen-Vergleiche und Wasserfall-Diagramme.
Felddaten (für die Wahrheit): Chrome UX Report (CrUX) sammelt echte Nutzerdaten von Chrome-Nutzern, die zugestimmt haben. Das ist, was Google tatsächlich fürs Ranking verwendet. Zugang über PageSpeed Insights, Search Console oder die CrUX API.
Kontinuierliches Monitoring: Lighthouse CI in der Deployment-Pipeline einrichten. Jede PR durchläuft ein Performance-Audit. Budgets setzen: LCP unter 2,5s, INP unter 200ms, CLS unter 0,1, Gesamt-JS unter 170 KB. Build fehlschlagen lassen, wenn Budgets überschritten werden. CrUX-Daten monatlich über die Search Console überwachen.
Die Performance-Checkliste
WebP/AVIF-Formate. Explizite Dimensionen. Responsives srcset. LCP eager laden. Below-fold lazy laden.
Self-hosted WOFF2. font-display: swap. Kritische Fonts preloaden. size-adjust für CLS-Prävention.
Kritisches CSS inline. Nicht-kritisches deferren. Unter 50 KB kritischer Pfad. Keine ungenutzten Styles.
Unter 170 KB pro Route. Islands für Interaktivität. Dynamische Imports. Kein Main-Thread-Blocking.
CDN-Auslieferung. Brotli-Kompression. Cache-Header. Preconnect für externe Origins.
Lighthouse CI in Pipeline. CrUX-Felddaten monatlich. Performance-Budgets durchgesetzt.
Optimierungsreihenfolge: Was zuerst angehen?
Performance-Optimierung priorisieren
- CDN und Kompression aktivieren
Der schnellste Einzelgewinn: statische Seite auf CDN (Netlify, Vercel, Cloudflare Pages) hosten. Brotli-Kompression aktivieren. Far-Future Cache-Header setzen. Allein das kann 500ms+ beim LCP einsparen.
- Bilder optimieren
Bilder zu WebP/AVIF konvertieren. Responsives srcset generieren. LCP-Bild mit eager und fetchpriority=high laden. Below-fold-Bilder lazy laden. Explizite width/height setzen. Diese Phase spart typischerweise 1-3 Sekunden beim LCP.
- Fonts und CSS optimieren
Fonts self-hosten als WOFF2. font-display: swap setzen. Kritische Fonts preloaden. Kritisches CSS inline einbinden. Nicht-kritisches CSS deferren. Ungenutztes CSS entfernen.
- JavaScript auditieren und reduzieren
Drittanbieter-Skripte auditieren — jedes einzelne auf seinen Mehrwert prüfen. Schwere Bibliotheken durch leichtere ersetzen. Astro Islands mit client:visible für verzögerte Hydration nutzen. JS-Budgets setzen und in CI durchsetzen.
- Monitoring einrichten
Lighthouse CI in die Deployment-Pipeline einrichten. CrUX-Daten monatlich überwachen. Performance-Budgets als Gate-Kriterien für Deployments definieren. Regressionen erkennen, bevor sie Nutzer erreichen.
Performance-Zeitplan
CDN + Kompression aktivieren. Explizite Bilddimensionen. Self-hosted Fonts mit font-display: swap. Ungenutztes CSS/JS entfernen. Das allein bringt die meisten Seiten in den "Gut"-Bereich.
Bilder zu WebP/AVIF konvertieren. Responsives srcset generieren. LCP-Bild preloaden. Below-fold-Bilder lazy laden. Spart typischerweise 1-3 Sekunden beim LCP.
Drittanbieter-Skripte auditieren. Schwere Bibliotheken durch leichtere Alternativen ersetzen. Astro Islands mit client:visible für verzögerte Hydration. JS-Budgets setzen und durchsetzen.
Lighthouse CI in Deployment-Pipeline einrichten. CrUX-Daten monatlich überwachen. Performance-Budgets erstellen. Regressionen erkennen, bevor sie Nutzer erreichen.
Vorher/Nachher: Typische Optimierungsergebnisse
| Metrik | Vor Optimierung | Nach Optimierung | Verbesserung Recommended |
|---|---|---|---|
| LCP | 4,2 Sekunden | 1,8 Sekunden | -57% |
| INP | 380ms | 120ms | -68% |
| CLS | 0,35 | 0,04 | -89% |
| Lighthouse Score | 52 | 98 | +88% |
| Gesamt-JS | 420 KB | 85 KB | -80% |
| Gesamt-CSS | 180 KB | 45 KB | -75% |
| Bildgröße (Hero) | 2,4 MB (PNG) | 180 KB (AVIF) | -92% |
| TTFB | 650ms | 45ms | -93% |
Diese Zahlen sind keine Theorie — sie spiegeln typische Ergebnisse wider, die bei der Migration von WordPress- oder SPA-basierten Seiten zu optimierten Astro-Builds erreicht werden.
Häufige Fehler und Missverständnisse
Frequently Asked Questions
Lighthouse läuft auf deinem schnellen Entwickler-Rechner mit simulierter Drosselung. Echte Nutzer sind auf 3 Jahre alten Android-Handys mit 3G-Verbindung. Prüfe immer CrUX-Felddaten (über PageSpeed Insights oder Search Console). Das 75. Perzentil echter Nutzer ist, was Google fürs Ranking verwendet — nicht dein lokaler Lighthouse-Score.
Nein. Das LCP-Bild (meist das Hero-Bild) muss eager geladen werden mit fetchpriority="high". Lazy-loade nur Bilder, die below the fold sind — Bilder, die der Nutzer erst beim Scrollen sieht. Lazy Loading des LCP-Bilds fügt 200-500ms zur LCP-Zeit hinzu.
Astro gibt dir eine exzellente Ausgangsbasis (kein JS, statisches HTML, scoped CSS). Aber du kannst trotzdem eine langsame Seite haben mit unoptimerten Bildern, zu vielen Drittanbieter-Skripten, render-blockenden Stylesheets oder einem langsamen Hosting-Anbieter. Astro übernimmt die Framework-Level-Performance — du übernimmst die Content-Level-Performance.
Erheblich. Eine statische Seite auf einem CDN (Netlify, Vercel, Cloudflare Pages) hat eine TTFB von 20-50ms weltweit. Dieselbe Seite auf einem Single-Region Shared Host kann 200-800ms TTFB haben. Für statische Astro-Seiten: immer ein CDN verwenden. Der Unterschied beträgt oft 500ms+ beim LCP.
Ja, besonders für Seiten mit vielen Assets. HTTP/2 ermöglicht Multiplexing (mehrere Dateien über eine Verbindung). HTTP/3 mit QUIC reduziert zusätzlich die Latenz bei instabilen Verbindungen. Die meisten CDN-Anbieter unterstützen HTTP/3 automatisch — es muss in der Regel nur aktiviert werden.
Service Worker lohnen sich für wiederkehrende Besucher und Offline-Szenarien. Sie können Assets im Cache halten und bei Folgebesuchen sofort ausliefern. Für eine rein statische Seite mit CDN ist der Mehrwert gering — das CDN übernimmt bereits effektives Caching. Service Worker sind sinnvoll bei Apps mit häufigen Wiederbesuchen.
Nein, wenn korrekt implementiert. Dark Mode über CSS Custom Properties (Design Tokens) hat null Performance-Impact — die Werte werden in der CSS-Kaskade aufgelöst, ohne zusätzliches JavaScript. Problematisch wird es nur, wenn Dark Mode per JavaScript-Theme-Switching implementiert wird, das den gesamten Stil-Baum neu berechnet.
Wie CSS Custom Properties und Design Tokens dein Styling wartbar und performant halten, erfährst du im Design-Tokens-Guide.