Die LCP-Resource-Load-Duration optimieren

Dieser Leitfaden ist Teil des Bereichs Largest Contentful Paint (LCP) unseres Core-Web-Vitals-Ressourcencenters. Die Resource Load Duration ist die dritte von vier aufeinanderfolgenden LCP-Phasen. Sie misst die Zeit, die das Herunterladen der LCP-Ressource über das Netzwerk dauert. Oft macht das Resource Load Delay den größeren Teil der LCP-Zeit aus. Dennoch bleibt eine optimierte Downloaddauer entscheidend für einen guten LCP-Wert.

Die LCP-Resource-Load-Duration optimieren

Der Largest Contentful Paint (LCP) ist eine der drei Core-Web-Vitals-Metriken, die deine Online-UX messen. Der LCP erfasst die Zeit, bis das größte sichtbare Inhaltselement (ein Bild, Video oder Textblock) im Viewport erscheint. Die Resource Load Duration ist eine Teilphase des LCP. Sie gibt an, wie viel Zeit das Laden der Netzwerkressource für das LCP-Element beansprucht.

Was ist die Resource Load Duration beim LCP?

Die Resource Load Duration – oft einfach Load Duration genannt – bezeichnet die Zeit, die der Browser zum Herunterladen der Netzwerkressource (z. B. eines Bildes) benötigt, die später das LCP-Element wird. Bei Bildern und Videos reicht diese Dauer vom Start des Downloads bis zum vollständigen Laden durch den Browser. Bei textbasierten LCP-Elementen liegt die Ladedauer in der Regel bei null. Googles Leitfaden zur LCP-Optimierung unterteilt den LCP in vier aufeinanderfolgende Teilphasen. Die Resource Load Duration ist dabei die Zeit, in der die eigentlichen Bytes der Ressource heruntergeladen werden.

Die Resource Load Duration wird von dem Moment an gemessen, in dem der Browser den Download der LCP-Ressource startet, bis er abgeschlossen ist. Vier Hauptfaktoren bestimmen die Resource Load Duration:

• Dateigröße: Größere Dateien erfordern längere Downloadzeiten.
• Netzwerkgeschwindigkeit: Langsamere Verbindungen verlängern die Ladedauer naturgemäß.
• Antwortzeit des Servers: Verzögerungen bei der Serverantwort bremsen das Laden der Ressource aus.
• Gleichzeitige Downloads: Werden Ressourcen parallel geladen, konkurrieren sie um Bandbreite. Das kann die Ladezeiten verlängern.

So ermittelst du die Resource Load Duration

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

Netzwerkanalyse in den Chrome DevTools: Öffne die Developer Tools von Chrome mit dem Tastenkürzel Strg + Umschalt + I. Wähle den Tab „Netzwerk“ und lade die Seite neu. Suche nach dem LCP-Element in den Netzwerk-Requests (wenn du das LCP-Element ermitteln willst, teste den Core Web Vitals Visualizer). Die Netzwerkanalyse zeigt dir, wie lange der Download der Ressource gedauert hat.

Profi-Tipp: Aktiviere große Request-Zeilen, um zusätzliche Details wie LCP-Latenz, übertragene Größe und tatsächliche Größe zu sehen.

Real-User-Monitoring-Daten (RUM) nutzen:

RUM-Tools erfassen häufig LCP-Attributionsdaten. Diese Daten für den Largest Contentful Paint enthalten Informationen zur Resource Load Duration. Damit kannst du Trends der Ladedauer im Zeitverlauf oder pro Seite darstellen und Seiten oder Elemente aufspüren, die bremsen.

Schritt-für-Schritt-Anleitung: Zeichne für eine präzise Lab-Messung einen Trace im Performance-Panel auf. Der LCP-Breakdown zeigt die Resource Load Duration neben den anderen drei Teilphasen. Vollständige Anleitung: LCP mit dem Performance-Panel der Chrome DevTools diagnostizieren.

So verbesserst du die LCP-Ladedauer

Probleme mit der Resource Load Duration entstehen, wenn Ressourcen zu groß sind oder über suboptimale Netzwerkpfade ausgeliefert werden. Zwei zentrale Hebel lösen das: die Datenmenge reduzieren oder die Datenübertragung optimieren.

1. Dateigröße optimieren

Eine optimierte Dateigröße reduziert die Bytes, die über das Netzwerk übertragen werden. Weniger Daten bedeuten kürzere Downloadzeiten. Eine vollständige Anleitung findest du in unserem Leitfaden darüber, wie du Bilder optimierst.

