Die LCP Resource Load Duration optimieren

Dieser Leitfaden ist Teil des Abschnitts Largest Contentful Paint (LCP) in unserem Core Web Vitals Ressourcenzentrum. Die Resource Load Duration ist die dritte von vier aufeinanderfolgenden LCP-Phasen und misst die Zeit, die zum Herunterladen der LCP-Ressource über das Netzwerk benötigt wird. Während die Resource Load Delay oft einen größeren Anteil an der LCP-Zeit ausmacht, bleibt die Optimierung der Download-Dauer entscheidend für das Erreichen eines guten LCP-Werts.

Die LCP Resource Load Duration optimieren

Largest Contentful Paint (LCP) ist eine der drei Core Web Vitals Leistungsmetriken, die Ihre Online-Nutzererfahrung messen. Der LCP erfasst die Zeit, bis das größte sichtbare Element (ein Bild, Video oder Textblock) im Viewport sichtbar wird. Die Resource Load Duration ist ein Teilbereich des LCP, der angibt, wie viel Zeit für das Abrufen der Netzwerkressource des LCP-Elements aufgewendet wird.

Was ist die Resource Load Duration beim LCP?

Resource Load Duration, oft auch Load Duration genannt, bezeichnet die Zeit, die der Browser zum Herunterladen der Netzwerkressource (z. B. eines Bildes) benötigt, die letztendlich zum LCP-Element wird. Bei Bildern und Videos erstreckt sich diese Dauer vom Beginn des Downloads bis zum Abschluss durch den Browser. Bei textbasierten LCP-Elementen ist die Load Duration typischerweise null. Googles LCP-Optimierungsleitfaden unterteilt den LCP in vier aufeinanderfolgende Teilbereiche, wobei die Resource Load Duration die Zeit umfasst, die tatsächlich für das Herunterladen der Ressource-Bytes aufgewendet wird.

Die Resource Load Duration wird ab dem Moment gemessen, in dem der Browser mit dem Herunterladen der LCP-Ressource beginnt, bis der Download abgeschlossen ist. Vier Hauptfaktoren bestimmen die Resource Load Duration:

• Dateigröße: Größere Dateien erfordern längere Downloadzeiten.
• Netzwerkgeschwindigkeit: Langsamere Verbindungen verlängern die Load Duration naturgemäß.
• Server-Reaktionsfähigkeit: Verzögerungen bei der Serverantwort verlangsamen das Abrufen der Ressource.
• Gleichzeitige Downloads: Ressourcen, die gleichzeitig heruntergeladen werden, konkurrieren um Bandbreite, was die Ladezeiten erhöhen kann.

Wie man die Resource Load Duration erkennt

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

Netzwerkinspektion in Chrome DevTools: Verwenden Sie die Tastenkombination Strg + Umschalt + I, um die Chrome-Entwicklertools zu öffnen, wählen Sie dann den Tab „Network" und laden Sie die Seite neu. Suchen Sie das LCP-Element in den Netzwerkanfragen (wenn Sie das LCP-Element ermitteln möchten, probieren Sie den Core Web Vitals Visualizer). Der Netzwerkinspektor zeigt Ihnen, wie lange der Download der Ressource gedauert hat.

Profi-Tipp: Aktivieren Sie große Anforderungszeilen, um zusätzliche Details wie LCP-Latenz, übertragene Größe und tatsächliche Größe anzuzeigen.

Real User Monitoring (RUM)-Daten verwenden:

RUM-Tools protokollieren häufig LCP-Attributionsdaten. Attributionsdaten für den Largest Contentful Paint enthalten Informationen über die Resource Load Duration. Mit diesen Daten können Sie Load-Duration-Trends über die Zeit oder nach Seiten darstellen und die Seiten oder Elemente identifizieren, die die Ladezeiten verlangsamen.

Wie man die LCP Load Duration verbessert

Probleme mit der Resource Load Duration entstehen, wenn Ressourcen zu groß sind oder über suboptimale Netzwerkpfade ausgeliefert werden. Zwei Hauptansätze beheben dies: Datengröße reduzieren oder Datenübertragung optimieren.

1. Dateigröße optimieren

