Die ultimative Core Web Vitals-Checkliste (2026)

Table of Contents!

• Die ultimative Core Web Vitals-Checkliste
• Checkliste zur Core Web Vitals-Optimierung
  • Bilder optimieren
  • Webfonts optimieren
  • Skripte optimieren
  • Styles optimieren
  • Resource Hints optimieren
  • Icons optimieren
  • Server-Antwortzeiten optimieren
  • Interaktivität optimieren
  • Core Web Vitals-Monitoring
  • Kritischen Rendering-Pfad optimieren
  • Cookie-Einwilligung optimieren
  • Single Page Applications optimieren
  • Zu große DOM-Größe vermeiden
  • API-Requests optimieren
  • Chat-Widgets optimieren
  • Service-Worker-Performance optimieren
  • Videoinhalte optimieren

Bilder optimieren

Große Bilder im sichtbaren Viewport werden meistens zum Largest Contentful Paint-Element. Die Optimierung von Bildern ist eine der effektivsten Maßnahmen für den LCP. Nutze diese Core Web Vitals-Checklistenpunkte, um Bilder schneller zu laden. Lies für die vollständige Strategie unseren Leitfaden, wie du das LCP-Bild optimierst.

• Passe die Bildgrößen an die maximalen Anzeigemaße an: So verschwendest du keine Bytes für den Download von Bildern, die größer als ihre maximale Anzeigegröße sind. Kombiniere dieses Vorgehen mit responsiven Bildern für kleinere Bildschirmgrößen. Die Auslieferung von Bildern in der richtigen Größe senkt die Dateigröße um 50 % oder mehr, ohne sichtbaren Qualitätsverlust.
• Nutze lazy loading für Bilder unterhalb des sichtbaren Bereichs: Lazy loading verzögert das Laden von Bildern außerhalb des Viewports, bis sie in den sichtbaren Bereich gescrollt werden. Das verbessert den First Contentful Paint (FCP) und die gesamte Ladezeit der Seite. Verwende niemals lazy loading für das LCP-Bild, da dies dessen Laden erheblich verzögert.
• Lade visuell wichtige Bilder wie das LCP-Element vor: Das Vorladen weist den Browser an, kritische Bilder vor dem Rest des Inhalts abzurufen, um den LCP zu priorisieren. Nutze <link rel="preload" as="image"> in Kombination mit fetchpriority="high" für optimale Ergebnisse. Das ist besonders wichtig, wenn das LCP-Bild in CSS referenziert oder per JavaScript geladen wird.
• Lege Breite und Höhe fest: Wenn du Bildmaße im Voraus definierst, verhinderst du Layout-Verschiebungen, während der Browser auf das Laden der Bilder wartet. Das verbessert den CLS. Moderne Browser nutzen die Attribute „width“ und „height“, um das Seitenverhältnis vor dem Laden des Bildes zu berechnen und den benötigten Platz zu reservieren.
• Nutze moderne Bildformate wie WebP oder AVIF: Diese Formate bieten im Vergleich zu JPEG oder PNG kleinere Dateigrößen bei gleicher Qualität, was zu kürzeren Ladezeiten führt. WebP erzielt in der Regel um 25–34 % kleinere Dateien als JPEG, während AVIF die Dateigröße um bis zu 50 % reduzieren kann. Nutze das <picture>-Element mit Format-Fallbacks für maximale Browserkompatibilität.
• Nutze natives lazy loading und deaktiviere JavaScript-basiertes lazy loading: Lazy loading verzögert das Laden von Bildern außerhalb des Viewports, bis sie in den sichtbaren Bereich gescrollt werden. Natives lazy loading über das Attribut loading="lazy" ist in der Regel effizienter als JavaScript-Lösungen, da es kein zusätzliches Parsen oder Ausführen von Skripten erfordert.
• Nutze responsive Bilder mit srcset: Dieses Attribut definiert verschiedene Bildversionen für unterschiedliche Bildschirmgrößen. So liefert der Browser das optimale Bild für das Gerät des Nutzers und verhindert unnötig große Downloads. Kombiniere srcset mit dem Attribut sizes für eine präzise Steuerung.
• Füge decoding="async" hinzu: Das Attribut decoding="async" verhindert, dass der Browser beim Decodieren eines Bildes andere Inhalte blockiert. So kann die Rendering-Engine andere Elemente weiter zeichnen, während das Bild parallel decodiert wird.
• Entferne Bild-Metadaten: In Bildern eingebettete Metadaten wie EXIF-Daten erzeugen unnötige Bytes. Das Entfernen dieser Informationen reduziert die Dateigröße, ohne die Bildqualität zu beeinträchtigen. Tools wie ImageOptim, Squoosh oder Sharp können das Entfernen von Metadaten als Teil deines Build-Prozesses automatisieren.
• Vermeide CSS-Hintergrundbilder für LCP-Elemente: In CSS referenzierte Hintergrundbilder werden vom Browser später entdeckt als <img>-Elemente in HTML. Wenn du ein Hintergrundbild als LCP-Element verwenden musst, lade es vorab mit einem <link rel="preload">-Tag, um eine frühe Entdeckung sicherzustellen. Erfahre mehr über die LCP-Ressourcen-Ladeverzögerung.

Webfonts optimieren

