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
  • Server-Antwortzeiten optimieren
  • Interaktivität optimieren
  • Core Web Vitals Monitoring
  • Critical Rendering Path optimieren
  • Cookie-Consent optimieren
  • Single Page Applications optimieren
  • Exzessive DOM-Größen vermeiden
  • API-Requests optimieren
  • Chat-Widgets optimieren
  • Service Worker Performance optimieren
  • Videoinhalte optimieren

Bilder optimieren

Große Bilder im sichtbaren Viewport werden in den meisten Fällen zum Largest Contentful Paint-Element. Die Optimierung von Bildern ist eine der wirkungsvollsten Maßnahmen, die Sie für den LCP ergreifen können. Verwenden Sie diese Core Web Vitals Checklisten-Punkte, um die Bildgeschwindigkeit zu verbessern. Die vollständige Strategie finden Sie in unserem Leitfaden, wie man das LCP-Bild optimiert.

• Passen Sie die Bildgröße an die größten Bildschirmdimensionen an: Dies stellt sicher, dass niemals Bytes für das Herunterladen von Bildern verschwendet werden, die größer als ihre maximale Bildschirmgröße sind. Kombinieren Sie diese Praxis mit responsiven Bildern für kleinere Bildschirmgrößen. Die Bereitstellung von korrekt skalierten Bildern kann die Dateigröße von Bildern ohne sichtbaren Qualitätsverlust um 50 % oder mehr reduzieren.
• Verwenden Sie Lazy Loading für Bilder unterhalb der Fold: Lazy Loading verzögert das Laden von Bildern außerhalb des Viewports, bis sie in den sichtbaren Bereich gescrollt werden, was First Contentful Paint (FCP) und die allgemeine Ladezeit der Seite verbessert. Verwenden Sie niemals Lazy Loading für das LCP-Bild, da dies es erheblich verzögern wird.
• Preloaden Sie visuell wichtige Bilder wie das LCP-Element: Preloading weist den Browser an, kritische Bilder vor dem Rest des Inhalts abzurufen, wodurch LCP priorisiert wird. Verwenden Sie <link rel="preload" as="image"> kombiniert mit fetchpriority="high" für die besten Ergebnisse. Dies ist besonders wichtig, wenn das LCP-Bild über CSS referenziert oder per JavaScript geladen wird.
• Legen Sie Breite und Höhe fest: Die Definition von Bildabmessungen im Voraus verhindert Layout-Verschiebungen, die dadurch verursacht werden, dass der Browser auf das Laden von Bildern wartet. Dies verbessert CLS. Moderne Browser verwenden Breiten- und Höhenattribute, um das Seitenverhältnis zu berechnen, bevor das Bild geladen wurde, und reservieren so den korrekten Platzbedarf.
• Verwenden Sie moderne Bildformate wie WebP oder AVIF: Diese Formate bieten im Vergleich zu JPEG oder PNG kleinere Dateigrößen bei gleichbleibender Qualität, was zu schnelleren Ladezeiten führt. WebP erzielt 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 Browserkompatibilität.
• Verwenden Sie natives Lazy Loading und deaktivieren Sie 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, das von Browsern über das loading="lazy"-Attribut angeboten wird, ist im Allgemeinen effizienter, als sich für diese Aufgabe auf JavaScript zu verlassen, da kein zusätzliches Parsen oder Ausführen von Skripten erforderlich ist.
• Verwenden Sie responsive Bilder mit srcset: Dieses Attribut gibt verschiedene Bildversionen für unterschiedliche Bildschirmgrößen an und stellt sicher, dass der Browser das optimale Bild für das Gerät des Benutzers liefert und unnötig große Downloads reduziert werden. Kombinieren Sie srcset mit dem sizes-Attribut für präzise Kontrolle.
• Fügen Sie decoding="async" hinzu: Das decoding="async"-Attribut verhindert, dass der Browser andere Inhalte blockiert, während er ein Bild dekodiert. Dadurch kann die Rendering-Engine weiterhin andere Elemente malen, während die Bilddekodierung parallel abläuft.
• Entfernen Sie Bild-Metadaten: Metadaten wie EXIF-Daten, die in Bilder 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 die Metadaten-Entfernung als Teil Ihres Build-Prozesses automatisieren.
• Vermeiden Sie CSS-Hintergrundbilder für LCP-Elemente: In CSS referenzierte Hintergrundbilder werden vom Browser später entdeckt als <img>-Elemente in HTML. Wenn Sie ein Hintergrundbild als LCP-Element verwenden müssen, preloaden Sie es mit einem <link rel="preload">-Tag, um eine frühzeitige 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. Verwenden Sie diese Checkliste, um ein reibungsloses Web-Font-Erlebnis zu gewährleisten. Best Practices zum Hosting von Schriftarten finden Sie in unserem Leitfaden zum selbst hosten von Google Fonts.