Moderne Bildformate nutzen

AVIF und WebP sind die besten Optionen für die Bildkompression. Bei komplexen Fotos komprimiert AVIF bis zu 50 % kleiner als WebP – ohne sichtbaren Qualitätsverlust. WebP bietet die breitere Browserunterstützung und eignet sich gut für einfachere Bilder. Laut dem Web Almanac 2025 wird WebP mittlerweile bei über 40 % aller Bild-Requests genutzt. Die Verbreitung von AVIF hat sich im Jahresvergleich zwar ungefähr verdoppelt, liegt aber immer noch unter 10 %.

Die richtige Qualitätseinstellung wählen

Moderne Bildformate wie WebP und AVIF erlauben eine deutliche Qualitätsreduzierung, bevor optische Verluste sichtbar werden. Als Faustregel gilt: Eine Qualitätseinstellung zwischen 75 und 85 bei WebP und zwischen 60 und 75 bei AVIF sieht bei normalem Betrachtungsabstand identisch zum Original aus – bei einem Bruchteil der Dateigröße. Teste das immer an deinen konkreten Bildern: Die optimale Qualität hängt vom Inhalt ab (Fotos vs. Illustrationen vs. textlastige Grafiken).

Bildkompression mit Sharp automatisieren

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

const sharp = require('sharp');

// In WebP mit optimierter Qualität konvertieren
await sharp('input.jpg')
  .resize(1200)  // Auf maximal benötigte Breite skalieren
  .webp({ quality: 80, effort: 6 })
  .toFile('output.webp');

// In AVIF mit optimierter Qualität konvertieren
await sharp('input.jpg')
  .resize(1200)
  .avif({ quality: 65, effort: 6 })
  .toFile('output.avif');

// Mehrere Größen für responsive Bilder generieren
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 erzeugt alle Varianten, die du für ein responsives <picture>-Element mit Unterstützung moderner Formate benötigst. Bei WordPress-Websites erledigen Plugins wie ShortPixel oder Imagify diese Konvertierung automatisch beim Upload.

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ösungen für größere Bildschirme. Ein Beispielaufbau:

<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. Denn responsive bedeutet nicht automatisch passgenau. Die Bildabmessungen nicht an die Anzeigegröße anzupassen, ist einer der häufigsten Fehler, die ich in der Praxis sehe. Ein 2000 Pixel breites Bild für eine 500 Pixel breite Anzeigefläche auszuliefern, verschwendet Bandbreite und bremst die Ladezeit spürbar aus.

Schriftdateien optimieren

Wenn das LCP-Element ein Text ist, der mit einem Webfont gerendert wird, wird die Schriftdatei zur LCP-Ressource. So optimierst du die Ladedauer von Schriften:

• WOFF2-Format nutzen: WOFF2 bietet die beste Kompression für Webfonts – typischerweise 30 % kleiner als WOFF und deutlich kleiner als TTF- oder OTF-Dateien.
• Fonts subsetten: Wenn deine Website nur lateinische Zeichen nutzt, entferne ungenutzte Zeichensätze (Kyrillisch, Griechisch, CJK) per Subsetting. Tools wie glyphhanger oder pyftsubset können das automatisieren und reduzieren die Dateigröße oft um 50 % oder mehr.
• Schriftvarianten begrenzen: Jeder Schriftschnitt und Stil (Regular, Bold, Italic) ist ein separater Download. Binde nur die Schnitte ein, die dein Design tatsächlich verwendet.

2. Netzwerkleistung verbessern

Sobald die Dateigrößen optimiert sind, geht es darum, die Netzwerkgeschwindigkeit zu maximieren – oder das Netzwerk komplett zu umgehen.

Das Netzwerk per Browser-Caching umgehen

Keine Netzwerkverbindung ist schneller als eine vermiedene Verbindung. Browser können statische Inhalte (Bilder, Skripte, Stylesheets) direkt aus dem lokalen Cache laden. Konfiguriere den Server so, dass er korrekte Caching-Anweisungen an den Browser sendet.

Am effektivsten ist ein Cache-Control-Header wie dieser:

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

• public: Erlaubt Browsern und Zwischen-Caches, die Ressource zu cachen.
• max-age=31536000: Legt fest, dass die Ressource für maximal ein Jahr (31.536.000 Sekunden) als aktuell gilt.
• immutable: Signalisiert, dass sich die Ressource nicht mehr ändert. Das verhindert unnötige Revalidierungs-Requests.