Webfonts können den First Contentful Paint verzögern, Layout-Verschiebungen verursachen und früh um Bandbreite konkurrieren. Nutze diese Checkliste für eine reibungslose Webfont-Nutzung. Best Practices zum Font-Hosting findest du in unserer Anleitung zum Selbsthosten von Google Fonts.

• Nutze font-display: swap für einen schnelleren ersten Paint: Setze die Eigenschaft font-display auf swap in deinen @font-face-Deklarationen. Dadurch zeigt der Browser sofort eine Fallback-Schriftart an, während er den Webfont im Hintergrund lädt. Sobald die Schriftart bereit ist, tauscht er sie nahtlos aus. Lies mehr darüber, wie du sicherstellst, dass Text während des Ladens von Webfonts sichtbar bleibt.
• Nutze font-display: optional kombiniert mit Preloading, um durch Schriftarten verursachte Layout-Verschiebungen zu eliminieren: Die Kombination von font-display: optional mit Preloading bietet eine Balance zwischen Geschwindigkeit und potenziellen Layout-Verschiebungen. Der Wert optional blendet Text kurz aus (ca. 100 ms), bevor eine Fallback-Schriftart verwendet wird. Preloading weist den Browser an, den Webfont früh zu laden. Dies minimiert die Zeit für Fallback-Schriftarten und reduziert Layout-Verschiebungen.
• Nutze font-face-Deskriptoren, damit die Fallback-Schriftart den Dimensionen des Webfonts entspricht: Dies sorgt für einen minimalen CLS, wenn der Webfont eingewechselt wird. Durch die Angabe ähnlicher Metriken mittels size-adjust, ascent-override, descent-override und line-gap-override für die Fallback-Schriftart verhinderst du, dass Inhalte beim Laden der Schriftart springen.
• Erstelle Subsets von Schriftarten, um nur benötigte Zeichen einzubinden: Reduziere die Dateigröße durch Subsetting der Schriftarten auf die Zeichen, die du für deine Inhalte benötigst. Tools wie Font Squirrel, pyftsubset oder glyphhanger helfen beim Generieren von Subsets. Eine Schriftart mit vollem lateinischen Zeichensatz lässt sich durch korrektes Subsetting oft von über 100 KB auf unter 20 KB reduzieren.
• Begrenze die Anzahl der Schriftgewichte und -stile: Vermeide das Laden zu vieler Schriftvarianten. Beschränke dich auf maximal 2 kritische Schriftarten (meist preloaded) und 2 nachgeladene Schriftarten (geladen nach dem ersten Rendering). Jedes zusätzliche Schriftgewicht erhöht die Download-Größe um 15 bis 50 KB.

Skripte optimieren

Skripte können Interaction to Next Paint-Probleme verursachen, Cumulative Layout Shifts auslösen oder den Largest Contentful Paint verzögern. Selbst optimierte und relativ harmlose frühe Skripte können um Ressourcen konkurrieren und Paint-Metriken (LCP und FCP) verzögern. Eine vollständige Anleitung findest du unter 14 Methoden, um JavaScript aufzuschieben.

• Unnötiges JavaScript entfernen: Identifiziere und eliminiere ungenutzten JavaScript-Code, um die geladene und ausgeführte Codemenge zu minimieren. Nutze den Coverage-Tab der Chrome DevTools, um ungenutzten Code zu finden. Das Entfernen von totem Code reduziert sowohl die Downloadzeit als auch die Verarbeitung im main thread.
• Priorisiere Skripte nach Funktion und Wichtigkeit: Skripte, die große Änderungen am sichtbaren viewport vornehmen, sollten render blocking sein. Wichtige Skripte sollten aufgeschoben oder asynchron geladen werden. Optionale Skripte sollten bei Browser-Leerlauf laden. Eine detaillierte Strategie findest du in unserem Leitfaden zur Ressourcen-Priorisierung.
• Code-Splitting und lazy loading: Teile große JavaScript-Bundles in kleinere Chunks auf und lade sie nur bei Bedarf. Das verkürzt die initiale Ladezeit. Moderne Bundler wie webpack, Rollup und esbuild unterstützen automatisches Code-Splitting über dynamische Importe.
• JavaScript-Dateien minifizieren und rekompilieren: Minifiziere und rekompiliere deine JavaScript-Dateien immer mit einem Minification-Tool wie SWC, Terser oder esbuild. Eine Minifizierung reduziert die Dateigröße von JavaScript meist um 30 bis 50 %.
• Drittanbieter-Skripte einschränken: Drittanbieter-Skripte können erheblichen Performance-Overhead verursachen. Prüfe, ob sie wirklich notwendig sind, und suche nach Alternativen. Jedes Drittanbieter-Skript verursacht DNS-Lookups, Verbindungs-Overhead und zusätzliche Verarbeitungszeit im main thread. Analysiere Drittanbieter-Skripte regelmäßig mit dem Network-Panel der Chrome DevTools.
• Drittanbieter-Skripte asynchron laden: Da Drittanbieter-Skripte unberechenbar sind, lass niemals zu, dass sie das Rendering blockieren. Verwende das Attribut async oder defer bei allen Skript-Tags von Drittanbietern.
• Performance von Drittanbieter-Skripten überwachen: Nutze die Long Animation Frames (LoAF) API oder CoreDash, um die realen Auswirkungen von Drittanbieter-Skripten auf INP und LCP zu verfolgen. Setze Performance-Budgets für Drittanbieter-JavaScript und überprüfe sie regelmäßig.

