fetchpriority: LCP mit Priority Hints beschleunigen

Beim Laden einer Seite ist der Browser ein Planer, der jeder Ressource eine Priorität zuweist und entscheidet, was zuerst geladen wird. Für Bilder gilt dabei eine pauschale Annahme: Sie starten mit niedriger Priorität, weil viele Bilder unterhalb des sichtbaren Bereichs liegen oder in aufklappbaren Menüs versteckt sind. Erst wenn der Browser das Layout berechnet hat und erkennt, dass ein Bild im Viewport sichtbar ist, stuft er es nachträglich hoch (web.dev). Diese Hochstufung kommt jedoch spät -- der Browser muss erst das CSS verarbeiten und das Layout berechnen, bevor er weiß, welches Bild sichtbar ist.

Für das LCP-Bild ist das ein Problem. Es ist das größte und damit für den ersten Eindruck wichtigste Bild der Seite, wird aber zunächst wie jedes andere behandelt. Im Netzwerk-Wasserfall zeigt sich das als langer grauer Balken: Der Browser kennt die Ressource bereits, hat den Download aber noch nicht begonnen, weil andere, höher eingestufte Ressourcen Vorrang haben (DebugBear). Erst nach dem ersten Rendering wechselt die Priorität von low auf high -- und kostbare Zeit ist verstrichen, bevor das wichtigste Bild überhaupt zu laden beginnt.

Das fetchpriority-Attribut teilt dem Browser die relative Wichtigkeit einer Ressource mit, bevor er das Layout berechnet hat. Der Wert high zieht eine Ressource vor, low schiebt sie nach hinten, auto überlässt dem Browser die Standardentscheidung. Auf das LCP-Bild gesetzt, bewirkt fetchpriority='high', dass der Browser die Wichtigkeit sofort erkennt und das Bild unmittelbar nach der Dokumentanforderung lädt, statt es hinter niedriger eingestufte Ressourcen einzureihen. Im Wasserfall verschwindet der lange graue Wartebalken, und die Priorität wechselt nicht mehr von low auf high -- sie ist von Anfang an hoch (DebugBear).

Die Wirkung ist in mehreren Fällen dokumentiert. Bei einem Test mit einer Flugsuche verbesserte der Hint den Largest Contentful Paint von 2,6 auf 1,9 Sekunden (web.dev), also um 0,7 Sekunden. DebugBear dokumentiert einen Fall, in dem das LCP-Bild nach dem Setzen des Attributs unmittelbar nach der Dokumentanforderung lud und der LCP von 4,2 auf 1,9 Sekunden (DebugBear) fiel. Addy Osmani berichtet, dass Priority Hints den LCP einer großen Handelsplattform um 4 Prozent (Addy Osmani) beschleunigten und manche Seiten in ihren Labortests 20 bis 30 Prozent (Addy Osmani) schnellere LCP-Werte erreichten. Die genaue Ersparnis hängt davon ab, wie spät der Browser das Bild sonst entdeckt hätte -- je größer der Wasserfall davor, desto größer der Hebel.

Wichtig ist die Einordnung: fetchpriority ist ein Hinweis, kein Befehl. Der Browser versucht, der Entwicklervorgabe zu folgen, darf sie aber gegen seine eigenen Heuristiken abwägen, um Konflikte aufzulösen (web.dev). In der Praxis bedeutet das, dass die Wirkung am verlässlichsten dort ist, wo der Browser sonst eine erkennbar falsche Entscheidung getroffen hätte -- etwa beim spät hochgestuften LCP-Bild. Hat man das Bild dagegen ohnehin schon als eines der ersten Elemente im Kopf des Dokuments vorgeladen, fällt der zusätzliche Gewinn durch fetchpriority kleiner aus, weil der Browser den Download dann bereits früh angestoßen hat. Genau dieses Zusammenspiel von preload und fetchpriority betrachten wir weiter unten im Detail.

Der wichtigste Grundsatz beim Priority Hint lautet: genau ein Element bekommt high. Die Versuchung ist groß, gleich mehrere wichtige Bilder hochzustufen -- den Hero, die Slider-Bilder, die Logos. Doch damit kippt der Effekt ins Gegenteil. Bandbreite ist begrenzt, besonders auf Mobilnetzen. Werden mehrere Ressourcen gleichzeitig als hochpriorisiert angefordert, konkurrieren sie um dieselbe Leitung und bremsen sich gegenseitig aus. DebugBear beschreibt einen Fall, in dem sieben Slider-Bilder unterhalb des sichtbaren Bereichs fetchpriority='high' trugen: Erst als das Attribut von ihnen entfernt und nur auf dem LCP-Bild belassen wurde, lud dieses schneller -- der LCP verbesserte sich in der Summe um fast 4 Sekunden (DebugBear).

Das high gehört also exklusiv auf das Element, das den Largest Contentful Paint bestimmt. Welches das ist, lässt sich nicht raten, sondern nur messen -- ein Labortest oder die Felddaten zeigen, welches Element auf den meisten Geräten als LCP gilt. Bei responsiven Layouts kann das je nach Bildschirmgröße variieren; hier helfen Felddaten zu erkennen, welches Bild über die große Mehrheit der Besuche hinweg das LCP-Element stellt. Wie sich Labor- und Felddaten dabei sinnvoll ergänzen, vertieft unser Beitrag zu RUM, CrUX und Performance-Budgets.