• Verwenden Sie font-display: swap für schnelleren First Paint: Setzen Sie die Eigenschaft font-display in Ihren @font-face-Deklarationen auf swap. Dies stellt sicher, dass der Browser sofort eine Fallback-Schriftart anzeigt, während der Web Font im Hintergrund geladen wird. Sobald der Font bereit ist, wird er nahtlos ausgetauscht. Lesen Sie mehr darüber, wie Sie sicherstellen, dass Text während des Ladens von Webfonts sichtbar bleibt.
• Verwenden Sie font-display: optional kombiniert mit Preloading, um durch Schriftarten verursachte Layout-Verschiebungen zu eliminieren: Die Kombination von font-display: optional mit Preloading bietet ein Gleichgewicht zwischen Geschwindigkeit und potenziellen Layout-Verschiebungen. Der Wert optional blendet Text kurz aus (etwa 100ms), bevor eine Fallback-Schriftart verwendet wird. Preloading weist den Browser an, den Web Font frühzeitig abzurufen, wodurch die Zeit, die mit Fallback-Schriftarten verbracht wird, minimiert und Layout-Verschiebungen reduziert werden.
• Verwenden Sie font-face Deskriptoren, um die Fallback-Schriftart an die Abmessungen des Web Fonts anzupassen: Dies stellt einen minimalen CLS sicher, wenn der Web Font eingewechselt wird. Durch die Angabe ähnlicher Metriken unter Verwendung von size-adjust, ascent-override, descent-override und line-gap-override für die Fallback-Schriftart können Sie verhindern, dass Inhalte beim Laden der Schriftart herumspringen.
• Subsetting von Schriftarten, um nur notwendige Zeichen einzuschließen: Reduzieren Sie die Dateigröße der Schriftart, indem Sie Schriftarten so reduzieren (Subsetting), dass sie nur die für Ihren Inhalt erforderlichen Zeichen enthalten. Tools wie Font Squirrel, pyftsubset oder glyphhanger können beim Generieren von Subsets helfen. Eine Schriftart mit vollständigem lateinischen Zeichensatz kann durch ordnungsgemäßes Subsetting oft von über 100 KB auf unter 20 KB reduziert werden.
• Begrenzen Sie die Anzahl der Schriftschnitte und -stile: Vermeiden Sie das Laden übermäßiger Schriftvariationen. Beschränken Sie sich auf maximal 2 kritische Schriftarten (normalerweise vorab geladen) und 2 spät ladende Schriftarten (nach dem initialen Rendering geladen). Jeder zusätzliche Schriftschnitt erhöht die Downloadgröß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. Einen vollständigen Leitfaden finden Sie unter 14 Methoden zum Zurückstellen von JavaScript.

• Entfernen Sie unnötiges JavaScript: Identifizieren und eliminieren Sie ungenutzten JavaScript-Code, um die Menge an Code zu minimieren, die heruntergeladen und ausgeführt werden muss. Verwenden Sie den Chrome DevTools Coverage Tab, um ungenutzten Code zu finden. Das Entfernen von totem Code reduziert sowohl die Downloadzeit als auch die Verarbeitungszeit des Main Threads.
• Priorisieren Sie Skripte basierend auf ihrer Funktion und Wichtigkeit: Skripte, die große Änderungen am sichtbaren Viewport vornehmen, sollten Render-blocking sein. Wichtige Skripte sollten zurückgestellt oder asynchron geladen werden. Nice-to-have Skripte sollten laden, wenn der Browser im Leerlauf (Idle) ist. Siehe unseren Leitfaden zur Ressourcenpriorisierung 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 anfängliche Ladezeit. Moderne Bundler wie webpack, Rollup und esbuild unterstützen automatisches Code Splitting basierend auf dynamischen Imports.
• Minifizieren und rekompilieren Sie JavaScript-Dateien: Minifizieren und rekompilieren Sie Ihre JavaScript-Dateien immer mit einem Minifizierungs-Tool wie SWC, Terser oder esbuild. Minifizierung reduziert die JavaScript-Dateigröße in der Regel um 30 bis 50 %.
• Begrenzen Sie Skripte von Drittanbietern: Skripte von Drittanbietern können erheblichen Performance-Overhead verursachen. Evaluieren Sie deren Notwendigkeit und prüfen Sie wenn möglich Alternativen. 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.
• Laden Sie Drittanbieter-Skripte asynchron: Wegen der unvorhersehbaren Natur von Drittanbieter-Skripten, erlauben Sie niemals, dass das Rendering durch einen Dritten blockiert wird. Verwenden Sie das async oder defer Attribut auf allen Drittanbieter-Skript-Tags.
• Überwachen Sie die Performance von Drittanbieter-Skripten: Verwenden Sie die Long Animation Frames (LoAF) API oder CoreDash, um die realen Auswirkungen von Drittanbieter-Skripten auf INP und LCP zu verfolgen. Setzen Sie Performance-Budgets für Drittanbieter-JavaScript 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. Befolgen Sie die 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. Tipps zum Bereinigen ungenutzter Styles finden Sie unter Wie man ungenutztes CSS entfernt.