Styles optimieren

Styles sind standardmäßig render blocking. Die Optimierung von Styles führt zu optimierten Paint-Metriken. Nutze diese Checkliste, um die Style-Performance deiner Webseite zu verbessern. Render blocking CSS wirkt sich direkt auf den First Contentful Paint und den LCP element render delay aus. Tipps zum Bereinigen ungenutzter Styles findest du unter wie du ungenutztes CSS entfernst.

• CSS-Dateien minifizieren: Entferne nicht benötigte Zeichen wie Leerzeichen, Kommentare und Formatierungen aus den CSS-Dateien. Minifizierte Dateien sind kleiner. Das sorgt für schnellere Ladezeiten. Tools wie cssnano, PostCSS oder die integrierte Komprimierung deines CSS-Präprozessors können dies automatisieren.
• Ungenutztes CSS entfernen: Identifiziere und entferne CSS-Code, der auf deinen Webseiten nicht verwendet wird. Das reduziert die Datenmenge, die der Browser herunterladen und parsen muss, und verbessert die Performance. Tools wie PurgeCSS oder der Coverage-Tab der Chrome DevTools helfen dabei, ungenutztes CSS zu identifizieren.
• Kritisches CSS inlinen: Liefere Styles, die für das Rendering des initialen Seiteninhalts wichtig sind, direkt im HTML aus. Das verbessert die Paint-Metriken. Überlege, kritisches CSS nur für neue Besucher bereitzustellen. Für wiederkehrende Besucher kannst du gecachte externe Stylesheets nutzen. Diese Technik kann den FCP reduzieren, da der Roundtrip zum Laden eines externen Stylesheets entfällt.
• CSS-Dateigrößen gleichmäßig verteilen: Es mag effizient erscheinen, das gesamte CSS in einer einzigen Datei zusammenzufassen. Zu große Dateien können jedoch den Download verlangsamen. Teile das CSS in kleinere Dateien mit einer gleichmäßigeren Größenverteilung auf (jeweils 10 bis 15 KB). Das optimiert das Laden und ermöglicht dem Browser, Styles inkrementell zu verarbeiten.
• Offscreen-Styles asynchron laden: Lade Styles für Elemente außerhalb des initialen Viewports asynchron. Verwende dazu das Pattern media="print" onload="this.media='all'". Dadurch lädt der Browser diese Styles parallel zu anderen Ressourcen, ohne das initiale Rendering der Seite zu blockieren.

Resource Hints optimieren

Resource Hints priorisieren den Download kritischer Ressourcen. Vorab geladene Ressourcen werden früher für den Download eingereiht. Sie stehen dem Browser deutlich früher zur Verfügung als ohne Preloading. Der effektive Einsatz von Resource Hints reduziert die LCP-Ressourcen-Ladeverzögerung erheblich. Lies für fortgeschrittene Implementierungen über 103 Early Hints.

• Entferne nicht-kritische Resource Hints: Entferne Preload-Hints für Ressourcen, die für das initiale Laden der Seite nicht essenziell sind. Das verhindert unnötige Downloads oder Netzwerkverbindungen, die in der frühen Phase um die begrenzte Bandbreite konkurrieren. Jeder unnötige Preload verbraucht Bandbreite, die für kritische Ressourcen genutzt werden könnte.
• Verbinde kritische Domains vorab: Baue frühzeitig Verbindungen zu wichtigen Domains (wie Content Delivery Networks oder Font-Anbietern) auf. Das beschleunigt den Download kritischer Ressourcen von diesen Domains. DNS-, TCP- und TLS-Handshakes werden so im Voraus abgeschlossen. Nutze <link rel="preconnect" href="https://example.com"> für kritische Drittanbieter-Origins.
• Ziehe DNS-Prefetch als Alternative zu Preconnect in Erwägung: Ähnlich wie Preconnect weist auch DNS-Prefetch den Browser auf potenzielle Verbindungen hin. Preconnect priorisiert jedoch den Aufbau der vollständigen Verbindung. DNS-Prefetch weist den Browser lediglich an, den Domainnamen vorab aufzulösen. Nutze <link rel="dns-prefetch">, wenn der Overhead einer vollständigen Preconnect-Verbindung nicht gerechtfertigt ist.
• Lade das LCP-Element vorab: LCP misst, wie lange das Laden der Hauptinhalte dauert. Das Vorabladen des LCP-Elements weist den Browser an, den Download dieser kritischen Ressource zu priorisieren. Das verkürzt die Zeit, bis Nutzer die Hauptinhalte sehen. Das ist besonders wichtig für Bilder, die in CSS referenziert oder über JavaScript geladen werden.
• Lade kritische Fonts vorab: Das Vorabladen kritischer Fonts stellt sicher, dass der Browser diese frühzeitig abruft. Das verhindert Verzögerungen bei der Textdarstellung und reduziert Cumulative Layout Shifts, die durch Font-Swapping entstehen. Nutze <link rel="preload" as="font" type="font/woff2" crossorigin> für deine wichtigsten Schriftarten.
• Bevorzuge 103 Early Hints für Resource Hints: Der HTTP-Statuscode 103 Early Hints erlaubt es dem Server, Resource Hints zu senden, bevor die vollständige Antwort bereit ist. Wenn dein Server 103 nicht unterstützt, nutze stattdessen Link-Response-Header. Sind keine Header verfügbar, füge als Fallback <link>-Elemente in den <head> der Seite ein. Früher ausgelieferte Hints bedeuten eine schnellere Erkennung der Ressourcen.
• Lade Fonts vorab, bevor CSS-Dateien sie entdecken: In CSS referenzierte Fonts werden erst entdeckt, nachdem die CSS-Datei heruntergeladen und geparst wurde. Durch das Vorabladen der Fonts direkt im HTML-<head> eliminierst du die Abhängigkeit vom CSS-Parsing. Die Fonts laden parallel, was sowohl den FCP als auch das Layout-Shift-Risiko verringert.

