Optimiere die Ladezeit der LCP-Ressource

Dieser Leitfaden ist Teil des Bereichs Largest Contentful Paint (LCP) in unserem Core Web Vitals Resource Center. Die Resource Load Duration ist die dritte von vier aufeinanderfolgenden LCP-Phasen. Sie misst die Zeit, die es dauert, die LCP-Ressource über das Netzwerk herunterzuladen. Obwohl das Resource Load Delay oft einen größeren Teil der LCP-Zeit ausmacht, bleibt die Optimierung der Download-Dauer unerlässlich, um einen guten LCP-Wert zu erreichen.

Optimiere die LCP Resource Load Duration

Largest Contentful Paint (LCP) ist eine der drei Core Web Vitals Leistungsmetriken. Sie messen deine Online-Nutzererfahrung. Der LCP erfasst die Zeit, bis das größte Inhaltselement (ein Bild, Video oder Textblock) im Viewport sichtbar wird. Die Resource Load Duration ist ein Teil des LCP. Sie gibt an, wie viel Zeit für das Herunterladen der Netzwerkressource des LCP-Elements vergeht.

Was ist die Resource Load Duration beim LCP?

Die Resource Load Duration, oft auch Load Duration genannt, ist die Zeit, die der Browser benötigt, um die Netzwerkressource (z. B. ein Bild) herunterzuladen, die später zum LCP-Element wird. Bei Bildern und Videos reicht diese Dauer vom Start bis zum Ende des Downloads. Bei textbasierten LCP-Elementen beträgt die Ladedauer normalerweise null. Googles LCP-Optimierungsleitfaden unterteilt den LCP in vier aufeinanderfolgende Teile. Die Resource Load Duration ist dabei die Zeit, die für das eigentliche Herunterladen der Ressourcen-Bytes aufgewendet wird.

Die Resource Load Duration wird vom Beginn bis zum Ende des Downloads der LCP-Ressource durch den Browser gemessen. Vier Hauptfaktoren bestimmen diese Dauer:

• Dateigröße: Größere Dateien benötigen längere Download-Zeiten.
• Netzwerkgeschwindigkeit: Langsamere Verbindungen verlängern naturgemäß die Ladedauer.
• Server-Reaktionszeit: Verzögerungen bei der Server-Antwort verlangsamen den Ressourcenabruf.
• Gleichzeitige Downloads: Gleichzeitig heruntergeladene Ressourcen konkurrieren um Bandbreite. Das kann Ladezeiten erhöhen.

So ermittelst du die Resource Load Duration

Es gibt zwei effektive Wege, die Resource Load Duration zu identifizieren und zu messen:

Netzwerk-Inspektion in den Chrome DevTools: Nutze die Tastenkombination Strg + Umschalt + I, um die Chrome-Entwicklertools zu öffnen. Wähle den Tab „Network“ und lade die Seite neu. Suche das LCP-Element in den Netzwerkanfragen (wenn du das LCP-Element ermitteln möchtest, probiere den Core Web Vitals Visualizer). Der Netzwerk-Inspektor zeigt dir, wie lange der Download der Ressource gedauert hat.

Pro-Tipp: Aktiviere „Large request rows“, um zusätzliche Details wie LCP-Latenz, übertragene Größe und tatsächliche Größe zu sehen.

Nutze Real User Monitoring (RUM)-Daten:

RUM-Tools protokollieren oft LCP Attribution-Daten. Diese Zuordnungsdaten für den Largest Contentful Paint enthalten Informationen über die Resource Load Duration. Mit diesen Daten kannst du Trends der Ladedauer im Zeitverlauf oder pro Seite grafisch darstellen. So entdeckst du Seiten oder Elemente, die alles verlangsamen.

Schritt-für-Schritt-Anleitung: Für eine präzise Lab Data-Messung nimmst du einen Trace im Performance-Panel auf. Der LCP Breakdown Insight zeigt die Resource Load Duration neben den anderen drei Teilen an. Komplette Anleitung: LCP mit dem Chrome DevTools Performance-Panel diagnostizieren.