• Minifizieren Sie CSS-Dateien: 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-Präprozessors können dies automatisieren.
• Entfernen Sie ungenutztes CSS: Identifizieren und eliminieren Sie CSS-Code, der auf Ihren Webseiten nicht verwendet wird. Dies reduziert die Datenmenge, die der Browser herunterladen und parsen muss, was die Performance verbessert. Tools wie PurgeCSS oder der Chrome DevTools Coverage Tab helfen, ungenutztes CSS zu identifizieren.
• Inlinen Sie kritisches CSS: Stellen Sie Styles, die für das Rendering des anfänglichen Seiteninhalts unerlässlich sind, direkt im HTML bereit, um die Paint-Metriken zu verbessern. Erwägen Sie, kritisches CSS nur neuen Besuchern bereitzustellen und für wiederkehrende Besucher gecachte externe Stylesheets zu verwenden. Diese Technik kann den FCP reduzieren, indem sie den Round Trip eliminiert, der zum Abrufen eines externen Stylesheets erforderlich ist.
• Verteilen Sie CSS-Dateigrößen gleichmäßig: Während 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 (jeweils 10 bis 15 KB) aufzuteilen, um das Laden zu optimieren und dem Browser zu ermöglichen, Styles schrittweise zu verarbeiten.
• Laden Sie Offscreen-Styles asynchron: Für Styles, die für Elemente außerhalb des initialen Viewports gelten, erwägen Sie die Verwendung von asynchronem Laden über das Muster media="print" onload="this.media='all'". Dies ermöglicht es dem Browser, diese Styles parallel mit anderen Ressourcen abzurufen, ohne das anfängliche Rendering der Seite zu blockieren.

Resource Hints optimieren

Resource Hints helfen, Downloads für kritische Ressourcen zu priorisieren. Vorab geladene Ressourcen (Preloaded) werden normalerweise für den Download in die Warteschlange gestellt und stehen dem Browser viel früher zur Verfügung, als dies ohne Preloading der Fall gewesen wäre. Eine effektive Nutzung von Resource Hints kann das LCP resource load delay erheblich reduzieren. Für eine fortgeschrittene Implementierung lesen Sie über 103 Early Hints.

• Entfernen Sie nicht-kritische Resource Hints: Entfernen Sie Preload-Hints für Ressourcen, die für das anfängliche Laden der Seite nicht unerlässlich sind. Dies verhindert unnötige Downloads oder Netzwerkverbindungen, die um diese frühen, bandbreitenlimitierten Ressourcen konkurrieren. Jeder unnötige Preload verbraucht Bandbreite, die für 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.
• Erwägen Sie DNS-Prefetch als Preconnect-Alternative: Ähnlich wie Preconnect gibt DNS Prefetch dem Browser Hinweise auf mögliche Verbindungen. Allerdings priorisiert Preconnect den Aufbau der vollständigen Verbindung, während DNS Prefetch dem Browser lediglich mitteilt, den Domainnamen im Voraus aufzulösen. Verwenden Sie <link rel="dns-prefetch">, wenn der Overhead für eine vollständige Verbindung durch Preconnect nicht gerechtfertigt ist.
• Preloaden Sie das LCP-Element: LCP misst, wie lange es dauert, bis der Hauptinhalt geladen ist. Das Preloading des LCP-Elements weist den Browser an, den Download dieser kritischen Ressource zu priorisieren, wodurch sich die Zeit beschleunigt, die Benutzer benötigen, um den Hauptinhalt zu sehen. Dies ist besonders wichtig für Bilder, die in CSS referenziert oder per JavaScript geladen werden.
• Preloaden Sie kritische Schriftarten: Das Preloading kritischer Schriftarten stellt sicher, dass der Browser sie frühzeitig abruft, wodurch Verzögerungen bei der Anzeige von Text verhindert und Cumulative Layout Shifts, die durch das Austauschen von Schriftarten verursacht werden, verbessert werden. Verwenden Sie <link rel="preload" as="font" type="font/woff2" crossorigin> für Ihre wichtigsten Schriftarten.
• Bevorzugen Sie 103 Early Hints für Resource Hints: Der HTTP-Statuscode 103 Early Hints 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 in den <head> der Seite ein. Eine frühere Bereitstellung von Hints bedeutet eine schnellere Entdeckung von Ressourcen.
• Preloaden Sie Schriftarten, bevor CSS-Dateien sie entdecken: In CSS referenzierte Schriftarten werden erst entdeckt, nachdem die CSS-Datei heruntergeladen und geparst wurde. Indem Sie Schriftarten direkt im HTML-<head> preloaden, eliminieren Sie die Abhängigkeit vom CSS-Parsing und ermöglichen es den Schriftarten, parallel zu laden, wodurch sowohl FCP als auch das Risiko von Layout-Verschiebungen reduziert werden.

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-Fonts oft tausende ungenutzte Glyphen enthalten. Die Optimierung von Icons wirkt sich sowohl auf den LCP (reduziertes HTML/CSS-Gewicht) als auch auf den CLS (richtige Dimensionsreservierung) aus.