Icons optimieren

Ohne Optimierung erhöhen Icons das Gewicht deiner Seite erheblich. Große Inline-SVG-Icons blähen dein HTML auf. Icon-Fonts enthalten oft Tausende ungenutzte Glyphen. Die Optimierung von Icons beeinflusst sowohl den LCP (geringeres HTML/CSS-Gewicht) als auch den CLS (Reservierung der Abmessungen).

• Vermeide Inline-SVG-Icons im HTML: Das Einbetten großer SVG-Icons vergrößert dein HTML und verlangsamt die Ladezeit. Nutze stattdessen separate Dateien oder – mit Vorsicht – Icon-Fonts. Das reduziert die HTML-Größe und ermöglicht Browser-Caching für die Icons. Ein externes SVG-Sprite-Sheet bietet oft die beste Balance aus Performance und Flexibilität.
• Vermeide große Icon-Fonts: Nutze große Icon-Sets wie Font Awesome niemals komplett. Erstelle per Subsetting optimierte Icon-Fonts oder nutze einzelne SVGs. Das reduziert die Gesamtgröße der Seite und beschleunigt das Laden. Ein komplettes Font-Awesome-Set kann über 100 KB groß sein. Ein Subset mit 20 Icons liegt oft unter 5 KB.
• Reserviere Breite und Höhe für Icons: Wie bei Bildern hilft die Angabe von Breite und Höhe dem Browser, Platz zu reservieren. Das verhindert Layout-Verschiebungen beim Laden. Nutze die Attribute width und height auf SVG-Elementen oder definiere explizite Maße im CSS.
• Priorisiere nicht-kritische Icon-Sets niedriger: Wenn Icons für das erste Rendern der Seite nicht kritisch sind, lade sie mit niedrigerer Priorität. Das stellt sicher, dass wichtiger Inhalt zuerst lädt, und minimiert die Auswirkungen auf die Core Web Vitals. Nutze lazy loading oder lade Icon-Stylesheets asynchron nach dem ersten Paint.

Server-Antwortzeiten optimieren

Die Server-Antwortzeit, gemessen per Time to First Byte (TTFB), beeinflusst alle Paint-Metriken direkt. Eine langsame Server-Antwort verzögert alle nachfolgenden Schritte. Detaillierte Optimierungsstrategien findest du in unseren Leitfänden zur Diagnose von TTFB-Problemen und zur Konfiguration von Cloudflare für Performance.

• Nutze einen schnellen und zuverlässigen Hosting-Anbieter: Ein schneller Hosting-Anbieter mit starker Infrastruktur kann die Server-Antwortzeiten und die gesamte Website-Performance erheblich verbessern. Vergleiche Hosting-Anbieter anhand von realen TTFB-Messungen, nicht anhand von synthetischen Marketing-Angaben.
• Optimiere serverseitigen Code und database queries: Protokolliere regelmäßig die Ausführungszeit von Code und Datenbankabfragen, um Engpässe zu finden und die Gesamtgeschwindigkeit zu erhöhen. Nutze Query-Profiling und Tools für Application Performance Monitoring (APM), um langsame Endpunkte zu identifizieren.
• Implementiere Caching-Strategien: Nutze Browser-Caching und serverseitiges Caching, um häufig aufgerufene Daten zu speichern. Das reduziert wiederholte Datenabfragen und verbessert die Ladezeiten. Full-Page-Caching kann die TTFB von Sekunden auf unter 100 ms senken. Erfahre mehr über die Optimierung der Cache-Dauer.
• Client-Side- oder Edge-Rendering für Personalisierung: Erwäge Client-Side- oder Edge-Rendering für kleine Personalisierungen wie Warenkorb-Zähler, Login-Status oder minimale Menüänderungen, um die Funktionsfähigkeit des Full-Page-Caches zu erhalten. Das verhindert Cache-Busting der gesamten Seite wegen kleiner dynamischer Elemente.
• Optimiere Server-Konfigurationen: Überprüfe und optimiere deine Webserver-Einstellungen für Performance. Dazu gehören Keep-Alive-Verbindungseinstellungen, die Anzahl der Worker-Prozesse, Speicherzuweisungen und Timeout-Werte. Fehlkonfigurierte Server verschwenden Ressourcen und erhöhen die Antwortzeiten.
• Nutze ein Content Delivery Network (CDN): Ein CDN verteilt die statischen Inhalte deiner Website über mehrere Edge-Knoten (Server). Das verkürzt die physische Distanz zum Nutzer und sorgt für schnellere Ladezeiten bei globalem Publikum. Zudem sind CDNs meist besser konfiguriert als dein eigener Server. Lies unseren Leitfaden zur Konfiguration von Cloudflare für eine praktische Anleitung.
• Reduziere die serverseitige Verarbeitung: Minimiere die Arbeit, die dein Server pro Anfrage leisten muss. Berechne aufwendige Operationen im Voraus, nutze effiziente Algorithmen und verlagere nicht essenzielle Aufgaben in Hintergrund-Jobs. Analysiere den Request-Lifecycle deiner Anwendung, um unnötige Verarbeitungsschritte zu finden und zu eliminieren.
• Nutze HTTP/3: HTTP/3 ist die neueste Version des Hypertext Transfer Protocol. HTTP/3 ist schneller und effizienter als HTTP/2 und deutlich schneller als HTTP/1.1. Ein Upgrade auf HTTP/3 kann die Ladezeit der Seite insgesamt verkürzen und potenziell alle drei Core Web Vitals-Metriken (LCP, INP, CLS) verbessern. Erfahre mehr über die Optimierung der Verbindungsdauer.
• Richte Server-Timing-Header ein: Diese Header liefern detaillierte Informationen darüber, wie lange die Verarbeitung einzelner Seitenteile auf dem Server dauert. Mit diesen Daten kannst du Engpässe und Optimierungsbereiche genau identifizieren, insbesondere zur Verbesserung des Largest Contentful Paint (LCP). Server-Timing-Header sind im Chrome DevTools Network-Panel sichtbar und können von RUM-Tools wie CoreDash erfasst werden.
• Protokolliere langsame Datenbankabfragen und optimiere sie regelmäßig: Aktiviere das Logging langsamer Abfragen in deiner Datenbank (MySQL, PostgreSQL, MongoDB) und überprüfe die Logs wöchentlich. Index-Optimierungen, Query-Restrukturierungen und zusätzliche Caching-Layer für häufige Abfragen können die TTFB drastisch senken.
• Nutze GZIP- oder Brotli-Komprimierung: GZIP oder das neuere Brotli komprimieren textbasierte Ressourcen (HTML, CSS, JavaScript) direkt bei der Übertragung (on the fly). Das reduziert die Dateigröße um etwa 70 %. Brotli erzielt in der Regel eine 15 bis 20 % bessere Komprimierung als GZIP. Kleinere Dateigrößen bedeuten schnellere Ladezeiten.