So verbesserst du die LCP Load Duration

Probleme mit der Resource Load Duration treten auf, wenn Ressourcen zu groß sind oder über suboptimale Netzwerkpfade ausgeliefert werden. Zwei Hauptansätze lösen dies: Reduzierung der Datengröße oder Optimierung der Datenauslieferung.

1. Optimiere die Dateigröße

Die Optimierung der Dateigröße reduziert die Anzahl der über das Netzwerk gesendeten Bytes. Weniger Daten bedeuten weniger Download-Zeit. Einen vollständigen Leitfaden zur Bildoptimierung findest du in unserem Artikel über Bildoptimierung.

Nutze moderne Bildformate

AVIF und WebP sind die besten Optionen für die Bildkompression. AVIF komprimiert bei komplexen Fotos bis zu 50 % kleiner als WebP, ohne sichtbaren Qualitätsverlust. WebP wird von mehr Browsern unterstützt und eignet sich gut für einfachere Bilder. Laut dem 2025 Web Almanac wird WebP inzwischen bei über 40 % der Bildanfragen verwendet. Die Nutzung von AVIF hat sich im Jahresvergleich zwar in etwa verdoppelt, liegt aber immer noch unter 10 %.

Die richtige Qualitätseinstellung wählen

Moderne Bildformate wie WebP und AVIF erlauben eine deutliche Reduzierung der Qualität, bevor eine visuelle Verschlechterung sichtbar wird. Als Faustregel gilt: Eine Qualitätseinstellung zwischen 75 und 85 für WebP und zwischen 60 und 75 für AVIF sieht bei normalen Betrachtungsabständen identisch zum Original aus. Die Dateigröße ist jedoch nur ein Bruchteil so groß. Teste immer mit deinen spezifischen Bildern. Die optimale Qualität hängt vom Inhaltstyp ab (Fotos vs. Illustrationen vs. textlastige Bilder).

Bildkomprimierung mit sharp automatisieren

Für die Bildoptimierung zur Build-Zeit ist die sharp-Bibliothek eines der schnellsten und am weitesten verbreiteten Tools im Node.js-Ökosystem. Das folgende Beispiel zeigt, wie du ein Bild in die Formate WebP und AVIF konvertierst und mit optimierten Qualitätseinstellungen komprimierst:

const sharp = require('sharp');

// Convert to WebP with optimized quality
await sharp('input.jpg')
  .resize(1200)  // Resize to maximum needed width
  .webp({ quality: 80, effort: 6 })
  .toFile('output.webp');

// Convert to AVIF with optimized quality
await sharp('input.jpg')
  .resize(1200)
  .avif({ quality: 65, effort: 6 })
  .toFile('output.avif');

// Generate multiple sizes for responsive images
const widths = [400, 800, 1200];
for (const width of widths) {
  await sharp('input.jpg')
    .resize(width)
    .webp({ quality: 80 })
    .toFile(`output-${width}w.webp`);
}

Dieser Ansatz generiert alle Varianten, die du für ein responsives <picture>-Element mit moderner Formatunterstützung benötigst. Bei WordPress-Websites übernehmen Plugins wie ShortPixel oder Imagify diese Konvertierung beim Upload automatisch.

Responsive Bilder

Das <picture>-Element und das srcset-Attribut liefern je nach Bildschirm unterschiedliche Bildgrößen aus: kleinere Versionen für Mobilgeräte, höhere Auflösung für größere Bildschirme. Hier ist ein Beispiel-Setup:

<picture>
  <source media="(min-width: 800px)" srcset="large.jpg 1x, larger.jpg 2x">
  <img src="photo.jpg" alt="Description" width="800" height="450">
</picture>

Korrekte Bildabmessungen

