Die ultimative Core Web Vitals Checkliste (2026)

Table of Contents!

• Die ultimative Core Web Vitals Checkliste
• Core Web Vitals Optimierungs-Checkliste
  • Bilder optimieren
  • Web Fonts optimieren
  • Skripte optimieren
  • Styles optimieren
  • Resource Hints optimieren
  • Icons optimieren
  • Serverantwortzeiten optimieren
  • Interaktivität optimieren
  • Core Web Vitals Monitoring
  • Kritischen Rendering-Pfad optimieren
  • Cookie Consent optimieren
  • Single Page Applications optimieren
  • Exzessive DOM-Größe vermeiden
  • API-Requests optimieren
  • Chat-Widgets optimieren
  • Service Worker Performance optimieren
  • Video-Inhalt optimieren

Bilder optimieren

Große Bilder im sichtbaren Viewport werden meistens zum Largest Contentful Paint Element. Die Optimierung von Bildern ist eine der wirkungsvollsten Maßnahmen, die Sie für den LCP ergreifen können. Nutzen Sie diese Punkte der Core Web Vitals Checkliste, um die Bildgeschwindigkeit zu verbessern. Für einen tiefen Einblick lesen Sie unseren Leitfaden darüber, wie man das LCP-Bild optimiert.

• Bilder auf die größten Bildschirmabmessungen skalieren: Dies stellt sicher, dass keine Bytes für das Herunterladen von Bildern verschwendet werden, die größer sind als ihre maximale Bildschirmgröße. Kombinieren Sie diese Praxis mit responsive Images für kleinere Bildschirmgrößen. Das Bereitstellen korrekt dimensionierter Bilder kann die Dateigröße um 50% oder mehr reduzieren, ohne sichtbaren Qualitätsverlust.
• Lazy Loading für Bilder "below-the-fold" verwenden: Lazy Loading verzögert das Laden von Bildern außerhalb des Viewports, bis diese in den sichtbaren Bereich gescrollt werden, was den First Contentful Paint (FCP) und die allgemeine Ladegeschwindigkeit verbessert. Verwenden Sie niemals Lazy Loading für das LCP-Bild, da dies dieses signifikant verzögern würde.
• Visuell wichtige Bilder wie das LCP-Element vorladen (Preload): Preloading weist den Browser an, kritische Bilder vor dem restlichen Inhalt abzurufen und priorisiert so den LCP. Verwenden Sie <link rel="preload" as="image"> kombiniert mit fetchpriority="high" für die besten Ergebnisse. Dies ist besonders wichtig, wenn das LCP-Bild im CSS referenziert oder über JavaScript geladen wird.
• Breite und Höhe festlegen: Das Definieren von Bildabmessungen im Voraus verhindert Layout-Verschiebungen (Layout Shifts), die entstehen, wenn der Browser auf das Laden der Bilder wartet. Dies verbessert den CLS. Moderne Browser nutzen Breite- und Höhe-Attribute, um das Seitenverhältnis zu berechnen, bevor das Bild geladen ist, und reservieren so den korrekten Platz.
• Moderne Bildformate wie WebP oder AVIF verwenden: Diese Formate bieten im Vergleich zu JPEG oder PNG kleinere Dateigrößen bei ähnlicher Qualität, was zu schnelleren Ladezeiten führt. WebP erreicht typischerweise 25-34% kleinere Dateien als JPEG, während AVIF die Dateigröße um bis zu 50% reduzieren kann. Verwenden Sie das <picture> Element mit Format-Fallbacks für maximale Browser-Kompatibilität.
• Natives Lazy Loading verwenden und JavaScript-basiertes Lazy Loading deaktivieren: Lazy Loading verzögert das Laden von Bildern außerhalb des Viewports, bis sie in den sichtbaren Bereich gescrollt werden. Natives Lazy Loading, das von Browsern über das loading="lazy" Attribut angeboten wird, ist im Allgemeinen effizienter als die Verwendung von JavaScript für diese Aufgabe, da es kein zusätzliches Parsen oder Ausführen von Skripten erfordert.
• Responsive Bilder mit srcset verwenden: Dieses Attribut spezifiziert verschiedene Bildversionen für unterschiedliche Bildschirmgrößen und stellt sicher, dass der Browser das optimale Bild für das Gerät des Nutzers liefert, was unnötige große Downloads reduziert. Kombinieren Sie srcset mit dem sizes Attribut für präzise Kontrolle.
• decoding="async" hinzufügen: Das decoding="async" Attribut verhindert, dass der Browser anderen Inhalt blockiert, während er ein Bild dekodiert. Dies ermöglicht der Rendering-Engine, andere Elemente zu zeichnen (paint), während die Bilddekodierung parallel erfolgt.
• Bild-Metadaten entfernen: Metadaten wie EXIF-Daten, die in Bildern eingebettet sind, können unnötige Bytes hinzufügen. Das Entfernen dieser Informationen kann die Dateigröße reduzieren, ohne die Bildqualität zu beeinträchtigen. Tools wie ImageOptim, Squoosh oder Sharp können das Entfernen von Metadaten als Teil Ihres Build-Prozesses automatisieren.
• CSS-Hintergrundbilder für LCP-Elemente vermeiden: Hintergrundbilder, die in CSS referenziert werden, werden vom Browser später entdeckt als <img> Elemente im HTML. Wenn Sie ein Hintergrundbild als LCP-Element verwenden müssen, laden Sie es vor (preload) mit einem <link rel="preload"> Tag, um eine frühe Entdeckung sicherzustellen. Erfahren Sie mehr über LCP Resource Load Delay.

Web Fonts optimieren