Damit diese Strategie sicher funktioniert, nutze Dateinamen mit Content-Hash (z. B. hero-abc123.webp). Ändert sich das Bild, ändert sich auch der Dateiname – und der Cache wird automatisch invalidiert.

Brotli- vs. Gzip-Kompression

Bei textbasierten Ressourcen (HTML, CSS, JavaScript, SVG) ist eine serverseitige Kompression unverzichtbar. Das von Google entwickelte Brotli übertrifft Gzip bei der Kompressionsrate durchweg – bei vergleichbarer Dekomprimierungsgeschwindigkeit. Der folgende Vergleich zeigt die Unterschiede:

Das ideale Setup: Komprimiere statische Assets während des Build-Prozesses mit Brotli auf einer hohen Kompressionsstufe vor (z. B. Stufe 11) und nutze Gzip als Fallback für Clients ohne Brotli-Unterstützung. Die meisten CDNs wie Cloudflare erledigen das automatisch. Mehr Details zur CDN-Konfiguration findest du in unserem Leitfaden dazu, wie du Cloudflare für maximale Performance konfigurierst.

HTTP/2 und HTTP/3: Vorteile moderner Protokolle

Das Übertragungsprotokoll spielt vor allem dann eine Rolle, wenn der Browser mehrere Ressourcen gleichzeitig herunterlädt.

• HTTP/2 brachte Multiplexing: Mehrere Requests und Responses werden gleichzeitig über eine einzige TCP-Verbindung gesendet. Das beseitigt das Head-of-Line-Blocking von HTTP/1.1, bei dem eine langsame Ressource alle anderen aufhalten konnte. Zudem unterstützt HTTP/2 Header-Komprimierung (HPACK) und Server-Push.
• HTTP/3 geht noch weiter und ersetzt TCP durch QUIC, ein UDP-basiertes Protokoll. HTTP/3 eliminiert Head-of-Line-Blocking auf TCP-Ebene (bei dem ein einzelnes verlorenes Paket alle Streams blockiert). Es beschleunigt den Verbindungsaufbau via 0-RTT (Zero Round Trip Time für wiederkehrende Besucher) und federt Paketverluste deutlich besser ab. Diese Verbesserungen verkürzen vor allem die Time to First Byte, reduzieren aber auch die Resource Load Duration.

Ob HTTP/3 aktiv ist, kannst du direkt im Netzwerk-Tab prüfen: Öffne die DevTools mit dem Tastenkürzel Strg + Umschalt + I. Klicke mit der rechten Maustaste auf die Spaltenüberschriften im Netzwerk-Tab und stelle sicher, dass „Protokoll“ aktiviert ist. Lade die Seite neu und prüfe das Protokoll. Bei HTTP/3 sollte dort „h3“ stehen.

Content Delivery Networks (CDN)

Ein CDN ist ein verteiltes Servernetzwerk. Es cacht statische Ressourcen wie Bilder, CSS und JavaScript und liefert sie von Standorten aus, die näher am Nutzer liegen. Das verkürzt die Übertragungszeit der Daten (die Round-Trip-Time) und wirkt sich direkt auf die Resource Load Duration aus.

Neben der geografischen Nähe bieten moderne CDNs weitere Performance-Vorteile, die die Ladedauer verkürzen:

• Automatische Bildoptimierung: Viele CDNs können Bilder on-the-fly komprimieren, skalieren und konvertieren. Tools wie Cloudflare Polish, Imgix oder Cloudinary liefern basierend auf dem Accept-Header des Browsers automatisch WebP oder AVIF aus.
• Edge-Caching: Statische Ressourcen liegen auf Edge-Knoten weltweit im Cache. Ein Abruf vom Origin-Server entfällt dadurch komplett.
• Protokoll-Optimierung: CDNs aktivieren HTTP/2 und HTTP/3 sowie Brotli-Kompression meist standardmäßig – ohne manuelle Serverkonfiguration.
• Wiederverwendung von Verbindungen: Da das CDN alle Ressourcen über eine einzige Domain ausliefert, nutzt der Browser dieselbe Verbindung mehrfach. Das spart den Overhead durch zusätzliche DNS-Lookups und TLS-Handshakes.

Spezialisierte Image-CDNs gehen noch weiter: Sie optimieren Formate, Skalierung und Kompression automatisch in Echtzeit.

