Optimierung der Core Web Vitals
Zielgerichtete Optimierung der drei Core Web Vitals unter Verwendung von Felddaten zur Identifizierung der Nutzerauswirkungen und Browser-Traces zur Diagnose der Ursachen.
Messen vor dem Optimieren
Wenn eine ausführbare URL verfügbar ist, lesen Sie den Arbeitsablauf zur Leistungsmessung. Bevorzugen Sie diese Reihenfolge:
- Überprüfen Sie die CrUX-p75-Daten auf Seitenebene, mit einer klar gekennzeichneten Ursprungsalternative, wenn Seitendaten nicht verfügbar sind.
- Zeichnen Sie einen Browser-Leistungstrace unter den angegebenen Bedingungen auf. Mit Chrome DevTools MCP können Trace-Zusammenfassungen CrUX zusammen mit den beobachteten Labormetriken enthalten.
- Analysieren Sie nur die Erkenntnisse, die mit der fehlschlagenden Metrik zusammenhängen, und überprüfen Sie dann den betroffenen Code und die betroffenen Ressourcen.
- Führen Sie nach der Behebung gleichwertige Labormessungen erneut durch. Beanspruchen Sie keine sofortige Feldverbesserung; CrUX und First-Party-RUM benötigen neue Nutzerbesuche.
Wenn nur Quellcode verfügbar ist, identifizieren Sie wahrscheinliche Ursachen, aber behaupten Sie nicht, dass LCP, INP oder CLS fehlschlagen, ohne Laufzeitnachweise.
Die drei Metriken
| Metrik | Misst | Gut | Verbesserungswürdig | Schlecht |
|---|---|---|---|---|
| LCP | Laden | ≤ 2,5 s | 2,5 s – 4 s | > 4 s |
| INP | Interaktivität | ≤ 200 ms | 200 ms – 500 ms | > 500 ms |
| CLS | Visuelle Stabilität | ≤ 0,1 | 0,1 – 0,25 | > 0,25 |
Google misst am 75. Perzentil – 75 % der Seitenbesuche müssen die „Gut“-Schwellenwerte erfüllen.
LCP: Largest Contentful Paint
LCP misst, wann das größte sichtbare Inhaltselement gerendert wird. Normalerweise ist dies:
- Hero-Bild oder -Video
- Großer Textblock
- Hintergrundbild
<svg>-Element
Häufige LCP-Probleme
1. Langsame Serverantwort (TTFB > 800 ms)
Behebung: CDN, Caching, optimiertes Backend, Edge-Rendering
2. Renderblockierende Ressourcen
<!-- ❌ Blockiert das Rendern -->
<link rel="stylesheet" href="/all-styles.css">
<!-- ✅ Kritisches CSS inline, Rest verzögert -->
<style>/* Kritisches CSS oberhalb der Falz */</style>
<link rel="preload" href="/styles.css" as="style"
onload="this.onload=null;this.rel='stylesheet'">
3. Langsame Ressourcenladezeiten
<!-- ❌ LCP-Bild wird erst entdeckt, nachdem ein Stylesheet geladen ist -->
<div class="hero"></div>
<!-- ✅ Im initialen HTML auffindbar und priorisiert -->
<link rel="preload" href="/hero.webp" as="image" fetchpriority="high">
<img src="/hero.webp" alt="Hero" fetchpriority="high">
Bevorzugen Sie ein auffindbares <img> mit fetchpriority="high". Fügen Sie das Preload nur hinzu, wenn der Trace zeigt, dass die Ressource sonst spät entdeckt würde; doppelte oder spekulative Preloads können um Bandbreite konkurrieren.
4. Verzögerungen durch clientseitiges Rendern
// ❌ Inhalt lädt nach JavaScript
useEffect(() => {
fetch('/api/hero-text').then(r => r.json()).then(setHeroText);
}, []);
// ✅ Serverseitiges oder statisches Rendering
// Verwenden Sie SSR, SSG oder Streaming, um HTML mit Inhalt zu senden
export async function getServerSideProps() {
const heroText = await fetchHeroText();
return { props: { heroText } };
}
5. Navigationen mit der Speculation Rules API sofort machen
Für Websites mit vorhersagbaren Same-Origin-Pfaden kann das Vorab-Rendern einer wahrscheinlichen nächsten Seite eine erfolgreiche Folgenavigation viel schneller machen. Behandeln Sie dies als eine gemessene Navigationsoptimierung, nicht als Ersatz für die Behebung des LCP der aktuellen Seite.
<script type="speculationrules">
{
"prerender": [{
"where": { "href_matches": "/*" },
"eagerness": "moderate"
}]
}
</script>
Das aktuelle Chrome-Verhalten ist spezifisch genug, um die Wahl zu leiten:
eagerness | Auslöser |
|---|---|
conservative | Zeiger- oder Berührungsereignis |
moderate | Desktop: 200 ms Hover oder früheres Zeigerereignis; Mobil: Viewport-Heuristiken |
eager | Chrome 143+: Desktop 10 ms Hover; Mobil 50 ms nachdem der Anker in den Viewport eintritt |
immediate | Sobald die Regeln beobachtet werden |
Beginnen Sie konservativ und messen Sie die Vorhersagetrefferquote, die übertragenen Bytes, die Serverlast und die Navigationsverbesserung, bevor Sie die Regeln erweitern. Überprüfen Sie die von Chrome gepflegte Eagerness-Dokumentation, bevor Sie zeitkritisches Verhalten fest codieren.
Einschränkungen:
- Bandbreiten-/CPU-Kosten. Jedes Vorab-Rendern entspricht in etwa einem vollständigen Seitenladen. Begrenzen Sie
wheresorgfältig (href_matches-Muster, schließen Sie Logout/Checkout aus) und vermeiden Sieimmediateaußerhalb kleiner Websites. - Nebenwirkungen treten früh auf. Analysen, Werbung und jeder Code, der beim Laden ausgeführt wird, werden ausgelöst, wenn das Vorab-Rendern beginnt, nicht wenn der Nutzer navigiert. Sperren Sie Nebenwirkungen hinter dem
prerenderingchange-Ereignis oderdocument.prerendering. - Nur Chromium. Safari und Firefox ignorieren das Skript – es ist eine progressive Verbesserung, niemals eine Regression.
LCP-Optimierungs-Checkliste
- [ ] TTFB < 800 ms (CDN, Edge-Caching verwenden)
- [ ] LCP-Ressource ist im initialen HTML auffindbar und priorisiert; Preload nur, wenn der Trace eine späte Entdeckung zeigt
- [ ] LCP-Bild optimiert (WebP/AVIF, korrekte Größe)
- [ ] Kritisches CSS inline (< 14 KB)
- [ ] Kein renderblockierendes JavaScript im <head>
- [ ] Schriftarten blockieren nicht die Textwiedergabe (font-display: swap)
- [ ] LCP-Element im initialen HTML (nicht JS-gerendert)
- [ ] Speculation Rules für wahrscheinliche nächste Navigationen hinzugefügt (moderate eagerness)
Identifizierung des LCP-Elements
Dieser Codeausschnitt diagnostiziert die aktuelle Seitensitzung. Es sind keine Felddaten.
// Finden Sie Ihr LCP-Element
new PerformanceObserver((list) => {
const entries = list.getEntries();
const lastEntry = entries[entries.length - 1];
console.log('LCP-Element:', lastEntry.element);
console.log('LCP-Zeit:', lastEntry.startTime);
}).observe({ type: 'largest-contentful-paint', buffered: true });
INP: Interaction to Next Paint
INP misst die Reaktionsfähigkeit bei Klicks, Berührungen und Tastendrücken während eines Besuchs. Diagnostizieren Sie die Eingabeverzögerung, die Verarbeitungszeit und die Darstellungsverzögerung getrennt; eine langsame Interaktion kann Main-Thread-Konflikte vor dem Handler, teure Anwendungsarbeit oder verzögertes Rendern danach beinhalten.
Wenn das Feld-INP schlecht ist oder ein Trace eine langsame Interaktion identifiziert, lesen Sie die INP-Referenz für Trace-Interpretation, Yielding-Muster, Drittanbieter- und Rendering-Ursachen, einen Single-Session-Observer und First-Party-Zuordnung.
CLS: Cumulative Layout Shift
CLS misst unerwartete Layout-Verschiebungen während eines Seitenbesuchs. Verwenden Sie Feldzuordnung oder einen Trace, um den verschobenen Knoten und den Auslöser zu identifizieren; gehen Sie nicht davon aus, dass das sichtbare Opfer die Verschiebung verursacht hat.
Wenn das Feld-CLS schlecht ist oder ein Trace Verschiebungen meldet, lesen Sie die CLS-Referenz für reservierte-Platz-Muster, dynamische Inhalte, Schriftarten- und Animationskorrekturen, einen Debugging-Observer und eine Überprüfungscheckliste.
Messquellen
| Quelle | Verwendung |
|---|---|
Browser-Leistungstrace (Chrome DevTools MCP: performance_start_trace) | Beobachten Sie einen Ladevorgang oder eine Interaktion und diagnostizieren Sie fokussierte Erkenntnisse; verwenden Sie den enthaltenen CrUX-Kontext, wenn verfügbar |
| CrUX oder Search Console | Priorisieren Sie aggregierte reale Nutzerergebnisse bei p75 |
| Lighthouse CLI oder PageSpeed Insights | Kontrollierte Laboralternative, wenn DevTools-Tools nicht verfügbar sind |
| First-Party-RUM | Segmentieren Sie die aktuelle Produktionserfahrung nach Route, Gerät, Release und Attribution |
Roher PerformanceObserver | Untersuchen Sie eine Seitensitzung während des Debuggings |
Leiten Sie die Leistung nicht über lighthouse_audit des Chrome DevTools MCP; diese Fähigkeit deckt absichtlich nicht-leistungsbezogene Lighthouse-Kategorien ab. Vergleichen Sie keinen einzelnen Laborwert direkt mit einem Feld-p75, als ob es sich um gleichwertige Stichproben handelte.
Wenn Sie eine Produktionserfassung hinzufügen oder überprüfen, lesen Sie die First-Party-RUM-Referenz. Bevorzugen Sie die web-vitals-Bibliothek, weil rohe Browser-APIs nicht von sich aus alle Lebenszyklus- und Melde-Regeln der Core Web Vitals implementieren.
Framework-Kurzlösungen
Next.js
// LCP: next/image mit priority verwenden
import Image from 'next/image';
<Image src="/hero.jpg" priority fill alt="Hero" />
// INP: Dynamische Importe verwenden
const HeavyComponent = dynamic(() => import('./Heavy'), { ssr: false });
// CLS: Image-Komponente behandelt Abmessungen automatisch
React
// LCP: Preload im head
<link rel="preload" href="/hero.jpg" as="image" fetchpriority="high" />
// INP: Memoize und useTransition
const [isPending, startTransition] = useTransition();
startTransition(() => setExpensiveState(newValue));
// CLS: Immer Abmessungen in img-Tags angeben
Vue/Nuxt
<!-- LCP: nuxt/image mit preload verwenden -->
<NuxtImg src="/hero.jpg" preload loading="eager" />
<!-- INP: Async-Komponenten verwenden -->
<component :is="() => import('./Heavy.vue')" />
<!-- CLS: aspect-ratio CSS verwenden -->
<img :style="{ aspectRatio: '16/9' }" />
Referenzen
- Detaillierte LCP-Optimierung – lesen, wenn ein LCP-Trace auf Verzögerungen bei der Entdeckung, dem Laden oder dem Rendern hinweist
- Detaillierte INP-Optimierung – lesen, wenn ein Trace oder eine Feldzuordnung eine langsame Interaktion identifiziert
- Detaillierte CLS-Optimierung – lesen, wenn ein Trace oder eine Feldzuordnung unerwartete Verschiebungen identifiziert
- web.dev LCP
- web.dev INP
- web.dev CLS
- Leistungs-Skill