Interaktivität optimieren

Interaction to Next Paint (INP) misst, wie schnell deine Website auf Nutzerinteraktionen reagiert. Schlechte Interaktivität wird oft durch langlaufende JavaScript-Tasks verursacht, die den Main Thread blockieren. Eine genaue Aufschlüsselung der drei INP-Phasen findest du in unseren Leitfäden zu Eingabeverzögerung, Verarbeitungszeit und Präsentationsverzögerung.

• Implementiere ein „Idle-until-urgent“-Pattern für aufwendige Skripte: Dieser Ansatz priorisiert kritische Aufgaben und verzögert die Ausführung von nicht-essenziellem JavaScript, bis der Main browser thread im Leerlauf ist. Das stellt sicher, dass kritische Aufgaben wie das Rendering und Nutzerinteraktionen nicht durch langlaufende Skripte blockiert werden. Nutze requestIdleCallback, um nicht-dringende Aufgaben zu planen. Erfahre mehr über die Optimierung der Verarbeitungszeit.
• Teile Long Tasks auf, indem du an den Main Thread yieldest: Komplexe JavaScript-Tasks können den Main Thread blockieren und die Reaktionsfähigkeit verzögern. Zerteile diese Tasks in kleinere Chunks und yielde dazwischen an den Main Thread. So kann der Browser Nutzerinteraktionen verarbeiten und eine flüssige Nutzererfahrung aufrechterhalten. Nutze scheduler.yield() (sofern unterstützt) oder setTimeout(0), um Long Tasks aufzuteilen. Siehe unseren Leitfaden zur INP-Verbesserung durch den Verzicht auf JavaScript-Scrolling.
• Gib sofortiges Feedback nach Eingaben: Nutzer erwarten eine sofortige Reaktion, wenn sie mit deiner Website interagieren. Gib visuelle Hinweise oder bestätige die Eingabe sofort, selbst wenn im Hintergrund langlaufende Tasks ausgeführt werden. Nutze CSS-Transitions und die Pseudoklasse :active für sofortiges visuelles Feedback. Das erhält das Gefühl von Interaktivität. So verhinderst du, dass die Website für Nutzer wie eingefroren wirkt.
• Nutze passive Event-Listener für Scrollen und Touch: Füge { passive: true } zu Scroll- und Touch-Event-Listenern hinzu. Passive Listener signalisieren dem Browser, dass der Handler niemals preventDefault() aufruft. Dadurch kann er sofort mit dem Scrollen beginnen, ohne auf JavaScript zu warten. Das ist besonders auf Mobilgeräten spürbar und verbessert direkt das INP bei scrollnahen Interaktionen.

Core Web Vitals-Monitoring

Überwache deine Core Web Vitals kontinuierlich. So erkennst du Regressionen frühzeitig und validierst die Wirkung von Optimierungen. Kombiniere Labortools, field data und Real User Monitoring für ein vollständiges Bild.