• Vermeiden Sie Inline-SVG-Icons im HTML: Das Inlining großer SVG-Icons kann die Größe Ihres HTML-Codes erhöhen und das Laden der Seite verlangsamen. Erwägen Sie alternative Methoden wie die Bereitstellung als separate Dateien oder die (vorsichtige) Verwendung von Icon-Fonts, um die HTML-Größe zu minimieren und das Browser-Caching der Icons zu ermöglichen. Ein externes SVG-Spritesheet ist oft die beste Balance zwischen Performance und Flexibilität.
• Vermeiden Sie große Icon-Fonts: Verwenden Sie niemals große Icon-Sets wie Font Awesome in ihrer Gesamtheit. Verwenden Sie Subsetting, um optimierte Icon-Fonts oder individuelle SVGs zu erstellen, um die Gesamtgröße der Webseite zu reduzieren und die Ladegeschwindigkeit zu verbessern. Ein vollständiges Font Awesome Set kann 100 KB überschreiten, während ein Subset mit 20 Icons unter 5 KB groß sein kann.
• Reservieren Sie Breite und Höhe für Icons: Ähnlich wie bei Bildern hilft die Angabe von Breite und Höhe für Icons dem Browser, Platz zu reservieren und verhindert Layout-Verschiebungen, während sie geladen werden. Verwenden Sie die Attribute width und height für SVG-Elemente oder legen Sie explizite Dimensionen im CSS fest.
• Depriorisieren Sie nicht-kritische Icon-Sets: Wenn Icons für das initiale Rendering Ihrer Seite nicht entscheidend sind, sollten Sie in Betracht ziehen, sie mit geringerer Priorität zu laden. Dies stellt sicher, dass wesentliche Inhalte zuerst geladen werden und minimiert die Auswirkungen auf Core Web Vitals Metriken. Nutzen Sie Lazy Loading oder laden Sie Icon-Stylesheets asynchron nach dem initialen Paint.

Server-Antwortzeiten optimieren

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