Ressourcen selbst hosten

Wichtige und früh benötigte Netzwerkressourcen solltest du standardmäßig immer auf dem Origin-Server hosten. Self-Hosting vermeidet Verbindungen zu Drittanbieter-Servern. Diese führen durch zusätzliche DNS-Lookups, SSL-Handshakes und Verbindungsaufbauten oft zu spürbaren Verzögerungen. Du nutzt eine bereits offene Verbindung weiter und sparst den Overhead neuer Verbindungen. Zudem behältst du bei selbst gehosteten Ressourcen die volle Kontrolle über Kompression und Cache-Header.

3. Ressourcen-Priorisierung optimieren

Nachdem Dateigröße und Netzwerk optimiert sind, bleibt das Problem der Bandbreitenkonkurrenz: Fragt der Browser bei einer langsamen Verbindung mehrere Ressourcen gleichzeitig an, konkurrieren sie um Bandbreite. Minimiere diese Konkurrenz, indem du Downloads gezielt steuerst.

Kritische Ressourcen priorisieren

Kennzeichne wichtige Ressourcen wie Hero-Bilder oder Above-the-fold-CSS mit fetchpriority="high". Das signalisiert dem Browser, diese Assets zuerst zu laden. So werden sie nicht von Skripten, Widgets oder Drittanbieter-Elementen ausgebremst, die nicht sofort gebraucht werden. Die Priorisierung kritischer Ressourcen verkürzt die Ladezeit für die Inhalte, die deinen Nutzern am wichtigsten sind. Die Kombination aus Preload (behebt eine späte Erkennung) und fetchpriority="high" (löst Bandbreitenkonflikte) ist der wirksamste Hebel, damit die LCP-Ressource so früh und schnell wie möglich geladen wird.

<!-- Für LCP-Bilder, die im initialen HTML sichtbar sind -->
<img src="hero-image.webp" fetchpriority="high" alt="...">

<!-- Um die Erkennung zu verbessern -->
<link rel="preload" href="hero-image.webp" as="image" fetchpriority="high">

Bandbreitenkonflikte reduzieren

Entlaste die initialen Downloads, indem du unkritische Assets aufschiebst oder per Lazy Loading nachlädst. Verzögere das Laden von Bildern oder Videos, die nicht sofort sichtbar sind, genauso wie Hintergrund- oder Sekundärelemente. loading="lazy" für Offscreen-Medien ist ein guter Anfang. Wenn du zusätzlich unwichtige Skripte und Assets nach hinten verschiebst, gibst du Bandbreite frei. Das verringert die Konkurrenz zu deinen kritischen Ressourcen – der Hauptinhalt deiner Seite lädt und erscheint schneller. Setze loading="lazy" niemals für dein LCP-Bild ein: Das ist ein schwerer Fehler (Anti-Pattern), der deinen LCP-Wert ruiniert.

4. Speculation Rules einrichten

Mit Speculation Rules können Browser Seiten basierend auf der erwarteten Navigation vorab abrufen (Prefetch) oder komplett vorab rendern (Prerender). Prefetching eliminiert die Time-to-First-Byte-Phase des LCP praktisch vollständig, hat aber keinen Einfluss auf die Resource Load Duration. Prerendering rendert die nächste Seite in einem unsichtbaren Tab und lädt alle Ressourcen der Seite herunter. Das eliminiert die Ladedauer für das LCP-Element fast komplett, wie dieser beispielhafte LCP-Breakdown einer vorgerenderten Seite zeigt.

Nächste Schritte: LCP weiter optimieren

Die Resource Load Duration ist nur eine von vier LCP-Phasen. Wenn du die Downloadzeit optimiert hast, widme dich den weiteren LCP-Phasen:

• LCP-Probleme erkennen und beheben: Die vollständige Diagnose-Methodik, um alle LCP-Probleme mit Field Data und Lab-Tools aufzuspüren und zu lösen.
• Das LCP-Bild optimieren: Wahl des Bildformats, responsive Bilder, Preloading und typische Fehler bei der Bildoptimierung.
• Resource Load Delay: Sorge dafür, dass der Browser die LCP-Ressource so früh wie möglich entdeckt. Das ist oft ein größerer Engpass als die Ladedauer selbst.
• Element Render Delay: Stelle sicher, dass der Browser die Ressource nach dem Download sofort zeichnen kann, indem du den Main Thread freihältst.