• Prüfe regelmäßig mit Lighthouse: Lighthouse ist ein kostenloses Open-Source-Audit-Tool von Google. Es hilft dir, Performance-Probleme auf deinen Webseiten zu finden. Lighthouse misst die Core Web Vitals nicht direkt im echten Nutzerkontext. Es eignet sich aber hervorragend, um deine Website regelmäßig unter kontrollierten Standardbedingungen zu testen und zu vergleichen. Führe Lighthouse in CI/CD-Pipelines aus, um Regressionen vor dem Deployment abzufangen.
• Prüfe regelmäßig die historischen CrUX-Daten: CrUX (Chrome User Experience Report) ist ein öffentlicher Datensatz von Google mit echten Performance-Daten. Google nutzt diese Datenquelle, um das Bestehen der Core Web Vitals zu bewerten. Nutze die historischen Daten, um Regressionen schnell zu erkennen. Du kannst auf CrUX-Daten über PageSpeed Insights, das CrUX-Dashboard oder die CrUX-API zugreifen.
• Richte RUM-Tracking ein: RUM (Real User Monitoring) erfasst die echten Nutzererfahrungen auf deiner Website. RUM-Tools messen die tatsächliche Ladezeit deiner Seiten für Besucher an verschiedenen Standorten und auf unterschiedlichen Geräten. Das liefert wertvolle Einblicke in die reale Performance und ergänzt die simulierten Daten von Lighthouse und CrUX. Wir empfehlen CoreDash as dein RUM-Tracking-Tool für detaillierte Attributionsdaten der Core Web Vitals.
• Lege Performance-Budgets fest: Performance-Budgets definieren konkrete Performance-Ziele für verschiedene Metriken (zum Beispiel LCP unter 2,5 Sekunden, INP unter 200ms, CLS unter 0,1). Sie dienen als Benchmarks für deine Optimierungen. Prüfe deine Performance regelmäßig gegen diese Budgets. So erkennst du Schwachstellen sofort und priorisierst deine Arbeit richtig.
• Nutze Segmentierung: Nutze Segmentierung, um deine wertvollsten Besuchertypen und verschiedene Seitentypen zu überwachen. Große Traffic-Mengen verdecken sonst oft Performance-Probleme, die gezielt diese wichtigen Gruppen betreffen. Segmentiere nach Gerätetyp, Verbindungsgeschwindigkeit, Geografie und Seitenvorlage, um versteckte Probleme aufzudecken.

Kritischen Rendering-Pfad optimieren

Der kritische Rendering-Pfad ist die Abfolge von Schritten, die der Browser durchläuft, um HTML, CSS und JavaScript in sichtbare Pixel umzuwandeln. Die Optimierung dieses Pfads verbessert direkt den First Contentful Paint und die Renderverzögerung des LCP-Elements. Siehe auch wie du eine übermäßige DOM-Größe vermeidest.

• Minimiere die Anzahl kritischer Ressourcen: Jede render-blocking Ressource (CSS und synchrones JavaScript) muss heruntergeladen und verarbeitet werden, bevor der Browser zeichnen kann. Reduziere die Anzahl kritischer Ressourcen, indem du nicht-essenzielle Skripte aufschiebst und nicht-kritische Stylesheets asynchron lädst.
• Optimiere die Ladereihenfolge der Ressourcen: Stelle sicher, dass kritisches CSS und Schriftarten zuerst laden, gefolgt von Bildern „above the fold“ und dann aufgeschobenen Skripten. Verwende das Attribut fetchpriority und Hinweise zur Ressourcenpriorisierung, um dem Browser die Wichtigkeit mitzuteilen.
• Reduziere die Tiefe des DOM-Baums: Tief verschachtelte DOM-Bäume erhöhen die Zeit für Stilberechnungen und Layout-Arbeiten. Strebe wo möglich eine maximale Tiefe von 32 Ebenen und insgesamt weniger als 1.500 DOM-Elemente an. Eine flachere DOM-Struktur verbessert sowohl die Paint-Performance als auch die INP-Präsentationsverzögerung.
• Bevorzuge Klassen und IDs gegenüber Element-Tags und Attributen: Verwende .important statt p.important. Dadurch muss der Browser nicht alle Elemente dieses Typs für den Stilabgleich durchsuchen, was die Stilneuberechnung beschleunigt.
• Vermeide tief verschachtelte Selektoren: Je tiefer du CSS-Selektoren verschachtelst, desto mehr Berechnungen muss der Browser durchführen. Strukturiere dein HTML um, um die Verschachtelung zu reduzieren, oder verwende spezifischere Klassen näher am Element. Begrenze die Selektorentiefe auf maximal 3 Ebenen.
• Minimiere Nachfahren-Selektoren: Selektoren wie .container > .content zwingen den Browser, jedes Element innerhalb des Containers zu prüfen. Verwende nach Möglichkeit eine direktere Klasse für das Inhaltselement, um den Selektorabgleich zu beschleunigen.
• Führe Selektoren mit gleichen Stilen zusammen: Wenn mehrere Elemente dieselben Stile teilen, gruppiere sie in einer einzigen Klasse oder verwende eine BEM (Block Element Modifier) Namenskonvention für eine bessere Wartbarkeit und einen kleineren CSS-Output.

Cookie-Einwilligung optimieren

Cookie-Einwilligungsbanner sind durch die DSGVO und ähnliche Vorschriften vorgeschrieben. Ohne sorgfältige Implementierung beeinträchtigen sie jedoch die Core Web Vitals erheblich. Ein schlecht geladenes Einwilligungsbanner kann den LCP verzögern, CLS verursachen und den INP erhöhen. Lies für weitere Details über die Optimierung von Drittanbieter-Widgets für Core Web Vitals.