• Nutzen Sie einen schnellen und zuverlässigen Hosting-Provider: Ein schneller Hosting-Provider mit starker Infrastruktur kann die Server-Antwortzeiten und die allgemeine Website-Performance erheblich verbessern. Benchmarken Sie Hosting-Provider mit realen TTFB-Messungen, nicht mit synthetischen Marketingbehauptungen.
• Optimieren Sie serverseitigen Code und Datenbankabfragen: Protokollieren Sie häufig die Code-Ausführungs- und Datenbankabfragezeit, um Engpässe zu finden und die Gesamtgeschwindigkeit zu verbessern. Verwenden Sie Tools für Query-Profiling und Application Performance Monitoring (APM), um langsame Endpunkte zu identifizieren.
• Implementieren Sie Caching-Strategien: Nutzen Sie Browser-Caching und serverseitiges Caching, um häufig abgerufene Daten zu speichern, wodurch die Notwendigkeit des wiederholten Datenabrufs reduziert und Ladezeiten verbessert werden. Full-Page-Caching kann die TTFB von Sekunden auf unter 100ms reduzieren. Erfahren Sie mehr über Cache Duration Optimization.
• Client-side oder Edge-Rendering für Personalisierung: Erwägen Sie Client-side oder Edge-Rendering für kleine Personalisierungen wie Warenkorbanzahl, Login-Status oder kleinere Menüänderungen, um die Funktionalität des Full-Page-Caches beizubehalten. Dies vermeidet ein Cache-Busting der gesamten Seite für kleine dynamische Elemente.
• Optimieren Sie Serverkonfigurationen: Überprüfen und tunen Sie Ihre Webserver-Einstellungen für Performance. Dies umfasst Connection Keep-Alive-Einstellungen, Worker-Prozess-Anzahlen, Speicherzuweisung und Timeout-Werte. Falsch konfigurierte Server können Ressourcen verschwenden und Antwortzeiten erhöhen.
• Verwenden Sie ein Content Delivery Network (CDN): Ein CDN verteilt den statischen Inhalt Ihrer Website über mehrere Edge Nodes (Server). Dies reduziert die physische Entfernung, die Benutzer zurücklegen müssen, um auf Ihre Inhalte zuzugreifen, was zu schnelleren Ladezeiten für globale Zielgruppen führt. Darüber hinaus sind CDNs meist besser konfiguriert als Ihr eigener Server. Siehe unseren Leitfaden zur Konfiguration von Cloudflare für einen praktischen Setup-Walkthrough.
• Reduzieren Sie serverseitige Verarbeitung: Minimieren Sie die Menge an Arbeit, die Ihr Server pro Request verrichtet. Berechnen Sie teure Operationen vor, nutzen Sie effiziente Algorithmen und verschieben Sie nicht-essentielle Verarbeitungen in Hintergrund-Jobs (Background Jobs). Analysieren Sie den Request-Lifecycle Ihrer Anwendung, um unnötige Verarbeitungsschritte zu finden und zu eliminieren.
• Verwenden Sie 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 allgemeinen Seitenladezeiten und potenziell alle drei Core Web Vitals Metriken (LCP, INP, CLS) verbessern. Erfahren Sie mehr über Connection Duration Optimization.
• Richten Sie Server-Timing-Header ein: Diese Header liefern detaillierte Informationen darüber, wie lange verschiedene Teile Ihrer Seite für die Verarbeitung auf dem Server benötigen. Mit diesen Daten können Sie Engpässe und Bereiche für Verbesserungen aufspüren, wobei der Fokus speziell auf der Verbesserung des Largest Contentful Paint (LCP) liegt. Server-Timing-Header sind im Chrome DevTools Network Panel sichtbar und können von RUM-Tools wie CoreDash erfasst werden.
• Protokollieren Sie langsame Datenbankabfragen und optimieren Sie sie regelmäßig: Aktivieren Sie das Slow Query Logging in Ihrer Datenbank (MySQL, PostgreSQL, MongoDB) und überprüfen Sie die Logs wöchentlich. Indexoptimierung, Umstrukturierung von Abfragen und das Hinzufügen von Caching-Layern für häufige Abfragen können die TTFB drastisch reduzieren.
• Verwenden Sie GZIP- oder Brotli-Komprimierung: GZIP, oder das neuere Brotli, bietet eine On-the-fly-Komprimierung von textbasierten Ressourcen (HTML, CSS, JavaScript) vor der Übertragung, was zu etwa 70 % kleineren Dateigrößen führt. Brotli erreicht in der Regel eine 15 bis 20 % bessere Komprimierung als GZIP. Kleinere Dateigrößen führen zu schnelleren Ladezeiten.

Interaktivität optimieren

Interaction to Next Paint (INP) misst, wie schnell Ihre Website auf Benutzerinteraktionen reagiert. Eine schlechte Interaktivität wird oft durch lang laufende JavaScript-Aufgaben verursacht, die den Main Thread blockieren. Für eine vollständige Aufschlüsselung der drei INP-Phasen lesen Sie unsere Leitfäden zu Input Delay, Processing Time und Presentation Delay.