Web Fonts können den First Contentful Paint verzögern, Layout-Verschiebungen verursachen und um frühe Bandbreitenressourcen konkurrieren. Nutzen Sie diese Checkliste, um eine reibungslose Web Font Erfahrung sicherzustellen. Für Best Practices zum Hosting von Schriftarten, siehe unseren Leitfaden zum Self-Hosting von Google Fonts.

• font-display: swap für schnelleren First Paint verwenden: Setzen Sie die font-display Eigenschaft auf swap in Ihren @font-face Deklarationen. Dies stellt sicher, dass der Browser sofort eine Fallback-Schriftart anzeigt, während die Web Font im Hintergrund geladen wird. Sobald die Schriftart bereit ist, wird sie nahtlos ausgetauscht. Lesen Sie mehr darüber, wie man sicherstellt, dass Text während des Ladens der Webfont sichtbar bleibt.
• font-display: optional kombiniert mit Preloading verwenden, um Layout-Verschiebungen durch Schriftarten zu eliminieren: Die Kombination von font-display: optional mit Preloading bietet ein Gleichgewicht zwischen Geschwindigkeit und potenziellen Layout-Verschiebungen. Der Wert optional verbirgt Text kurzzeitig (ca. 100ms), bevor eine Fallback-Schriftart verwendet wird. Preloading weist den Browser an, die Web Font frühzeitig abzurufen, was die Zeit minimiert, die mit Fallback-Schriftarten verbracht wird, und Layout-Verschiebungen reduziert.
• Font-Face Deskriptoren verwenden, um die Fallback-Schriftart an die Abmessungen der Web Font anzupassen: Dies stellt minimalen CLS sicher, wenn die Web Font eingewechselt wird. Durch die Angabe ähnlicher Metriken mittels size-adjust, ascent-override, descent-override und line-gap-override für die Fallback-Schriftart können Sie verhindern, dass Inhalt herumspringt, wenn die Schriftart lädt.
• Schriftarten subsetten, um nur notwendige Zeichen einzuschließen: Reduzieren Sie die Dateigröße von Schriftarten, indem Sie Subsets erstellen, die nur die für Ihren Inhalt benötigten Zeichen enthalten. Tools wie Font Squirrel, pyftsubset oder glyphhanger können helfen, Subsets zu generieren. Eine Schriftart mit vollem lateinischen Zeichensatz kann oft von über 100KB auf unter 20KB mit korrektem Subsetting reduziert werden.
• Anzahl der Schriftstärken und -stile begrenzen: Vermeiden Sie das Laden übermäßiger Schriftvariationen. Beschränken Sie sich auf maximal 2 kritische Schriftarten (normalerweise preloaded) und 2 spät ladende Schriftarten (geladen nach dem initialen Rendering). Jede zusätzliche Schriftstärke fügt 15 bis 50KB an Downloadgröße hinzu.

Skripte optimieren

Skripte können Probleme mit Interaction to Next Paint 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. Für einen vollständigen Leitfaden, siehe 14 Methoden, um JavaScript aufzuschieben (defer).

• Unnötiges JavaScript entfernen: Identifizieren und eliminieren Sie ungenutzten JavaScript-Code, um die Menge an Code zu minimieren, der heruntergeladen und ausgeführt werden muss. Verwenden Sie den Coverage-Tab in den Chrome DevTools, um ungenutzten Code zu finden. Das Entfernen von totem Code reduziert sowohl die Downloadzeit als auch die Verarbeitung im Main Thread.
• Skripte basierend auf Funktion und Wichtigkeit priorisieren: Skripte, die große Änderungen am sichtbaren Viewport vornehmen, sollten Render-Blocking sein. Wichtige Skripte sollten aufgeschoben (deferred) oder asynchron (async) geladen werden. "Nice-to-have" Skripte sollten bei Browser-Leerlauf (idle) laden. Siehe unseren Leitfaden zur Ressourcen-Priorisierung für eine detaillierte Strategie.
• Code Splitting und Lazy Loading: Brechen Sie große JavaScript-Bundles in kleinere Chunks auf und laden Sie diese nur bei Bedarf. Dies reduziert die initiale Ladezeit. Moderne Bundler wie webpack, Rollup und esbuild unterstützen automatisches Code Splitting basierend auf dynamischen Imports.
• JavaScript-Dateien minifizieren und neu kompilieren: Minifizieren und kompilieren Sie Ihre JavaScript-Dateien immer neu mit einem Minifizierungs-Tool wie SWC, Terser oder esbuild. Minifizierung reduziert die JavaScript-Dateigröße typischerweise um 30 bis 50%.
• Drittanbieter-Skripte begrenzen: Skripte von Drittanbietern können erheblichen Performance-Overhead verursachen. Bewerten Sie deren Notwendigkeit und erkunden Sie Alternativen, wenn möglich. Jedes Drittanbieter-Skript fügt DNS-Lookups, Verbindungs-Overhead und Verarbeitungszeit im Main Thread hinzu. Überprüfen Sie Drittanbieter-Skripte regelmäßig mit dem Chrome DevTools Network Panel.
• Drittanbieter-Skripte asynchron laden: Aufgrund der unvorhersehbaren Natur von Drittanbieter-Skripten sollten Sie niemals zulassen, dass das Rendering durch einen Drittanbieter blockiert wird. Verwenden Sie das async oder defer Attribut bei allen Skript-Tags von Drittanbietern.
• Performance von Drittanbieter-Skripten überwachen: Nutzen Sie die Long Animation Frames (LoAF) API oder CoreDash, um den realen Einfluss von Drittanbieter-Skripten auf INP und LCP zu verfolgen. Legen Sie Performance-Budgets für JavaScript von Drittanbietern fest und überprüfen Sie diese regelmäßig.