• Ziehe eine serverseitige Cookie-Einwilligung für dynamische Seiten in Betracht: Bei dynamisch serverseitig gerenderten Seiten ist eine serverseitige Lösung oft schneller als eine separate JavaScript-basierte Lösung. Sie rendert das Einwilligungsbanner direkt im initialen HTML-Response. Das eliminiert den zusätzlichen Netzwerk-Request und den Overhead für die Skript-Auswertung.
• Lade Cookie-Einwilligungsskripte auf gecachten Seiten asynchron: Lade dein Cookie-Einwilligungsskript auf gecachten Seiten asynchron. Ziehe in Betracht, dem Skript fetchpriority="high" hinzuzufügen. Das stellt sicher, dass es früh genug lädt, um vor der Benutzerinteraktion angezeigt zu werden.
• Halte den Einwilligungstext kurz, um LCP-Interferenzen zu vermeiden: Lange Cookie-Hinweistexte können zum LCP-Element werden. Der Browser betrachtet den größten sichtbaren Textblock als potenziellen LCP-Kandidaten. Schreibe kürzere Texte oder unterteile den Text in mehrere Absätze mit kleinerer sichtbarer Fläche.
• Hoste Cookie-Benachrichtigungsskripte selbst: Cache und hoste Cookie-Benachrichtigungsskripte sowie Stylesheets wann immer möglich selbst. Das eliminiert DNS-Lookups und den Verbindungs-Overhead zu Drittanbieter-Consent-Management-Plattformen. So behältst du die volle Kontrolle über das Ladeverhalten.

Single Page Applications optimieren

Single Page Applications (SPAs) auf Basis von React, Vue, Angular oder ähnlichen Frameworks stehen vor ganz eigenen Core Web Vitals-Herausforderungen. Clientseitiges Rendering kann sowohl den FCP als auch den LCP verzögern. Die Hydration kann den INP blockieren.

• Nutze immer serverseitiges Rendering oder Prerendering: SPAs, die sich ausschließlich auf clientseitiges Rendering verlassen, zwingen den Browser, JavaScript herunterzuladen, zu parsen und auszuführen, bevor Inhalte sichtbar werden. Nutze SSR (Next.js, Nuxt, SvelteKit) oder statisches Prerendering, um initiales HTML auszuliefern, das der Browser sofort darstellen kann.
• Bevorzuge statische Prerenders gegenüber dynamischer Generierung: Statische Prerenders (erstellt zur Build-Zeit) sind viel schneller als dynamisch generierte Prerenders. Sie werden direkt von einem CDN ohne serverseitige Verarbeitung ausgeliefert. Nutze die statische Generierung für Seiten, die keine anfragespezifischen Daten benötigen.
• Lade Drittanbieterskripte nach der Hydration: Während der Hydration beansprucht das Framework bereits erhebliche Zeit auf dem main thread, um die Seite interaktiv zu machen. Das gleichzeitige Laden von Drittanbieterskripten verstärkt das Problem und verschlechtert den Input Delay. Lade alle nicht essenziellen Skripte erst nach Abschluss der Hydration.

Zu große DOM-Größe vermeiden

Ein großes DOM (mehr als 1.500 Elemente oder eine Tiefe von über 32 Ebenen) erhöht die Speichernutzung, verlangsamt Stilberechnungen und verursacht teure Layout-Reflows. Das wirkt sich direkt auf die INP-Präsentationsverzögerung und Paint-Metriken aus. Erfahre, wie du eine zu große DOM-Größe behebst.

• Reduziere überflüssige DOM-Elemente: Prüfe dein HTML auf Wrapper-Elemente, die keinen Styling- oder Strukturzweck erfüllen. Ersetze tief verschachtelte <div>-Strukturen durch semantische HTML-Elemente. Virtualisiere lange Listen mit Bibliotheken wie react-window oder virtual-scroller, um das aktive DOM klein zu halten.
• Nutze effiziente JavaScript- und CSS-Selektoren: Komplexe CSS-Selektoren und JavaScript-DOM-Abfragen (wie querySelectorAll mit unspezifischen Mustern) werden bei wachsender DOM-Größe exponentiell langsamer. Nutze spezifische Klassenselektoren und begrenze den Scope von DOM-Abfragen wann immer möglich auf Teilbäume.
• Nutze content-visibility: auto für Off-Screen-Inhalte: Die CSS-Eigenschaft content-visibility: auto weist den Browser an, das Rendering von Off-Screen-Elementen zu überspringen, bis sie in den Viewport gescrollt werden. Das kann den initialen Rendering-Aufwand für Seiten mit langen Inhaltsabschnitten drastisch reduzieren.

API-Requests optimieren

API-Requests, die das Rendering blockieren oder Inhalte verzögern, können LCP und TTFB negativ beeinflussen. Clientseitiger Datenabruf ist eine häufige Ursache für einen langsamen LCP in Single-Page-Applications.