Responsive Bilder sind nur ein Teil der Lösung. Responsiv bedeutet nicht zwingend, dass sie die richtige Größe haben. Bildabmessungen nicht an die Anzeigegröße anzupassen, ist einer der häufigsten Fehler, die ich sehe. Ein 2000 Pixel breites Bild für einen 500 Pixel breiten Anzeigebereich auszuliefern, verschwendet Bandbreite. Es kann die Ladezeiten spürbar verlangsamen.

Optimierung von Schriftdateien

Wenn das LCP-Element Text ist, der mit einem benutzerdefinierten Webfont gerendert wird, wird die Schriftdatei zur LCP-Ressource. Optimiere die Ladedauer der Schrift durch Folgendes:

• Nutze das WOFF2-Format: WOFF2 bietet die beste Kompression für Webfonts. Es ist in der Regel 30 % kleiner als WOFF und deutlich kleiner als TTF- oder OTF-Dateien.
• Erstelle Subsets deiner Schriften: Wenn deine Seite nur lateinische Zeichen verwendet, erstelle ein Subset der Schrift. So entfernst du ungenutzte Zeichensätze (Kyrillisch, Griechisch, CJK). Tools wie glyphhanger oder pyftsubset automatisieren dies. Das reduziert die Dateigröße der Schrift oft um 50 % oder mehr.
• Begrenze Schriftvariationen: Jedes Gewicht und jeder Stil (normal, fett, kursiv) erfordert einen separaten Dateidownload. Binde nur die Gewichte ein, die dein Design tatsächlich verwendet.

2. Optimiere die Netzwerk-Performance

Sobald die Ressourcengrößen optimiert sind, ist der nächste Schritt die Maximierung der Netzwerkgeschwindigkeit. Oder die vollständige Umgehung des Netzwerks.

Netzwerkanfragen durch Browser-Caching umgehen

Es gibt keine schnellere Netzwerkverbindung als eine übersprungene Netzwerkverbindung. Browser können statische Inhalte (Bilder, Skripte, Stylesheets) direkt aus dem lokalen Cache ausliefern. Konfiguriere den Server so, dass er korrekte Caching-Anweisungen an den Browser sendet.

Das effektivste Setup sendet einen Cache-Control-Header wie diesen:

Cache-Control: public, max-age=31536000, immutable

• public: Erlaubt das Caching der Ressource sowohl durch Browser als auch durch Zwischen-Caches.
• max-age=31536000: Setzt die maximale Zeit, in der die Ressource als frisch gilt, auf ein Jahr (31.536.000 Sekunden).
• immutable: Gibt an, dass sich die Ressource im Laufe der Zeit nicht ändert. Das verhindert unnötige Revalidierungsanfragen.

Damit diese Strategie sicher funktioniert, verwende inhaltsbasierte Dateinamen (Content-Hashing, z. B. hero-abc123.webp). Wenn sich das Bild ändert, ändert sich auch der Dateiname. Das leert den Cache automatisch.

Brotli- vs. Gzip-Kompression

Für textbasierte Ressourcen (HTML, CSS, JavaScript, SVG) ist eine serverseitige Kompression unerlässlich. Das von Google entwickelte Brotli übertrifft Gzip konstant beim Kompressionsverhältnis. Dabei behält es vergleichbare Dekompressionsgeschwindigkeiten bei. Der folgende Vergleich veranschaulicht den Unterschied:

Das ideale Setup komprimiert statische Assets während deines Build-Prozesses mit Brotli auf einer hohen Kompressionsstufe (z. B. Stufe 11) vor. Nutze Gzip als Fallback für Clients, die Brotli nicht unterstützen. Die meisten CDNs, einschließlich Cloudflare, handhaben dies automatisch. Weitere Details zur CDN-Konfiguration findest du in unserem Leitfaden zur Konfiguration von Cloudflare für bessere Performance.

HTTP/2 und HTTP/3: Vorteile moderner Protokolle

Das Auslieferungsprotokoll ist am wichtigsten, wenn der Browser mehrere Ressourcen gleichzeitig herunterlädt.