• Implementieren Sie ein Idle-until-urgent-Muster für teure Skripte: Dieser Ansatz beinhaltet die Priorisierung kritischer Aufgaben und die Zurückstellung nicht-essentieller JavaScript-Ausführung, bis der Haupt-Browser-Thread im Leerlauf (Idle) ist. Dies stellt sicher, dass kritische Aufgaben wie Rendering und Benutzerinteraktionen nicht durch lang laufende Skripte blockiert werden. Verwenden Sie requestIdleCallback, um nicht dringende Arbeit einzuplanen. Erfahren Sie mehr über Optimizing Processing Time.
• Brechen Sie lange Aufgaben auf, durch Yielding an den Main Thread: Komplexe JavaScript-Aufgaben können den Main Thread blockieren und die Reaktionsfähigkeit verzögern. Die Aufteilung dieser Aufgaben in kleinere Chunks und die Rückgabe der Kontrolle (Yielding) an den Main Thread zwischen den Chunks ermöglicht es dem Browser, Benutzerinteraktionen zu verarbeiten und eine reibungslose User Experience aufrechtzuerhalten. Verwenden Sie scheduler.yield() (wo unterstützt) oder setTimeout(0), um lange Aufgaben aufzubrechen. Siehe unseren Leitfaden zur Verbesserung des INP durch den Verzicht auf JavaScript-Scrolling.
• Geben Sie sofortiges Feedback nach einer Eingabe: Nutzer erwarten nach der Interaktion mit Ihrer Website eine sofortige Reaktion. Bieten Sie visuelle Hinweise oder bestätigen Sie Benutzereingaben umgehend, auch während im Hintergrund noch langlaufende Aufgaben verarbeitet werden. Verwenden Sie CSS-Transitions und die Pseudoklasse :active für sofortiges visuelles Feedback. Dies hilft, ein Gefühl von Interaktivität aufrechtzuerhalten und verhindert, dass Benutzer das Gefühl haben, die Website sei eingefroren.
• Verwenden Sie passive Event-Listener für Scrollen und Touch: 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, sodass er sofort mit dem Scrollen beginnen kann, ohne auf JavaScript zu warten. Dies ist besonders auf mobilen Geräten wirkungsvoll und verbessert direkt den INP für Scroll-bezogene Interaktionen.

Core Web Vitals Monitoring

Die kontinuierliche Überwachung Ihrer Core Web Vitals ist unerlässlich, um Regressionen frühzeitig zu erkennen und zu validieren, dass Optimierungen die erwarteten Auswirkungen haben. Verwenden Sie eine Kombination aus Lab-Tools, Felddaten und Real User Monitoring für ein vollständiges Bild.

• Überprüfen Sie Lighthouse regelmäßig: Lighthouse ist ein kostenloses Open-Source-Auditing-Tool von Google, das Ihnen hilft, Performance-Probleme auf Ihren Webseiten zu identifizieren. Auch wenn Lighthouse die Core Web Vitals nicht direkt im Kontext eines echten Benutzers misst, ist es ein großartiges Werkzeug, um Ihre Website regelmäßig unter regulierten und standardisierten Bedingungen zu testen und zu vergleichen. Führen Sie Lighthouse in CI/CD-Pipelines aus, um Regressionen vor dem Deployment zu erkennen.
• Überprüfen Sie regelmäßig die historischen CrUX-Daten: CrUX (Chrome User Experience Report) ist ein öffentlicher Datensatz von Google, der reale Performance-Daten liefert. CrUX ist die Datenquelle, die von Google verwendet wird, um zu bestimmen, ob Sie die Core Web Vitals bestehen oder nicht. Nutzen Sie die historischen Daten, um Regressionen schnell zu erkennen. Sie können auf CrUX-Daten über PageSpeed Insights, das CrUX Dashboard oder die CrUX API zugreifen.
• Richten Sie RUM-Tracking ein: RUM (Real User Monitoring) beinhaltet das Tracking echter Benutzererfahrungen auf Ihrer Website. RUM-Tools sammeln Daten darüber, wie lange es tatsächlich dauert, bis Seiten für Ihre Besucher an verschiedenen Standorten und auf verschiedenen Geräten geladen sind. Dies liefert wertvolle Einblicke in die reale Performance 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.
• Setzen Sie Performance-Budgets: Performance-Budgets legen spezifische Performance-Ziele (zum Beispiel LCP unter 2,5 Sekunden, INP unter 200ms, CLS unter 0,1) für verschiedene Metriken fest. Diese dienen als Benchmarks zur Steuerung Ihrer Optimierungsbemühungen. Eine regelmäßige Überprüfung Ihrer Performance gegen diese Budgets hilft Ihnen, Bereiche zu identifizieren, die sofortige Aufmerksamkeit erfordern, und Optimierungen zu priorisieren.
• Verwenden Sie Segmentierung: Nutzen Sie Segmentierung, um Ihre wertvollsten Besuchertypen und verschiedene Seitentypen zu verfolgen. Größere Traffic-Mengen könnten sonst Performance-Probleme verdecken, die speziell diese wichtigen Gruppen betreffen. Segmentieren Sie nach Gerätetyp, Verbindungsgeschwindigkeit, Geografie und Seiten-Template, um verborgene Probleme aufzudecken.

Critical Rendering Path optimieren

Der Critical Rendering Path ist die Abfolge von Schritten, die der Browser durchführt, 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 eine exzessive DOM-Größe vermeidet.