Styles optimieren

Styles sind standardmäßig Render-Blocking. Die Optimierung von Styles führt zu optimierten Paint-Metriken. Folgen Sie der Checkliste, um die Style-Performance Ihrer Webseite zu verbessern. Render-Blocking CSS wirkt sich direkt sowohl auf First Contentful Paint als auch auf LCP Element Render Delay aus. Für Tipps zum Aufräumen ungenutzter Styles, siehe wie man ungenutztes CSS entfernt.

• CSS-Dateien minifizieren: Entfernen Sie unnötige Zeichen wie Leerzeichen, Kommentare und Formatierungen aus CSS-Dateien. Minifizierte Dateien sind kleiner, was zu schnelleren Ladezeiten führt. Tools wie cssnano, PostCSS oder die eingebaute Komprimierung Ihres CSS-Preprocessors können dies automatisieren.
• Ungenutztes CSS entfernen: Identifizieren und eliminieren Sie CSS-Code, der auf Ihren Webseiten nicht verwendet wird. Dies reduziert die Datenmenge, die der Browser herunterladen und parsen muss, und verbessert die Performance. Tools wie PurgeCSS oder der Chrome DevTools Coverage Tab helfen dabei, ungenutztes CSS zu identifizieren.
• Kritisches CSS inlinen: Liefern Sie Styles, die für das Rendern des initialen Seiteninhalts essentiell sind, direkt im HTML aus, um die Paint-Metriken zu verbessern. Ziehen Sie in Betracht, kritisches CSS nur an neue Besucher auszuliefern und für wiederkehrende Besucher gecachte externe Stylesheets zu verwenden. Diese Technik kann den FCP reduzieren, indem der Round-Trip zum Abrufen eines externen Stylesheets eliminiert wird.
• CSS-Dateigrößen gleichmäßig verteilen: Auch wenn es effizient erscheinen mag, alles CSS in einer Datei zu kombinieren, können übermäßig große Dateien die Downloadzeiten verlangsamen. Erwägen Sie, CSS in kleinere Dateien mit einer gleichmäßigeren Größenverteilung (10 bis 15KB pro Datei) aufzuteilen, um das Laden zu optimieren und dem Browser zu ermöglichen, Styles inkrementell zu verarbeiten.
• Offscreen-Styles asynchron laden: Für Styles, die auf Elemente außerhalb des initialen Viewports angewendet werden, sollten Sie asynchrones Laden über das Muster media="print" onload="this.media='all'" in Betracht ziehen. Dies ermöglicht dem Browser, diese Styles parallel mit anderen Ressourcen abzurufen, ohne das initiale Rendering der Seite zu blockieren.

Resource Hints optimieren

Resource Hints helfen dabei, Downloads für kritische Ressourcen zu priorisieren. Vorgeladene Ressourcen werden normalerweise in die Warteschlange für den Download eingereiht und stehen dem Browser viel früher zur Verfügung, als dies ohne Preloading der Fall wäre. Der effektive Einsatz von Resource Hints kann das LCP Resource Load Delay signifikant reduzieren. Für fortgeschrittene Implementierung, lesen Sie über 103 Early Hints.

• Nicht-kritische Resource Hints entfernen: Entfernen Sie Preload-Hints für Ressourcen, die für den initialen Seitenaufbau nicht essentiell sind. Dies verhindert unnötige Downloads oder Netzwerkverbindungen, die um jene frühen, bandbreitenlimitierten Ressourcen konkurrieren. Jeder unnötige Preload verbraucht Bandbreite, die für wirklich kritische Ressourcen genutzt werden könnte.
• Preconnect zu kritischen Domains: Stellen Sie frühzeitig Verbindungen zu wichtigen Domains (wie Content Delivery Networks oder Schriftarten-Anbietern) her. Dies beschleunigt den Download kritischer Ressourcen von diesen Domains, indem DNS, TCP und TLS Handshakes im Voraus abgeschlossen werden. Verwenden Sie <link rel="preconnect" href="https://example.com"> für kritische Drittanbieter-Origins.
• DNS Prefetch als Preconnect-Alternative in Betracht ziehen: Ähnlich wie Preconnect gibt DNS Prefetch dem Browser Hinweise auf potenzielle Verbindungen. Preconnect priorisiert jedoch den Aufbau der vollständigen Verbindung, während DNS Prefetch dem Browser nur mitteilt, den Domainnamen im Voraus aufzulösen. Verwenden Sie <link rel="dns-prefetch">, wenn der volle Verbindungs-Overhead von Preconnect nicht gerechtfertigt ist.
• Das LCP-Element vorladen (Preload): LCP misst, wie lange es dauert, bis der Hauptinhalt geladen ist. Das LCP-Element vorzuladen weist den Browser an, das Herunterladen dieser kritischen Ressource zu priorisieren, was die Zeit beschleunigt, bis Nutzer den Hauptinhalt sehen. Dies ist besonders wichtig für Bilder, die im CSS referenziert oder über JavaScript geladen werden.
• Kritische Schriftarten vorladen: Das Vorladen kritischer Schriftarten stellt sicher, dass der Browser diese frühzeitig abruft, was Verzögerungen bei der Textanzeige verhindert und Cumulative Layout Shifts durch Schriftart-Austausch verbessert. Verwenden Sie <link rel="preload" as="font" type="font/woff2" crossorigin> für Ihre wichtigsten Schriftarten.
• 103 Early Hints für Resource Hints bevorzugen: Der 103 Early Hints HTTP-Statuscode ermöglicht es dem Server, Resource Hints zu senden, bevor die vollständige Antwort bereit ist. Wenn Ihr Server 103 nicht unterstützt, verwenden Sie stattdessen Link Response Header. Wenn Header nicht verfügbar sind, fügen Sie als Fallback <link> Elemente zum <head> der Seite hinzu. Eine frühere Auslieferung von Hints bedeutet eine schnellere Ressourcen-Entdeckung.
• Schriftarten vorladen, bevor CSS-Dateien sie entdecken: Im CSS referenzierte Schriftarten werden erst entdeckt, nachdem die CSS-Datei heruntergeladen und geparst wurde. Indem Sie Schriftarten direkt im HTML <head> vorladen, eliminieren Sie die Abhängigkeit vom CSS-Parsen und ermöglichen das parallele Laden von Schriftarten, was sowohl den FCP als auch das Risiko von Layout-Verschiebungen reduziert.