• HTTP/2 hat das Multiplexing eingeführt. Es ermöglicht das gleichzeitige Senden mehrerer Anfragen und Antworten über eine einzige TCP-Verbindung. Dies eliminiert das Head-of-Line-Blocking-Problem von HTTP/1.1. Dort konnte eine langsame Ressource alle anderen verzögern. HTTP/2 unterstützt zudem Header-Kompression (HPACK) und Server-Push.
• HTTP/3 geht noch weiter. Es ersetzt TCP durch QUIC, ein UDP-basiertes Protokoll. HTTP/3 beseitigt Head-of-Line-Blocking auf TCP-Ebene (bei dem ein einziges verlorenes Paket alle Streams blockiert). Es bietet einen schnelleren Verbindungsaufbau durch 0-RTT (Zero Round Trip Time Resumption für wiederkehrende Besucher) und geht eleganter mit Paketverlusten um. Diese Verbesserungen beschleunigen primär die Time to First Byte. Sie reduzieren aber auch die Resource Load Duration.

Um zu prüfen, ob HTTP/3 aktiviert ist, untersuchst du einfach dein Netzwerk mit der Tastenkombination Strg+Umschalt+I. Wähle den Network-Tab, klicke mit der rechten Maustaste auf die Spaltenüberschriften des Netzwerks und stelle sicher, dass „Protocol“ aktiviert ist. Lade die Seite neu und überprüfe das Protokoll. Bei HTTP/3 sollte das Protokoll „h3“ lauten.

Content Delivery Networks (CDN)

Ein CDN ist ein Netzwerk verteilter Server. Sie cachen und liefern statische Ressourcen wie Bilder, CSS und JavaScript von Standorten näher am Nutzer aus. Dies reduziert die Reisezeit der Daten (die Round-Trip-Time). Das wirkt sich direkt auf die Resource Load Duration aus.

Neben der räumlichen Nähe bieten moderne CDNs mehrere Leistungsvorteile, die die Ladedauer verringern:

• Automatische Bildoptimierung: Viele CDNs können Bilder on-the-fly komprimieren, skalieren und konvertieren. Cloudflare Polish, Imgix und Cloudinary können beispielsweise automatisch WebP oder AVIF ausliefern, basierend auf dem Accept-Header des Browsers.
• Edge Caching: Statische Ressourcen werden weltweit auf Edge-Knoten gecacht. Das macht den Abruf vom Ursprungsserver komplett überflüssig.
• Protokolloptimierung: CDNs aktivieren in der Regel standardmäßig HTTP/2 und HTTP/3 zusammen mit Brotli-Kompression. Serverseitige Konfigurationsänderungen sind dafür nicht erforderlich.
• Wiederverwendung von Verbindungen: Da das CDN alle Ressourcen von einer einzigen Domain ausliefert, verwendet der Browser eine einzige Verbindung wieder. Das eliminiert den Overhead durch mehrere DNS-Lookups und TLS-Handshakes.

Spezialisierte Bild-CDNs können dies noch erweitern. Sie bieten automatische Echtzeit-Optimierungen wie Formatkonvertierung, Größenanpassung und Komprimierung.

Self-Hosting von Ressourcen

Wichtige und frühe Netzwerkressourcen sollten standardmäßig immer auf dem Ursprungsserver gehostet werden. Self-Hosting umgeht die Notwendigkeit, sich mit Servern von Drittanbietern zu verbinden. Solche Verbindungen können durch zusätzliche DNS-Lookups, SSL-Aushandlungen und Verbindungsaufbauten erhebliche Verzögerungen verursachen. Self-Hosting stellt die Wiederverwendung einer einzigen, bereits offenen Verbindung sicher. Es reduziert den Overhead durch den Aufbau separater Verbindungen. Selbst gehostete Ressourcen ermöglichen zudem die volle Kontrolle über Kompressions- und Cache-Richtlinien.