• Minimieren Sie die Anzahl kritischer Ressourcen: Jede Render-blocking Ressource (CSS und synchrones JavaScript) muss heruntergeladen und verarbeitet werden, bevor der Browser malen (paint) kann. Reduzieren Sie die Anzahl kritischer Ressourcen, indem Sie nicht-essentielle Skripte zurückstellen und nicht-kritische Stylesheets asynchron laden.
• Optimieren Sie die Reihenfolge des Ressourcen-Ladens: Stellen Sie sicher, dass kritisches CSS und Schriftarten zuerst geladen werden, gefolgt von Above-the-fold-Bildern und dann zurückgestellten Skripten. Verwenden Sie das fetchpriority Attribut und Ressourcen-Priorisierungs-Hints, um dem Browser Wichtigkeit zu kommunizieren.
• Reduzieren Sie die Tiefe des DOM-Baums: Tief verschachtelte DOM-Bäume erhöhen die Zeit für die Stilberechnung (Style Calculation) und die Layout-Arbeit. Streben Sie wo möglich eine maximale Tiefe von 32 Ebenen und weniger als 1.500 DOM-Elemente insgesamt an. Eine flachere DOM-Struktur verbessert sowohl die Paint-Performance als auch das INP presentation delay.
• Bevorzugen Sie Klassen und IDs gegenüber Element-Tags und Attributen: Verwenden Sie statt p.important besser .important. Dies reduziert die Notwendigkeit für den Browser, durch alle Elemente dieses Typs nach einem passenden Style zu suchen, was zu einer schnelleren Neuberechnung von Styles führt.
• Vermeiden Sie es, Selektoren tief zu verschachteln: Je tiefer Sie CSS-Selektoren verschachteln, desto mehr Berechnungen muss der Browser durchführen. Versuchen Sie, Ihr HTML umzustrukturieren, um Verschachtelungen zu reduzieren, oder verwenden Sie spezifischere Klassen näher am Element. Begrenzen Sie die Selektortiefe auf maximal 3 Ebenen.
• Minimieren Sie Descendant-Selektoren: Selektoren wie .container > .content zwingen den Browser, jedes Element innerhalb des Containers zu überprüfen. Wenn möglich, verwenden Sie eine direktere Klasse für das Content-Element für ein schnelleres Selektor-Matching.
• Fassen Sie Selektoren mit gleichen Styles zusammen: Wenn mehrere Elemente die gleichen Styles teilen, gruppieren Sie sie in einer einzigen Klasse oder verwenden Sie eine BEM (Block Element Modifier) Namenskonvention für bessere Wartbarkeit und eine kleinere CSS-Ausgabe.

Cookie-Consent optimieren

Cookie-Consent-Banner sind durch die DSGVO und ähnliche Verordnungen vorgeschrieben, können aber die Core Web Vitals erheblich 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. Weitere Details lesen Sie unter Optimierung von Drittanbieter-Widgets für Core Web Vitals.

• Erwägen Sie serverseitigen Cookie-Consent für dynamische Seiten: Für dynamisch Server-Side 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 Overhead durch zusätzliche Netzwerkanfragen und Skriptauswertung.
• Laden Sie Cookie-Consent-Skripte auf gecachten Seiten asynchron: Laden Sie Ihr Cookie-Consent-Skript für gecachte Seiten asynchron und erwägen Sie, fetchpriority="high" zum Skript hinzuzufügen, um sicherzustellen, dass es früh genug lädt, um vor der Benutzerinteraktion angezeigt zu werden.
• Halten Sie Consent-Texte kurz, um LCP-Interferenz 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 kleinerer sichtbarer Fläche aufzuteilen.
• Hosten Sie Cookie-Benachrichtigungsskripte selbst: Cachen und hosten Sie Cookie-Benachrichtigungsskripte und Stylesheets wann immer möglich selbst. Dies eliminiert DNS Lookups und Verbindungs-Overhead zu Drittanbieter-Consent-Management-Plattformen und gibt Ihnen die 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.

• Verwenden Sie immer Server-Side Rendering oder Prerendering: 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 bereitzustellen, das der Browser sofort malen (paint) kann.
• Bevorzugen Sie statische Prerenders gegenüber dynamischer Generierung: Statische Prerenders (die zur Build-Zeit generiert werden) sind viel schneller als dynamisch generierte Prerenders, da sie direkt von einem CDN ohne jegliche serverseitige Verarbeitung ausgeliefert werden können. Verwenden Sie statische Generierung für Seiten, die keine Pro-Request-Daten benötigen.
• Laden Sie Drittanbieter-Skripte nach der Hydration: Während der Hydration verbraucht das Framework bereits erhebliche Zeit des Main Threads, um die Seite interaktiv zu machen. Das gleichzeitige Laden von Drittanbieter-Skripten verschärft das Problem und verschlechtert das Input Delay. Stellen Sie alle nicht-essentiellen Skripte zurück, bis der Hydration-Prozess abgeschlossen ist.