Icons optimieren

Icons können Ihrer Seite erhebliches Gewicht hinzufügen, wenn sie nicht optimiert sind. Große inline SVG-Icons blähen Ihr HTML auf, während Icon-Schriftarten oft tausende ungenutzter Glyphen enthalten. Die Optimierung von Icons wirkt sich sowohl auf den LCP (reduziertes HTML/CSS-Gewicht) als auch auf den CLS (korrekte Platzreservierung) aus.

• Inline SVG-Icons im HTML vermeiden: Das Inlining großer SVG-Icons kann die Größe Ihres HTML-Codes erhöhen und das Laden der Seite verlangsamen. Ziehen Sie alternative Methoden in Betracht, wie das Bereitstellen als separate Dateien oder die Verwendung von Icon-Fonts (mit Vorsicht), um die HTML-Größe zu minimieren und Browser-Caching der Icons zu ermöglichen. Ein externes SVG-Sprite-Sheet ist oft die beste Balance zwischen Performance und Flexibilität.
• Große Icon-Fonts vermeiden: Verwenden Sie niemals große Icon-Sets wie Font Awesome in ihrer Gesamtheit. Nutzen Sie Subsetting, um optimierte Icon-Fonts zu erstellen, oder einzelne SVGs, um die Gesamtgröße der Webseite zu reduzieren und die Ladegeschwindigkeit zu verbessern. Ein vollständiges Font Awesome Set kann 100KB überschreiten, während ein Subset mit 20 Icons unter 5KB liegen kann.
• Breite und Höhe für Icons reservieren: Ähnlich wie bei Bildern hilft die Angabe von Breite und Höhe für Icons dem Browser, Platz zu reservieren und verhindert Layout-Verschiebungen beim Laden. Verwenden Sie die width und height Attribute auf SVG-Elementen oder setzen Sie explizite Dimensionen im CSS.
• Nicht-kritische Icon-Sets depriorisieren: Wenn Icons für das initiale Rendering Ihrer Seite nicht kritisch sind, ziehen Sie in Betracht, sie mit niedrigerer Priorität zu laden. Dies stellt sicher, dass essentieller Inhalt zuerst lädt und minimiert den Einfluss auf Core Web Vitals Metriken. Nutzen Sie Lazy Loading oder laden Sie Icon-Stylesheets asynchron nach dem initialen Paint.

Serverantwortzeiten optimieren

Serverantwortzeiten, gemessen als Time to First Byte (TTFB), stehen in direkter Beziehung zu allen Paint-Metriken. Eine langsame Serverantwort verzögert alles, was folgt. Für detaillierte Optimierungsstrategien, erkunden Sie unsere Leitfäden zur Diagnose von TTFB-Problemen und Konfiguration von Cloudflare für Performance.