• Minimiere die Anzahl der API-Requests: Jeder API-Request erhöht die gesamte Ladezeit der Seite. Prüfe die Funktionalität deiner Website und finde Möglichkeiten, die Anzahl der API-Requests für das Rendern des ersten Inhalts zu reduzieren. Techniken wie Data-Batching (das Kombinieren mehrerer Requests in einen) und GraphQL können Roundtrips reduzieren.
• Nutze effiziente und optimierte APIs: Das Design und die Implementierung der APIs selbst können die Performance beeinflussen. Nutze gut gestaltete APIs, die auf Geschwindigkeit und Effizienz optimiert sind. Implementiere Caching-Mechanismen auf API-Seite, um die Antwortzeiten für häufig angeforderte Daten zu reduzieren.
• Lade kritische API-Requests vor: Ähnlich wie das Vorladen kritischer Ressourcen wie Bilder kann das Vorladen essenzieller API-Requests die gefühlte Performance deutlich verbessern. Nutze <link rel="preload" as="fetch">, um den Browser anzuweisen, kritische APIs frühzeitig abzurufen. Das minimiert Verzögerungen beim Rendern der ersten Inhalte. Siehe unseren Leitfaden zur Ressourcen-Priorisierung für weitere Techniken.

Chat-Widgets optimieren

Chat-Widgets sind eine häufige Ursache für Layout-Verschiebungen. Werden sie früh geladen, können sie sogar Probleme mit dem LCP verursachen. Lies für eine Schritt-für-Schritt-Anleitung wie du ein Chat-Widget mit perfekten Core Web Vitals implementierst.

• Lade Chat-Widgets erst nach dem Hauptinhalt: Niemand in der Geschichte des Internets musste je chatten, bevor der Hauptinhalt der Seite geladen war. Verzögere die Initialisierung des Chat-Widgets, bis die Seite ihr erstes Rendern abgeschlossen hat. Nutze dafür requestIdleCallback oder einen scrollbasierten Trigger.
• Verhindere Layout-Verschiebungen durch Chat-Widgets: Verursachen Chat-Widgets Layout-Verschiebungen, blende sie mit opacity: 0 aus, bis sie vollständig auf der Seite gerendert sind. So baut sich das Widget im Hintergrund auf, ohne dass der sichtbare Inhalt springt. Nutze eine CSS-Transition, um das Widget sanft einzublenden.
• Wähle leichtgewichtige Chat-Widget-Anbieter: Schau dich um. Einige Chat-Widgets sind deutlich leichtgewichtiger und verursachen weniger Probleme mit den Core Web Vitals als andere. Vergleiche die JavaScript-Bundle-Größe, die Anzahl der Netzwerkanfragen und die Auswirkungen auf den INP verschiedener Anbieter, bevor du dich festlegst.

Service-Worker-Performance optimieren

Service-Worker können die Performance bei wiederkehrenden Besuchen erheblich verbessern, indem sie Assets und sogar vollständige Seitenantworten cachen. Das reduziert die TTFB für wiederkehrende Besucher. Ein schlecht implementierter Service-Worker kann die Navigation jedoch verlangsamen. Erfahre mehr über die Optimierung der Cache-Dauer.

• Cache kritische Assets im Service-Worker: Nutze eine Cache-First-Strategie für statische Assets wie CSS, JavaScript, Schriftarten und Bilder. Wiederkehrende Besucher laden deine Website dadurch nahezu sofort aus dem lokalen Cache. Precache die wichtigsten Ressourcen während des Install-Events des Service-Workers.
• Service-Worker-Code optimieren: Halte deinen Service-Worker schlank und effizient. Vermeide komplexe Routing-Logik, den übermäßigen Einsatz von event.waitUntil() und große Precache-Manifeste, die die Installation verlangsamen. Nutze das Stale-While-Revalidate-Pattern für Ressourcen, die sich häufig ändern, aber keine sofortige Aktualität erfordern.

Videoinhalte optimieren

Video-Elemente können zum LCP-Element werden, wenn sie der größte sichtbare Inhalt im Viewport sind. Große, nicht optimierte Videos konkurrieren zudem mit anderen kritischen Ressourcen um Bandbreite.

• Komprimiere und optimiere Videos: Nutze moderne Codecs wie H.264, VP9 oder AV1 mit passenden Qualitätseinstellungen. Reduziere die Videoauflösung auf die maximale Anzeigegröße. Ein 400px breites Video muss nicht mit 1920px codiert sein. Nutze Two-Pass-Encoding für das beste Verhältnis von Qualität zu Dateigröße.
• Nutze lazy loading für Videos: Für Videos unterhalb des sichtbaren Bereichs nutze das Attribut loading="lazy" auf <iframe>-Elementen oder verzögere das Laden mit der Intersection Observer API. Ersetze automatisch abspielende Hintergrundvideos durch Poster-Bilder. Lade das Video erst, wenn der Nutzer in die Nähe scrollt.
• Hoste Videos auf einem schnellen CDN: Videodateien sind groß. Sie profitieren stark von der Verteilung über ein CDN. Nutze ein dediziertes Video-CDN oder einen Hosting-Dienst (wie Cloudflare Stream, Mux oder Bunny.net) mit adaptivem Bitraten-Streaming, geografischer Verteilung und optimierter Auslieferung.
• Nutze Poster-Bilder für Video-Elemente: Setze immer ein poster-Attribut bei <video>-Elementen. Das Poster-Bild gibt dem Browser sofort etwas zum Darstellen, während das Video lädt. Das kann als LCP-Element dienen. Optimiere das Poster-Bild genau wie jedes andere LCP-Bild.