Exzessive DOM-Größen vermeiden

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

• Reduzieren Sie unnötige DOM-Elemente: Überprüfen Sie Ihr HTML auf Wrapper-Elemente, die keinem Styling- oder strukturellen Zweck dienen. Ersetzen Sie tief verschachtelte <div>-Strukturen durch semantische HTML-Elemente. Erwägen Sie die Virtualisierung langer Listen mit Bibliotheken wie react-window oder virtual-scroller, um das aktive DOM klein zu halten.
• Verwenden Sie effiziente JavaScript- und CSS-Selektoren: Komplexe CSS-Selektoren und JavaScript-DOM-Abfragen (wie querySelectorAll mit breiten Mustern) werden mit zunehmender DOM-Größe exponentiell langsamer. Verwenden Sie spezifische Klassen-Selektoren und begrenzen Sie den Geltungsbereich von DOM-Abfragen auf Subtrees, wann immer dies möglich ist.
• Verwenden Sie content-visibility: auto für Off-Screen-Inhalte: Die CSS-Eigenschaft content-visibility: auto teilt dem Browser mit, das Rendering von Off-Screen-Elementen zu überspringen, bis sie in den sichtbaren Bereich gescrollt werden. Dies kann die anfängliche Rendering-Arbeit für Seiten mit langen Inhaltsbereichen drastisch reduzieren.

API-Requests optimieren

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

• Minimieren Sie die Anzahl von API-Requests: Jeder API-Request verlängert die gesamte Ladezeit der Seite. Evaluieren Sie die Funktionalität Ihrer Website und identifizieren Sie Möglichkeiten, die Anzahl der API-Requests zu reduzieren, die für das Rendering des anfänglichen Inhalts erforderlich sind. Techniken wie Data Batching (Zusammenfassen mehrerer Requests in einem) und GraphQL können Round Trips reduzieren.
• Verwenden Sie effiziente und optimierte APIs: Das Design und die Implementierung der APIs selbst können die Performance beeinflussen. Stellen Sie sicher, dass Sie gut gestaltete APIs verwenden, die für Geschwindigkeit und Effizienz optimiert sind. Implementieren Sie Caching-Mechanismen auf der API-Seite, um die Antwortzeiten für häufig angefragte Daten zu reduzieren.
• Preloaden Sie kritische API-Requests: Ähnlich wie beim Preloading kritischer Ressourcen wie Bilder kann das Preloading wesentlicher API-Requests die wahrgenommene Performance erheblich verbessern. Verwenden Sie <link rel="preload" as="fetch">, um den Browser anzuweisen, kritische APIs frühzeitig abzurufen, wodurch Verzögerungen minimiert werden, wenn sie für das Rendering des anfänglichen Inhalts benötigt werden. Siehe unseren Leitfaden zur Ressourcenpriorisierung für weitere Techniken.

Chat-Widgets optimieren

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

• Laden Sie Chat-Widgets, nachdem der Hauptinhalt geladen wurde: Niemand in der Geschichte des Internets musste jemals chatten, bevor der Hauptinhalt der Seite geladen war. Stellen Sie die Initialisierung des Chat-Widgets zurück, bis die Seite ihren initialen Render beendet hat, indem Sie requestIdleCallback oder einen Scroll-basierten Auslöser verwenden.
• Verhindern Sie Layout-Verschiebungen durch Chat-Widgets: Wenn Chat-Widgets eine Layout-Verschiebung verursachen, ist es in der Regel eine gute Idee, sie mit opacity: 0 zu verbergen, bis sie vollständig auf der Seite gerendert wurden. Dies ermöglicht es dem Widget, sich im Hintergrund auszurichten, ohne dass sichtbare Inhalte springen. Verwenden Sie eine CSS-Transition, um das Widget sanft einzublenden.
• Wählen Sie leichtgewichtige Chat-Widget-Anbieter: Sehen Sie sich auf dem Markt um. Einige Chat-Widgets sind viel leichtgewichtiger und verursachen weniger Core Web Vitals Probleme als andere. Vergleichen Sie die JavaScript-Bundle-Größe, die Anzahl der Netzwerkanfragen und die INP-Auswirkungen verschiedener Anbieter, bevor Sie sich festlegen.

Service Worker Performance optimieren

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

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

Videoinhalte optimieren

Videoelemente können zum LCP-Element werden, wenn sie der größte sichtbare Inhalt im Viewport sind. Große, unoptimierte Videos konkurrieren auch mit anderen kritischen Ressourcen um Bandbreite.

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