• Einen schnellen und zuverlässigen Hosting-Anbieter verwenden: Ein schneller Hosting-Anbieter mit starker Infrastruktur kann Serverantwortzeiten und die allgemeine Website-Performance signifikant verbessern. Vergleichen Sie Hosting-Anbieter anhand echter TTFB-Messungen, nicht anhand synthetischer Marketing-Behauptungen.
• Serverseitigen Code und Datenbankabfragen optimieren: Loggen Sie regelmäßig Code-Ausführungs- und Datenbankabfragezeiten, um Engpässe zu finden und die allgemeine Geschwindigkeit zu verbessern. Nutzen Sie Query-Profiling und Application Performance Monitoring (APM) Tools, um langsame Endpoints zu identifizieren.
• Caching-Strategien implementieren: Nutzen Sie Browser-Caching und serverseitiges Caching, um häufig abgerufene Daten zu speichern, was die Notwendigkeit wiederholter Datenabrufe reduziert und Ladezeiten verbessert. Full-Page-Caching kann die TTFB von Sekunden auf unter 100ms reduzieren. Erfahren Sie mehr über Cache-Dauer-Optimierung.
• Client-Side oder Edge Rendering für Personalisierung: Ziehen Sie Client-Side oder Edge Rendering für kleine Personalisierungen wie Warenkorb-Anzahl, Login-Status oder kleinere Menüänderungen in Betracht, um die Full-Page-Cache-Funktionalität zu erhalten. Dies vermeidet das "Cache Busting" der gesamten Seite für kleine dynamische Elemente.
• Serverkonfigurationen optimieren: Überprüfen und tunen Sie Ihre Webserver-Einstellungen auf Performance. Dazu gehören Connection Keep-Alive Einstellungen, Anzahl der Worker-Prozesse, Speicherzuweisung und Timeout-Werte. Falsch konfigurierte Server können Ressourcen verschwenden und Antwortzeiten erhöhen.
• Ein Content Delivery Network (CDN) verwenden: Ein CDN verteilt den statischen Inhalt Ihrer Website über mehrere Edge-Knoten (Server). Dies reduziert die physische Distanz, die Nutzer überbrücken müssen, um auf Ihren Inhalt zuzugreifen, was zu schnelleren Ladezeiten für ein globales Publikum führt. Zudem sind CDNs meist besser konfiguriert als Ihr eigener Server. Siehe unseren Leitfaden zur Konfiguration von Cloudflare für eine praktische Einrichtungsanleitung.
• Serverseitige Verarbeitung reduzieren: Minimieren Sie die Menge an Arbeit, die Ihr Server pro Anfrage leistet. Berechnen Sie aufwendige Operationen vor, nutzen Sie effiziente Algorithmen und verschieben Sie nicht-essentielle Verarbeitung in Background-Jobs. Analysieren Sie den Request-Lifecycle Ihrer Anwendung, um unnötige Verarbeitungsschritte zu finden und zu eliminieren.
• HTTP/3 verwenden: HTTP/3 ist die neueste Version des Hypertext Transfer Protocol. HTTP/3 ist schneller und effizienter als HTTP/2 und signifikant schneller als HTTP/1.1. Ein Upgrade auf HTTP/3 kann die allgemeinen Ladezeiten und potenziell alle drei Core Web Vitals Metriken (LCP, INP, CLS) verbessern. Erfahren Sie mehr über Connection Duration Optimierung.
• Server-Timing Header einrichten: Diese Header liefern detaillierte Informationen darüber, wie lange verschiedene Teile Ihrer Seite auf dem Server für die Verarbeitung benötigen. Mit diesen Daten können Sie Engpässe und Bereiche für Verbesserungen identifizieren, mit speziellem Fokus auf die 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.
• Langsame Datenbankabfragen loggen und regelmäßig optimieren: Aktivieren Sie Slow Query Logging in Ihrer Datenbank (MySQL, PostgreSQL, MongoDB) und überprüfen Sie die Logs wöchentlich. Index-Optimierung, Umstrukturierung von Abfragen und das Hinzufügen von Caching-Layern für häufige Abfragen können die TTFB drastisch reduzieren.
• GZIP oder Brotli Kompression verwenden: GZIP, oder das neuere Brotli, bietet eine On-the-fly-Kompression textbasierter Ressourcen (HTML, CSS, JavaScript) vor der Übertragung, was zu etwa 70% kleineren Dateigrößen führt. Brotli erreicht typischerweise 15 bis 20% bessere Kompression als GZIP. Kleinere Dateigrößen bedeuten schnellere Ladezeiten.

Interaktivität optimieren

Interaction to Next Paint (INP) misst, wie schnell Ihre Seite auf Nutzerinteraktionen reagiert. Schlechte Interaktivität wird oft durch lang laufende JavaScript-Tasks verursacht, die den Main Thread blockieren. Für eine komplette Aufschlüsselung der drei INP-Phasen, siehe unsere Leitfäden zu Input Delay, Processing Time und Presentation Delay.

• Ein Idle-Until-Urgent Muster für teure Skripte implementieren: Dieser Ansatz beinhaltet die Priorisierung kritischer Aufgaben und das Aufschieben nicht-essentieller JavaScript-Ausführung, bis der Main Browser Thread im Leerlauf (idle) ist. Dies stellt sicher, dass kritische Aufgaben wie Rendering und Nutzerinteraktionen nicht durch lang laufende Skripte blockiert werden. Verwenden Sie requestIdleCallback, um nicht dringende Arbeit zu planen. Erfahren Sie mehr über die Optimierung der Processing Time.
• Lange Tasks durch Yielding an den Main Thread aufbrechen: Komplexe JavaScript-Aufgaben können den Main Thread blockieren und die Reaktionsfähigkeit verzögern. Das Aufteilen dieser Aufgaben in kleinere Chunks und die Rückgabe der Kontrolle an den Main Thread zwischen den Chunks ermöglicht es dem Browser, Nutzerinteraktionen zu verarbeiten und eine reibungslose Nutzererfahrung aufrechtzuerhalten. Verwenden Sie scheduler.yield() (wo unterstützt) oder setTimeout(0), um lange Tasks aufzubrechen. Siehe unseren Leitfaden zur Verbesserung des INP durch Verzicht auf JavaScript-Scrolling.
• Sofortiges Feedback nach Eingabe geben: Nutzer erwarten sofortige Reaktionsfähigkeit nach der Interaktion mit Ihrer Website. Geben Sie visuelle Hinweise oder bestätigen Sie Nutzereingaben umgehend, auch während lang laufende Aufgaben im Hintergrund verarbeitet werden. Verwenden Sie CSS-Transitions und die :active Pseudo-Klasse für sofortiges visuelles Feedback. Dies hilft, ein Gefühl der Interaktivität zu bewahren und verhindert, dass Nutzer das Gefühl haben, die Website sei eingefroren.
• Passive Event Listeners für Scrollen und Touch verwenden: Fügen Sie { passive: true } zu Scroll- und Touch-Event-Listenern hinzu. Passive Listener teilen dem Browser mit, dass der Handler niemals preventDefault() aufrufen wird, was ihm erlaubt, sofort mit dem Scrollen zu beginnen, ohne auf JavaScript zu warten. Dies ist besonders auf Mobilgeräten wirkungsvoll und verbessert direkt den INP für Scroll-nahe Interaktionen.

Core Web Vitals Monitoring