Die Optimierung der Dateigröße reduziert die Anzahl der Bytes, die über das Netzwerk gesendet werden müssen. Weniger Daten bedeuten weniger Downloadzeit. Einen vollständigen Leitfaden zur Bildoptimierung finden Sie in unserem Artikel über die Optimierung von Bildern für Core Web Vitals.

Moderne Bildformate verwenden

AVIF und WebP sind die besten Optionen für Bildkomprimierung. AVIF komprimiert bei komplexen Fotos bis zu 50 % kleiner als WebP, ohne sichtbaren Qualitätsverlust. WebP hat eine breitere Browser-Unterstützung und funktioniert gut bei einfacheren Bildern. Laut dem 2025 Web Almanac wird WebP inzwischen bei über 40 % der Bildanfragen verwendet, während die AVIF-Nutzung sich von Jahr zu Jahr ungefähr verdoppelt hat, aber immer noch unter 10 % liegt.

Die richtige Qualitätseinstellung wählen

Moderne Bildformate wie WebP und AVIF ermöglichen eine deutliche Qualitätsreduzierung, bevor eine sichtbare Verschlechterung erkennbar 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 mit dem Original aus – bei einem Bruchteil der Dateigröße. Testen Sie immer mit Ihren spezifischen Bildern, da die optimale Qualität vom Inhaltstyp abhängt (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 häufigsten verwendeten Tools im Node.js-Ökosystem. Das folgende Beispiel zeigt, wie man ein Bild in die Formate WebP und AVIF mit optimierten Qualitätseinstellungen konvertiert und komprimiert:

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 Sie für ein responsives <picture>-Element mit Unterstützung moderner Formate benötigen. Für WordPress-Websites übernehmen Plugins wie ShortPixel oder Imagify diese Konvertierung automatisch beim Upload.

Responsive Bilder

Das <picture>-Element und das srcset-Attribut liefern je nach Bildschirmgröße unterschiedliche Bildgrößen: kleinere Versionen für Mobilgeräte, höhere Auflösungen 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, denn responsiv bedeutet nicht, dass sie die richtige Größe haben. Die Anpassung der Bildabmessungen an die Anzeigegröße ist einer der häufigsten Fehler, die ich sehe. Ein 2000px breites Bild für einen 500px großen Anzeigebereich zu laden, verschwendet Bandbreite und kann die Ladezeiten spürbar verlangsamen.

Schriftdatei-Optimierung

Wenn das LCP-Element ein Text ist, der mit einer benutzerdefinierten Web-Schriftart gerendert wird, wird die Schriftdatei zur LCP-Ressource. Optimieren Sie die Load Duration der Schriftart durch:

• WOFF2-Format verwenden: WOFF2 bietet die beste Komprimierung für Web-Schriftarten, typischerweise 30 % kleiner als WOFF und deutlich kleiner als TTF- oder OTF-Dateien.
• Schriftarten subsetten: Wenn Ihre Website nur lateinische Zeichen verwendet, entfernen Sie nicht benötigte Zeichensätze (Kyrillisch, Griechisch, CJK) aus der Schriftart. Tools wie glyphhanger oder pyftsubset können dies automatisieren und die Schriftdateigröße oft um 50 % oder mehr reduzieren.
• Schriftvarianten begrenzen: Jede Schriftstärke und jeder Stil (Regular, Bold, Italic) ist ein separater Datei-Download. Verwenden Sie nur die Schriftstärken, die Ihr Design tatsächlich nutzt.

2. Netzwerkleistung verbessern

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

Netzwerk mit 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 bereitstellen. Konfigurieren Sie den Server so, dass er korrekte Caching-Anweisungen an den Browser sendet.

Die effektivste Konfiguration ist das Senden eines Cache-Control-Headers wie diesem:

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

• public: Erlaubt die Zwischenspeicherung der Ressource sowohl durch Browser als auch durch zwischengeschaltete Caches.
• max-age=31536000: Setzt die maximale Zeit, in der die Ressource als aktuell gilt, auf ein Jahr (31.536.000 Sekunden).
• immutable: Zeigt an, dass sich die Ressource im Laufe der Zeit nicht ändern wird, wodurch unnötige Revalidierungsanfragen vermieden werden.

Damit diese Strategie sicher funktioniert, verwenden Sie Content-Hash-Dateinamen (z. B. hero-abc123.webp), sodass sich bei Bildänderungen auch der Dateiname ändert und der Cache automatisch invalidiert wird.

Brotli vs. Gzip-Komprimierung

Für textbasierte Ressourcen (HTML, CSS, JavaScript, SVG) ist serverseitige Komprimierung unerlässlich. Brotli, von Google entwickelt, übertrifft Gzip konstant im Komprimierungsverhältnis bei vergleichbaren Dekomprimierungsgeschwindigkeiten. Der folgende Vergleich veranschaulicht den Unterschied:

Die ideale Konfiguration ist, statische Assets während des Build-Prozesses mit Brotli auf hoher Komprimierungsstufe (z. B. Stufe 11) vorzukomprimieren und Gzip als Fallback für Clients zu verwenden, die Brotli nicht unterstützen. Die meisten CDNs, einschließlich Cloudflare, erledigen dies automatisch. Weitere Details zur CDN-Konfiguration finden Sie in unserem Leitfaden zur Konfiguration von Cloudflare für optimale Performance.

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 führte Multiplexing ein, das es ermöglicht, mehrere Anfragen und Antworten gleichzeitig über eine einzige TCP-Verbindung zu senden. Dies beseitigt das Head-of-Line-Blocking-Problem von HTTP/1.1, bei dem eine langsame Ressource alle anderen verzögern konnte. HTTP/2 unterstützt außerdem Header-Komprimierung (HPACK) und Server Push.
• HTTP/3 geht noch weiter, indem es TCP durch QUIC ersetzt, ein UDP-basiertes Protokoll. HTTP/3 beseitigt TCP-seitiges Head-of-Line-Blocking (bei dem ein einzelnes verlorenes Paket alle Streams blockiert), ermöglicht schnelleren Verbindungsaufbau durch 0-RTT (Zero Round Trip Time-Wiederaufnahme für wiederkehrende Besucher) und handhabt Paketverluste eleganter. Diese Verbesserungen beschleunigen primär die Time to First Byte, reduzieren aber auch die Resource Load Duration.

Um zu prüfen, ob HTTP/3 aktiviert ist, inspizieren Sie einfach Ihr Netzwerk mit der Tastenkombination Strg+Umschalt+I. Wählen Sie den Network-Tab, klicken Sie mit der rechten Maustaste auf die Netzwerk-Spaltenüberschriften und stellen Sie sicher, dass „protocol" aktiviert ist. Laden Sie die Seite neu und prüfen Sie das Protokoll. Für HTTP/3 sollte das Protokoll „h3" anzeigen.

Content Delivery Networks (CDN)

Ein CDN ist ein Netzwerk verteilter Server, die statische Ressourcen wie Bilder, CSS und JavaScript von Standorten zwischenspeichern und ausliefern, die näher am Nutzer liegen. Dies reduziert die Datenübertragungszeit (die Round-Trip-Time), was sich direkt auf die Resource Load Duration auswirkt.

Über die räumliche Nähe hinaus bieten moderne CDNs mehrere Leistungsvorteile, die die Load Duration reduzieren:

• Automatische Bildoptimierung: Viele CDNs können Bilder on-the-fly komprimieren, skalieren und konvertieren. Beispielsweise können Cloudflare Polish, Imgix und Cloudinary WebP oder AVIF automatisch basierend auf dem Accept-Header des Browsers ausliefern.
• Edge-Caching: Statische Ressourcen werden an Edge-Knoten weltweit zwischengespeichert, wodurch der Abruf vom Ursprungsserver vollständig entfällt.
• Protokolloptimierung: CDNs aktivieren in der Regel HTTP/2 und HTTP/3 standardmäßig, zusammen mit Brotli-Komprimierung, ohne dass serverseitige Konfigurationsänderungen erforderlich sind.
• Verbindungswiederverwendung: Da das CDN alle Ressourcen von einer einzigen Domain ausliefert, nutzt der Browser eine einzige Verbindung wieder, wodurch der Overhead mehrerer DNS-Lookups und TLS-Handshakes entfällt.

Spezialisierte Bild-CDNs können dies noch weiter optimieren, indem sie automatische Echtzeit-Optimierungen wie Formatkonvertierung, Größenanpassung und Komprimierung bereitstellen.

Ressourcen selbst hosten

Wichtige und früh benötigte Netzwerkressourcen sollten standardmäßig immer auf dem Ursprungsserver gehostet werden. Self-Hosting umgeht die Notwendigkeit, sich mit Drittanbieter-Servern zu verbinden, was aufgrund zusätzlicher DNS-Lookups, SSL-Verhandlungen und Verbindungsaufbauten erhebliche Verzögerungen verursachen kann. Self-Hosting gewährleistet die Wiederverwendung einer einzelnen, bereits offenen Verbindung und reduziert den Overhead des Aufbaus separater Verbindungen. Selbst gehostete Ressourcen ermöglichen außerdem die volle Kontrolle über Komprimierung und Cache-Richtlinien.

3. Ressourcenpriorisierung optimieren

Nach der Reduzierung der Ressourcengröße und der Optimierung des Netzwerks gibt es noch das Problem der Netzwerkkonkurrenz. Wenn der Browser auf einer langsamen Verbindung mehrere Ressourcen gleichzeitig anfordert, konkurrieren diese um Bandbreite. Minimieren Sie diese Konkurrenz durch die zeitliche Steuerung der Ressourcen-Downloads.

Kritische Ressourcen priorisieren

Kennzeichnen Sie wichtige Ressourcen, wie Hero-Bilder oder Above-the-Fold-CSS, mit fetchpriority="high". Dies signalisiert dem Browser, diese Assets zuerst herunterzuladen, damit sie nicht durch Skripte, Widgets oder Drittanbieter-Elemente gebremst werden, die kein sofortiges Laden erfordern. Die Priorisierung dieser kritischen Ressourcen verkürzt die Ladezeit für die Inhalte, die Ihren Nutzern am wichtigsten sind. Die Kombination von Preload (zur Lösung der späten Entdeckung) und fetchpriority="high" (zur Lösung der Netzwerkkonkurrenz) ist die wirkungsvollste Technik, um sicherzustellen, dass die LCP-Ressource so früh und so 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">

Netzwerkkonkurrenz reduzieren

Optimieren Sie die initialen Downloads, indem Sie nicht-essentielle Assets verzögert oder per Lazy Loading laden. Verschieben Sie das Laden von Bildern oder Videos, die nicht sofort sichtbar sind, sowie von Hintergrund- oder sekundären Elementen. Die Verwendung von loading="lazy" für Medien außerhalb des sichtbaren Bereichs ist ein guter Anfang, während das zusätzliche Verzögern anderer nicht-essentieller Skripte und Assets Bandbreite freigeben und die Konkurrenz mit Ihren kritischen Ressourcen reduzieren wird, sodass der Hauptinhalt Ihrer Seite schnell geladen und angezeigt wird. Wenden Sie niemals loading="lazy" auf Ihr LCP-Bild an; dies ist ein kritisches Anti-Pattern, das Ihren Score verschlechtert.

4. Speculation Rules einrichten

Speculation Rules ermöglichen es Browsern, Webseiten basierend auf vorhergesagter Benutzernavigation vorab abzurufen oder vorzurendern. Prefetching eliminiert effektiv den Time to First Byte-Teilbereich des LCP und hat keinen Einfluss auf die Resource Load Duration. Prerendering rendert die nächste Seite in einem verborgenen Tab und lädt alle Seitenressourcen herunter. Dies eliminiert den größten Teil der Load Duration für das LCP-Element, wie dieses Beispiel einer LCP-Aufschlüsselung einer vorgerenderten Seite zeigt.

Nächste Schritte: LCP weiter optimieren

Die Resource Load Duration ist nur eine der vier LCP-Phasen. Nach der Optimierung der Download-Zeit fahren Sie mit den anderen LCP-Phasen fort:

• LCP-Probleme finden und beheben: Die vollständige Diagnosemethodik zum Finden und Beheben aller LCP-Probleme mit Felddaten und Lab-Tools.
• Das LCP-Bild optimieren: Bildformatauswahl, responsive Bilder, Preloading und häufige Fehler bei der Bildoptimierung.
• Resource Load Delay: Stellen Sie sicher, dass der Browser die LCP-Ressource so früh wie möglich entdeckt. Dies ist oft ein größerer Engpass als die Load Duration selbst.
• Element Render Delay: Nachdem die Ressource heruntergeladen wurde, stellen Sie sicher, dass der Browser sie sofort rendern kann, indem Sie den Main Thread freimachen.