3. Optimiere die Ressourcen-Priorisierung

Nach der Reduzierung der Ressourcengröße und der Optimierung des Netzwerks gibt es auch das Problem der Netzwerk-Konkurrenz. Wenn der Browser auf einer langsamen Verbindung mehrere Ressourcen gleichzeitig anfordert, konkurrieren sie um Bandbreite. Minimiere diese Konkurrenz, indem du Ressourcen-Downloads planst.

Priorisiere kritische Ressourcen

Markiere essenzielle Ressourcen wie Hero-Bilder oder Above-the-Fold-CSS mit fetchpriority="high". Dies signalisiert dem Browser, diese Assets zuerst herunterzuladen. Es bewahrt sie davor, durch Skripte, Widgets oder Drittanbieter-Elemente, die nicht sofort geladen werden müssen, ausgebremst zu werden. Die Priorisierung dieser kritischen Ressourcen reduziert die Ladezeit für die Inhalte, die deinen Nutzern am wichtigsten sind. Die Kombination aus Preload (als Lösung für späte Entdeckung) und fetchpriority="high" (als Lösung für Netzwerk-Konkurrenz) ist die wirkungsvollste Technik. Sie stellt sicher, dass die LCP-Ressource so früh und schnell wie möglich abgerufen wird.

<!-- For LCP images visible in the initial HTML -->
<img src="hero-image.webp" fetchpriority="high" alt="...">

<!-- To improve discovery  -->
<link rel="preload" href="hero-image.webp" as="image" fetchpriority="high">

Reduziere Netzwerk-Konkurrenz

Optimiere initiale Downloads, indem du nicht essenzielle Assets aufschiebst oder mit Lazy Loading lädst. Verzögere das Laden von Bildern oder Videos, die nicht sofort sichtbar sind. Gleiches gilt für Hintergrund- oder Sekundärelemente. Die Verwendung von loading="lazy" für Offscreen-Medien ist ein guter Anfang. Das weitere Aufschieben anderer nicht essenzieller Skripte und Assets gibt Bandbreite frei. Es verringert die Konkurrenz mit deinen kritischen Ressourcen. So wird der Hauptinhalt deiner Seite schnell geladen und angezeigt. Wende niemals loading="lazy" auf dein LCP-Bild an. Das ist ein kritisches Anti-Pattern, das deinem Score schadet.

4. Richte Speculation Rules ein

Speculation Rules ermöglichen es Browsern, Webseiten basierend auf der vorhergesagten Nutzer-Navigation vorab abzurufen (Prefetching) oder vorab zu rendern (Prerendering). Prefetching eliminiert effektiv den Time to First Byte-Teil des LCP. Es hat keine Auswirkungen auf die Resource Load Duration. Prerendering rendert die nächste Seite in einem versteckten Tab und lädt alle Seitenressourcen herunter. Dadurch wird der Großteil der Ladedauer für das LCP-Element eliminiert. Das zeigt dieser beispielhafte LCP-Breakdown einer vorgerenderten Seite.

Nächste Schritte: Optimiere das LCP weiter

Die Resource Load Duration ist nur eine der vier LCP-Phasen. Nach der Optimierung der Download-Zeit fährst du mit den anderen LCP-Phasen fort:

• LCP-Probleme identifizieren &amp; beheben: Die komplette diagnostische Methodik, um alle LCP-Probleme mit Field Data und Labor-Tools zu finden und zu beheben.
• Das LCP-Bild optimieren: Auswahl des Bildformats, responsive Bilder, Preloading und häufige Fehler bei der Bildoptimierung.
• Resource Load Delay: Stelle sicher, dass der Browser die LCP-Ressource so früh wie möglich entdeckt. Dies ist oft ein größerer Flaschenhals als die Ladedauer selbst.
• Element Render Delay: Stelle nach dem Download der Ressource sicher, dass der Browser sie sofort rendern kann, indem du den Main Thread freihältst.