Das kontinuierliche Monitoring Ihrer Core Web Vitals ist essentiell, um Regressionen frühzeitig zu erkennen und zu validieren, dass Optimierungen den erwarteten Effekt haben. Nutzen Sie eine Kombination aus Lab-Tools, Felddaten und Real User Monitoring für ein vollständiges Bild.

• Lighthouse regelmäßig prüfen: Lighthouse ist ein kostenloses Open-Source-Auditing-Tool von Google, das Ihnen hilft, Performance-Probleme auf Ihren Webseiten zu identifizieren. Während Lighthouse die Core Web Vitals nicht direkt in einem echten Nutzerkontext misst, ist es ein großartiges Tool, um Ihre Website periodisch unter regulierten und standardisierten Bedingungen zu testen und zu vergleichen. Führen Sie Lighthouse in CI/CD-Pipelines aus, um Regressionen vor dem Deployment abzufangen.
• CrUX historische Daten regelmäßig prüfen: CrUX (Chrome User Experience Report) ist ein öffentlicher Datensatz von Google, der Performance-Daten aus der realen Welt liefert. CrUX ist die Datenquelle, die Google verwendet, um zu bestimmen, ob Sie die Core Web Vitals bestehen oder nicht. Nutzen Sie die historischen Daten, um Regressionen schnell zu entdecken. Sie können auf CrUX-Daten über PageSpeed Insights, das CrUX Dashboard oder die CrUX API zugreifen.
• RUM Tracking einrichten: RUM (Real User Monitoring) beinhaltet das Tracking echter Nutzererfahrungen auf Ihrer Website. RUM-Tools sammeln Daten darüber, wie lange es tatsächlich dauert, bis Seiten für Ihre Besucher an verschiedenen Orten und auf verschiedenen Geräten laden. Dies liefert wertvolle Einblicke in die Performance in der realen Welt und ergänzt die simulierten Daten von Lighthouse und CrUX. Wir empfehlen CoreDash als Ihr RUM-Tracking-Tool für detaillierte Core Web Vitals Attributionsdaten.
• Performance-Budgets festlegen: Performance-Budgets setzen spezifische Performance-Ziele (zum Beispiel LCP unter 2,5 Sekunden, INP unter 200ms, CLS unter 0,1) für verschiedene Metriken. Diese fungieren als Maßstäbe, um Ihre Optimierungsbemühungen zu leiten. Das regelmäßige Überprüfen Ihrer Performance gegen diese Budgets hilft Ihnen, Bereiche zu identifizieren, die sofortige Aufmerksamkeit erfordern, und Optimierungen zu priorisieren.
• Segmentierung nutzen: Nutzen Sie Segmentierung, um Ihre wertvollsten Besuchergruppen und verschiedene Seitentypen zu tracken. Größere Mengen an Traffic könnten sonst Performance-Probleme maskieren, die spezifisch diese wichtigen Gruppen betreffen. Segmentieren Sie 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 unternimmt, um HTML, CSS und JavaScript in sichtbare Pixel umzuwandeln. Die Optimierung dieses Pfades verbessert direkt den First Contentful Paint und das LCP Element Render Delay. Siehe auch wie man exzessive DOM-Größe vermeidet.

• Anzahl kritischer Ressourcen minimieren: Jede Render-Blocking Ressource (CSS und synchrones JavaScript) muss heruntergeladen und verarbeitet werden, bevor der Browser "painten" kann. Reduzieren Sie die Anzahl kritischer Ressourcen, indem Sie nicht-essentielle Skripte aufschieben (defer) und nicht-kritische Stylesheets asynchron laden.
• Reihenfolge des Ressourcen-Ladens optimieren: Stellen Sie sicher, dass kritisches CSS und Schriftarten zuerst laden, gefolgt von "Above-the-Fold" Bildern, dann aufgeschobenen (deferred) Skripten. Verwenden Sie das fetchpriority Attribut und Resource Prioritization Hints, um dem Browser Wichtigkeit zu kommunizieren.
• Tiefe des DOM-Baums reduzieren: Tief verschachtelte DOM-Bäume erhöhen die Zeit für Style-Berechnungen und Layout-Arbeit. Zielen Sie auf eine maximale Tiefe von 32 Ebenen und weniger als 1.500 gesamte DOM-Elemente ab, wo möglich. Eine flachere DOM-Struktur verbessert sowohl die Paint-Performance als auch das INP Presentation Delay.
• Klassen und IDs gegenüber Element-Tags und Attributen bevorzugen: Anstatt p.important, verwenden Sie .important. Dies reduziert die Notwendigkeit für den Browser, alle Elemente dieses Typs nach Style-Übereinstimmungen zu durchsuchen, was zu schnelleren Style-Neuberechnungen führt.
• Tiefes Verschachteln von Selektoren vermeiden: Je tiefer Sie CSS-Selektoren verschachteln, desto mehr Berechnungen muss der Browser durchführen. Versuchen Sie, Ihr HTML umzustrukturieren, um Verschachtelung zu reduzieren oder verwenden Sie spezifischere Klassen näher am Element. Begrenzen Sie die Selektor-Tiefe auf maximal 3 Ebenen.
• Nachfahren-Selektoren minimieren: Selektoren wie .container > .content zwingen den Browser, jedes Element innerhalb des Containers zu prüfen. Wenn möglich, verwenden Sie eine direktere Klasse am Inhaltselement für schnelleres Selektor-Matching.
• Selektoren mit gleichen Styles konsolidieren: Wenn mehrere Elemente die gleichen Styles teilen, gruppieren Sie diese in einer einzigen Klasse oder verwenden Sie eine BEM (Block Element Modifier) Namenskonvention für bessere Wartbarkeit und kleineren CSS-Output.