Lazy Loading ist eine der wirksamsten Techniken für Bilder unterhalb des sichtbaren Bereichs: Mit loading='lazy' lädt der Browser ein Bild erst, wenn es in die Nähe des Viewports scrollt. Bei einer Seite mit zehn Bildern, von denen nur das erste -- das LCP-Element -- im ersten Viewport sichtbar ist, kann das Lazy-Loaden der übrigen neun Bilder das Laden des ersten sogar beschleunigen (MDN), weil sie ihm keine Bandbreite mehr stehlen. Genau hier liegt aber die Falle: Das LCP-Bild selbst sollte gerade nicht lazy geladen werden.

Wird loading='lazy' versehentlich auf das Hero-Bild gesetzt -- etwa weil ein Theme oder Plugin pauschal alle Bilder lazy lädt -- verzögert das genau den Inhalt, den fetchpriority beschleunigen soll. Der Browser wartet dann, bis er weiß, ob das Bild im Viewport liegt, statt es sofort zu laden. Das LCP-Bild gehört daher eager geladen, also ohne lazy-Attribut, und zusätzlich mit fetchpriority='high' versehen. Diese Kombination ist der Standardfall: das wichtigste Bild eager und hochpriorisiert, alle übrigen lazy.

In der Praxis ist dieser eine Fehler -- das lazy geladene Hero-Bild -- einer der häufigsten Gründe für einen unnötig hohen LCP. Viele Content-Management-Systeme und Theme-Baukästen aktivieren Lazy Loading inzwischen pauschal für alle Bilder, weil es unterhalb des Folds meist hilft. Für das eine Bild im sichtbaren Bereich kehrt sich der Nutzen jedoch um. Deshalb prüfen wir bei jeder Optimierung zuerst, ob das LCP-Bild versehentlich im Lazy Loading hängt, bevor wir überhaupt über den Priority Hint nachdenken -- denn ein high-Attribut auf einem lazy geladenen Bild hebt sich gegenseitig auf.

fetchpriority und preload lösen zwei verschiedene Teilprobleme und entfalten zusammen die volle Wirkung. Das Problem der späten Entdeckung -- der Browser findet ein Bild erst spät im Markup oder weil es per CSS-Hintergrund geladen wird -- löst preload, indem es den Download früh anstößt. Das Problem der falschen Priorität löst fetchpriority. Wird ein Bild nur vorgeladen, behält es seine niedrige Standardpriorität; erst fetchpriority='high' am preload-Tag hebt sie an. Beide gehören daher zusammen, wenn das LCP-Element spät entdeckt wird, etwa als CSS-Hintergrundbild.

Bei responsiven Bildern mit srcset und sizes gehört das Attribut an das img-Element selbst, nicht an das umgebende picture-Element (DebugBear). Der Browser wählt dann zunächst anhand von srcset und sizes die passende Bildvariante aus und lädt diese mit hoher Priorität. So lässt sich das LCP-Bild gleichzeitig responsiv ausliefern und priorisieren -- die beiden Optimierungen schließen sich nicht aus. Wer das LCP-Bild zusätzlich verkleinert, etwa durch ein modernes Format, gewinnt doppelt: Ein als AVIF mit 80 Prozent Qualität gespeichertes Bild kam in einem Beispiel auf eine 95-prozentige (MDN) Ersparnis und schrumpfte von 1 MB auf 46 KB.

Der erste und folgenreichste Fehler ist das Überpriorisieren: mehrere Bilder gleichzeitig auf high zu setzen. Wie beschrieben, konkurrieren sie dann um die Bandbreite und bremsen das wirklich wichtige Bild aus. Der zweite Fehler ist das versehentliche Lazy-Loaden des LCP-Bildes, oft verursacht durch ein Theme oder Plugin, das pauschal alle Bilder lazy lädt. Der dritte Fehler ist, das Attribut auf das falsche Element zu setzen -- nicht jedes Hero-Bild ist auf jedem Gerät das LCP-Element, und ohne Messung trifft man hier leicht daneben.

Der vierte Fehler ist, fetchpriority isoliert zu betrachten. Der Hint beschleunigt den Moment, in dem der Browser das Bild lädt -- er ersetzt aber nicht die übrigen Bausteine eines schnellen LCP. Eine langsame Serverantwort verzögert jede Ressource gleichermaßen, wie unser Beitrag zur TTFB-Optimierung zeigt. Ein zu großes, unkomprimiertes Bild lädt auch mit hoher Priorität langsam. Und ein Layout, das nach dem Bildladen noch verspringt, drückt zwar nicht den LCP, aber die Stabilität, die wir im Beitrag zum Visual Stability Index als CLS-Nachfolger behandeln. Der Priority Hint ist ein Baustein, kein Ersatz für das Gesamtbild.

Der große Vorteil von fetchpriority ist, dass es rein deklarativ im Markup steht. Es braucht keine neue Infrastruktur, keinen zusätzlichen Build-Schritt und keine Server-Konfiguration -- ein Attribut auf einem Element genügt. Damit gehört der Priority Hint zu den günstigsten Maßnahmen, um den Largest Contentful Paint zu verbessern, und zugleich zu denen mit dem besten Verhältnis von Aufwand zu Wirkung. In unserer Frontend-Optimierung ist er meist einer der ersten Handgriffe, sobald wir das LCP-Element zweifelsfrei identifiziert haben.