Cookie Consent optimieren

Cookie-Consent-Banner sind durch DSGVO und ähnliche Vorschriften erforderlich, können aber die Core Web Vitals signifikant beeinträchtigen, wenn sie nicht sorgfältig implementiert werden. Ein schlecht geladenes Consent-Banner kann den LCP verzögern, CLS verursachen und den INP erhöhen. Für mehr Details, lesen Sie über die Optimierung von Drittanbieter-Widgets für Core Web Vitals.

• Serverseitigen Cookie-Consent für dynamische Seiten in Betracht ziehen: Für dynamisch serverseitig gerenderte Seiten ist die Implementierung einer serverseitigen Lösung, die das Consent-Banner in der initialen HTML-Antwort rendert, oft schneller als das Laden einer separaten JavaScript-basierten Lösung. Dies eliminiert den extra Netzwerk-Request und Script-Evaluierungs-Overhead.
• Cookie-Consent-Skripte auf gecachten Seiten asynchron laden: Laden Sie Ihr Cookie-Consent-Skript für gecachte Seiten asynchron und ziehen Sie in Betracht, fetchpriority="high" zum Skript hinzuzufügen, um sicherzustellen, dass es früh genug lädt, um vor der Nutzerinteraktion angezeigt zu werden.
• Consent-Text kurz halten, um LCP-Interferenzen zu vermeiden: Lange Cookie-Hinweistexte können das LCP-Element übernehmen, da der Browser den größten sichtbaren Textblock als potenziellen LCP-Kandidaten betrachtet. Erwägen Sie, kürzere Texte zu schreiben oder Texte in mehrere Absätze mit kleinerem sichtbaren Bereich aufzuteilen.
• Cookie-Benachrichtigungs-Skripte selbst hosten: Cachen und hosten Sie Cookie-Benachrichtigungs-Skripte und Stylesheets wann immer möglich selbst. Dies eliminiert DNS-Lookups und Verbindungs-Overhead zu Consent-Management-Plattformen von Drittanbietern und gibt Ihnen volle Kontrolle über das Ladeverhalten.

Single Page Applications optimieren

Single Page Applications (SPAs), die mit React, Vue, Angular oder ähnlichen Frameworks erstellt wurden, stehen vor einzigartigen Core Web Vitals Herausforderungen. Client-Side Rendering kann sowohl FCP als auch LCP verzögern, während Hydration den INP blockieren kann.

• Immer Server-Side Rendering oder Prerendering verwenden: SPAs, die sich ausschließlich auf Client-Side Rendering verlassen, zwingen den Browser dazu, JavaScript herunterzuladen, zu parsen und auszuführen, bevor irgendein Inhalt sichtbar ist. Verwenden Sie SSR (Next.js, Nuxt, SvelteKit) oder statisches Prerendering, um initiales HTML auszuliefern, das der Browser sofort painten kann.
• Statische Prerenders gegenüber dynamischer Generierung bevorzugen: Statische Prerenders (zur Build-Zeit generiert) sind viel schneller als dynamisch generierte Prerenders, da sie direkt von einem CDN ohne serverseitige Verarbeitung ausgeliefert werden können. Verwenden Sie statische Generierung für Seiten, die keine Pro-Request-Daten benötigen.
• Drittanbieter-Skripte nach der Hydration laden: Während der Hydration verbraucht das Framework bereits signifikante Zeit im Main Thread, um die Seite interaktiv zu machen. Das gleichzeitige Laden von Drittanbieter-Skripten verschärft das Problem und verschlechtert das Input Delay. Schieben Sie alle nicht-essentiellen Skripte auf, bis der Hydration-Prozess abgeschlossen ist.

Exzessive DOM-Größe vermeiden

Ein großes DOM (mehr als 1.500 Elemente oder eine Tiefe von mehr als 32 Ebenen) erhöht die Speichernutzung, verlangsamt Style-Berechnungen und verursacht kostspielige Layout-Reflows. Dies wirkt sich direkt sowohl auf das INP Presentation Delay als auch auf Paint-Metriken aus. Siehe wie man exzessive DOM-Größe behebt.

• Unnötige DOM-Elemente reduzieren: Auditieren Sie Ihr HTML auf Wrapper-Elemente, die keinem Styling- oder Strukturzweck dienen. Ersetzen Sie tief verschachtelte <div> Strukturen durch semantische HTML-Elemente. Ziehen Sie die Virtualisierung langer Listen mit Bibliotheken wie react-window oder virtual-scroller in Betracht, um das aktive DOM klein zu halten.
• Effiziente JavaScript- und CSS-Selektoren verwenden: Komplexe CSS-Selektoren und JavaScript DOM-Queries (wie querySelectorAll mit breiten Mustern) werden exponentiell langsamer, je größer das DOM wird. Verwenden Sie spezifische Klassen-Selektoren und begrenzen Sie den Scope von DOM-Queries auf Subtrees, wann immer möglich.
• content-visibility: auto für Off-Screen-Inhalt verwenden: Die CSS-Eigenschaft content-visibility: auto teilt dem Browser mit, das Rendern von Off-Screen-Elementen zu überspringen, bis sie in den sichtbaren Bereich gescrollt werden. Dies kann die initiale Rendering-Arbeit für Seiten mit langen Inhaltsabschnitten drastisch reduzieren.

API-Requests optimieren

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

• Anzahl der API-Requests minimieren: Jeder API-Request trägt zur gesamten Ladezeit der Seite bei. Evaluieren Sie die Funktionalität Ihrer Website und identifizieren Sie Möglichkeiten, die Anzahl der für das Rendern des initialen Inhalts benötigten API-Requests zu reduzieren. Techniken wie Data Batching (Kombinieren mehrerer Requests in einen) und GraphQL können Round-Trips reduzieren.
• Effiziente und optimierte APIs verwenden: Das Design und die Implementierung der APIs selbst können die Performance beeinflussen. Stellen Sie sicher, dass Sie gut designte APIs verwenden, die auf Geschwindigkeit und Effizienz optimiert sind. Implementieren Sie Caching-Mechanismen auf der API-Seite, um Antwortzeiten für häufig angefragte Daten zu reduzieren.
• Kritische API-Requests vorladen (Preload): Ähnlich wie das Vorladen kritischer Ressourcen wie Bilder kann das Vorladen essentieller API-Requests die gefühlte Performance signifikant verbessern. Verwenden Sie <link rel="preload" as="fetch">, um den Browser anzuweisen, kritische APIs frühzeitig abzurufen, und so Verzögerungen zu minimieren, wenn sie für das Rendern des initialen Inhalts benötigt werden. Siehe unseren Leitfaden zur Ressourcen-Priorisierung für weitere Techniken.

Chat-Widgets optimieren

Chat-Widgets sind eine häufige Ursache für Layout-Verschiebungen und können sogar Probleme mit dem LCP verursachen, wenn sie früh geladen werden. Für einen schrittweisen Ansatz, lesen Sie wie man ein Chat-Widget mit perfekten Core Web Vitals implementiert.

• Chat-Widgets laden, nachdem der Hauptinhalt geladen ist: Niemand in der Geschichte des Internets musste jemals chatten, bevor der Hauptinhalt der Seite geladen war. Schieben Sie die Initialisierung des Chat-Widgets auf, bis die Seite ihren initialen Render abgeschlossen hat, unter Verwendung von requestIdleCallback oder einem Scroll-basierten Trigger.
• Layout-Verschiebungen durch Chat-Widgets verhindern: Wenn Chat-Widgets eine Layout-Verschiebung verursachen, ist es meist eine gute Idee, sie mit opacity: 0 zu verbergen, bis sie vollständig auf der Seite gerendert sind. Dies erlaubt dem Widget, sich im Hintergrund aufzubauen, ohne dass sichtbarer Inhalt springt. Verwenden Sie eine CSS-Transition, um das Widget sanft einzublenden.
• Leichtgewichtige Chat-Widget-Anbieter wählen: Vergleichen Sie Angebote. Einige Chat-Widgets sind viel leichtgewichtiger und verursachen weniger Core Web Vitals Probleme als andere. Vergleichen Sie die JavaScript-Bundle-Größe, Anzahl der Netzwerk-Requests und den INP-Einfluss verschiedener Anbieter, bevor Sie sich festlegen.

Service Worker Performance optimieren

Service Worker können die Performance bei wiederkehrenden Besuchen signifikant verbessern, indem sie Assets und sogar ganze Seitenantworten cachen, was die TTFB für wiederkehrende Besucher reduziert. Ein schlecht implementierter Service Worker kann die Navigation jedoch tatsächlich verlangsamen. Erfahren Sie mehr über Cache-Dauer-Optimierung.

• Kritische Assets im Service Worker cachen: Verwenden Sie eine Cache-First-Strategie für statische Assets wie CSS, JavaScript, Schriftarten und Bilder. Dies ermöglicht wiederkehrenden Besuchern, Ihre Seite fast sofort aus dem lokalen Cache zu laden. Cachen Sie die wichtigsten Ressourcen während des Service Worker Install-Events vor (Precache).
• Service Worker Code optimieren: Halten Sie Ihren Service Worker schlank und effizient. Vermeiden Sie komplexe Routing-Logik, übermäßigen Gebrauch von event.waitUntil() und große Precache-Manifeste, die die Installation verlangsamen. Verwenden Sie das Stale-While-Revalidate Muster für Ressourcen, die sich häufig ändern, aber keine sofortige Frische erfordern.

Video-Inhalt 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 außerdem um Bandbreite mit anderen kritischen Ressourcen.

• Videos komprimieren und optimieren: Verwenden Sie moderne Codecs wie H.264, VP9 oder AV1 mit angemessenen Qualitätseinstellungen. Reduzieren Sie die Videoauflösung, um sie an die maximale Anzeigegröße anzupassen. Ein Video, das 400px breit erscheint, muss nicht in 1920px kodiert sein. Verwenden Sie Two-Pass Encoding für das beste Verhältnis von Qualität zu Dateigröße.
• Lazy Loading für Videos verwenden: Für Videos "below the fold" verwenden Sie das loading="lazy" Attribut auf <iframe> Elementen oder verzögern das Laden des Videos mit der Intersection Observer API. Ersetzen Sie automatisch abspielende Hintergrundvideos durch Poster-Bilder und laden Sie das Video erst, wenn der Nutzer in die Nähe scrollt.
• Videos auf einem schnellen CDN hosten: Videodateien sind groß und profitieren stark von CDN-Verteilung. Nutzen Sie ein dediziertes Video-CDN oder einen Hosting-Service (wie Cloudflare Stream, Mux oder Bunny.net), der adaptives Bitrate-Streaming, geografische Verteilung und optimierte Auslieferung bietet.
• Poster-Bilder für Video-Elemente verwenden: Setzen Sie immer ein poster Attribut auf <video> Elemente. Das Poster-Bild gibt dem Browser etwas, das er sofort "painten" kann, während das Video lädt, was als LCP-Element dienen kann. Optimieren Sie das Poster-Bild genau wie jedes andere LCP-Bild.