fetchpriority Guide: LCP-Boost (2026)

Q: Was ist der Unterschied zwischen preload und fetchpriority?

preload teilt dem Browser mit, dass eine Ressource überhaupt existiert und früh geladen werden soll – es entdeckt die Ressource. fetchpriority hingegen weist eine Priorität zu (high/low/auto). Beide sind ergänzend: <link rel="preload" as="image" fetchpriority="high"> nutzt sowohl frühe Entdeckung als auch hohe Priorität.

Q: Kann ich fetchpriority auf mehreren Bildern gleichzeitig setzen?

Technisch ja, aber es hebt sich auf. Wenn drei Bilder fetchpriority="high" haben, teilt Chrome die Bandbreite unter ihnen auf – kein einzelnes wird schneller. Regel: Ein High pro Seite (das LCP-Element). Below-the-fold-Bilder bekommen fetchpriority="low" plus loading="lazy" .

Q: Sollte ich fetchpriority auf jedem Bild setzen?

Nein. Bilder ohne Attribut nutzen die auto -Heuristik von Chrome – für die meisten Fälle völlig ausreichend. Priority Hints gehören nur auf Ressourcen, bei denen Sie mehr wissen als der Browser: das LCP-Bild (high) und explizit unwichtige Assets wie Analytics-Scripts oder Below-the-fold-Iframes (low).

Aktualisiert: 28. Juli 2026

Priority Hints sind ein HTML-Mechanismus, mit dem Sie dem Browser per fetchpriority-Attribut mitteilen, welche Ressourcen kritisch für die erste Darstellung sind und welche warten dürfen. Konkret setzen Sie fetchpriority="high" auf Ihr LCP-Bild und fetchpriority="low" auf verzögerbare Assets wie Below-the-fold-Bilder oder nicht-kritische Skripte – Chrome, Edge, Safari 17.2+ und Firefox 132+ interpretieren diesen Hinweis und ordnen die Netzwerk-Warteschlange entsprechend um. In produktiven Rollouts habe ich damit LCP-Verbesserungen von 200–700 ms auf Produktseiten gesehen, ohne eine einzige Zeile Backend-Code anzufassen.

fetchpriority ist ein HTML-Attribut mit drei Werten (high, low, auto) und wird auf <img>, <link>, <script> und <iframe> unterstützt.
Chrome 101+, Edge 101+, Safari 17.2+ und Firefox 132+ berücksichtigen Priority Hints; ältere Browser ignorieren das Attribut folgenlos.
Der wichtigste Use Case ist die LCP-Bild-Priorisierung: <img fetchpriority="high" src="hero.avif"> reduziert die LCP-Zeit typischerweise um 150–500 ms.
fetchpriority="low" auf Analytics-Skripten und Below-the-fold-Iframes gibt dem kritischen Pfad Bandbreite zurück.
Priority Hints ersetzen <link rel="preload"> nicht, sondern ergänzen es – die Kombination liefert die stabilsten LCP-Gewinne.
Falsch gesetzte hohe Prioritäten schaden mehr als sie nutzen: Nur eine Ressource pro Seite sollte high sein.

Was sind Priority Hints und wie funktioniert fetchpriority?

Priority Hints sind ein Standard, der das Attribut fetchpriority zu <img>, <link>, <script> und <iframe> hinzufügt, damit Autoren dem Browser Ressourcen-Prioritäten deklarativ mitteilen können. Vor Priority Hints entschied ausschließlich der Browser über die interne Priorität – Chrome nutzt ein Schema mit fünf Stufen (VeryLow, Low, Medium, High, VeryHigh), das auf Heuristiken basiert: <script>-Tags im <head> bekommen High, spät geladene Bilder Low, CSS Very High. Diese Heuristik funktioniert gut, aber sie kennt Ihr Layout nicht: Sie weiß nicht, dass das dritte Bild im HTML das Hero-Bild ist und dass das fünfte Skript ein CMP-Consent-Banner ist, das über der Hero-Grafik liegt.

Genau hier greift fetchpriority ein. Die drei zulässigen Werte lauten:

high – Der Browser stellt die Ressource in eine höhere interne Prioritätsklasse und lädt sie früher.
low – Die Ressource wird auf eine niedrigere Klasse degradiert und wartet, bis kritische Assets fertig sind.
auto – Standardverhalten; der Browser entscheidet wie bisher.

Wichtig: Der Browser respektiert den Hinweis, ist aber nicht daran gebunden. HTTP/2- und HTTP/3-Server können die Priorität außerdem für Stream-Multiplexing verwenden. Der ausführliche Mechanismus ist in der WHATWG-Spezifikation für fetch-priority-Attribute definiert.

Wie verbessert fetchpriority den LCP-Wert?

Der Largest Contentful Paint (LCP) misst, wann das größte sichtbare Element im Viewport gerendert wird – bei den meisten E-Commerce- und Content-Sites ist das ein Hero-Bild. Ohne Priority Hint startet Chrome den Download eines <img>-Tags mit interner Priorität "Low", weil der Preload Scanner nicht weiß, ob das Bild über oder unter der Falzlinie liegt. Erst wenn der Layout-Pass läuft (nach CSS-Verarbeitung), promoviert Chrome das Bild auf "High" – und verliert dabei den frühen Download-Slot. Diese Verzögerung fällt besonders auf langsamen 3G/4G-Verbindungen ins Gewicht und ist der häufigste Grund für "guter LCP im Lab, schlechter LCP im Feld".

Mit fetchpriority="high" auf dem Hero-<img> startet der Download sofort mit High Priority – parallel zu CSS, ohne auf den Layout-Pass zu warten. In einer Studie des Chrome-Teams verbesserte die Priorisierung des LCP-Bildes den 75. Perzentil-LCP um ~10 % im Chrome UX Report (CrUX). In meiner E-Commerce-Praxis waren die absoluten Zahlen deutlicher: Auf einer Produktdetailseite mit einem 240 KB großen Hero-AVIF sank der Feld-LCP nach Rollout von 3,1 s auf 2,4 s. Das schob die gesamte Origin über die 2,5-s-Schwelle für "Good".

Der Effekt wird verstärkt, wenn Sie Priority Hints mit anderen LCP-Techniken kombinieren: dedizierte <link rel="preload">-Tags, moderne Bildformate wie AVIF sowie ein Bildoptimierungs-Setup mit Responsive Images. Wichtige Warnung: Setzen Sie high immer nur auf ein LCP-Kandidat pro Seite. Mehrere gleichzeitige High-Bilder verwässern den Effekt und können sogar die Time to First Byte-Wahrnehmung verschlechtern, weil der Browser die Bandbreite auf sie aufteilt.

fetchpriority="high" für Hero-Bilder: Das Rezept

So sieht das Minimalrezept für ein priorisiertes Hero-Bild aus – inklusive Loading-Attribut, responsive Sources und dimensionierten Boxen zur CLS-Vermeidung:

<!-- Hero-Bild im Above-the-fold-Bereich -->
<img
  src="/img/hero-1200.avif"
  srcset="
    /img/hero-800.avif   800w,
    /img/hero-1200.avif 1200w,
    /img/hero-1600.avif 1600w"
  sizes="(min-width: 1024px) 1200px, 100vw"
  width="1200"
  height="600"
  alt="Produktkategorie: Sommerkollektion"
  fetchpriority="high"
  decoding="async"
>

Drei Details verdienen Beachtung:

Kein loading="lazy" auf dem LCP-Bild. Lazy-Loading verzögert den Download, bis das Element sichtbar wird – für Above-the-fold-Content das falsche Signal. In früheren Chrome-Versionen wurde loading="lazy" zusammen mit fetchpriority="high" als Bug behandelt; heute gewinnt fetchpriority, aber besser gar nicht erst kombinieren.
Explizite width und height reservieren den Layout-Space und verhindern Cumulative Layout Shift. Ohne diese Attribute macht der schnellere Download den CLS-Wert kaputt statt den LCP zu retten.
decoding="async" erlaubt dem Browser, das Bild parallel zur Haupt-Thread-Arbeit zu dekodieren. Bei großen AVIFs auf schwachen Mobil-CPUs macht das nochmal 50–150 ms aus.

Wenn Sie ein <picture>-Element für Art Direction verwenden, gehört fetchpriority auf das innere <img>, nicht auf die <source>-Tags:

<picture>
  <source
    media="(min-width: 1024px)"
    srcset="/img/hero-desktop.avif"
    type="image/avif">
  <source
    srcset="/img/hero-mobile.avif"
    type="image/avif">
  <img
    src="/img/hero-fallback.jpg"
    width="1200"
    height="600"
    alt="Sommerkollektion"
    fetchpriority="high"
    decoding="async">
</picture>

Priority Hints mit preload kombinieren

fetchpriority ersetzt <link rel="preload"> nicht – die zwei Mechanismen adressieren unterschiedliche Probleme. Preload teilt dem Preload Scanner mit, dass eine Ressource überhaupt existiert, bevor der Parser sie erreicht (relevant für Ressourcen, die aus JavaScript oder CSS geladen werden). Priority Hint teilt dem Netzwerkstack mit, wie wichtig diese Ressource ist. Beide zusammen sind der Goldstandard für kritische Assets.

Beispiel: Ein Hero-Bild, dessen Pfad erst nach der JavaScript-Auswertung feststeht (z. B. bei einer React-Shell), profitiert von der Kombination:

<!-- Im <head> -->
<link
  rel="preload"
  as="image"
  href="/img/hero-1200.avif"
  imagesrcset="
    /img/hero-800.avif   800w,
    /img/hero-1200.avif 1200w"
  imagesizes="(min-width: 1024px) 1200px, 100vw"
  type="image/avif"
  fetchpriority="high">

Wichtig: preload auf Bildern erzeugt einen zweiten Netzwerk-Request, wenn der später gerenderte <img>-Tag nicht exakt dieselbe URL, Sizes und Type-Signatur verwendet. Prüfen Sie im DevTools-Network-Panel unbedingt, ob das Bild nur einmal geladen wird. Googles Priority-Hints-Guide auf web.dev dokumentiert die häufigsten Preload-Duplikate-Fallen.

Für Web Fonts sieht die Kombination ähnlich aus – Preload plus High Priority verhindert FOIT/FOUT-Sprünge. Details dazu finden Sie in unserem Leitfaden zu Web-Font-Performance.

Priority Hints für fetch(), Skripte und Iframes

Über Bilder hinaus unterstützen weitere Ressourcentypen fetchpriority:

Skripte

Skripte im <head> haben Standard-Priorität "High" – aber die Reihenfolge im HTML entscheidet über die Ausführung. Mit fetchpriority="high" kann ein späteres Skript im Dokument früher heruntergeladen werden, ohne dass Sie es im HTML verschieben müssen:

<!-- Kritisches Skript, aber im Body, weil es auf DOM-Elemente zugreift -->
<script
  src="/js/checkout-form.js"
  defer
  fetchpriority="high"></script>

fetch()-Requests

Die fetch()-API akzeptiert die priority-Option. Beispiel: Ein Ratings-Widget, das erst nach dem LCP-Rendering laden soll:

// Nicht-kritische Bewertungen als Low-Priority laden
async function ladeBewertungen(produktId) {
  const response = await fetch(`/api/reviews/${produktId}`, {
    priority: 'low',
  });
  return response.json();
}

// Kritisches Preis-Update mit High-Priority
async function ladePreis(produktId) {
  const response = await fetch(`/api/price/${produktId}`, {
    priority: 'high',
  });
  return response.json();
}

Iframes

Below-the-fold-Iframes wie eingebettete YouTube-Player oder Kartenwidgets sollten immer fetchpriority="low" und loading="lazy" haben:

<iframe
  src="https://www.youtube.com/embed/VIDEO_ID"
  width="560"
  height="315"
  loading="lazy"
  fetchpriority="low"
  title="Produktvideo"></iframe>

Third-Party-Skripte mit fetchpriority="low" entlasten

Bei jedem Perf-Audit den ich für unseren Shop mache, ist der größte einzelne LCP-Killer nicht das Hero-Bild – es sind Third-Party-Skripte, die sich mit dem Hero-Bild um die Bandbreite streiten. Ein typischer Sünder-Stack: Google Tag Manager (60 KB), zwei Analytics-Skripte (je 40 KB), ein Consent-Manager (25 KB), ein Live-Chat-Widget (80 KB) und ein A/B-Testing-Container (35 KB). Zusammen 280 KB an nicht-visueller JavaScript-Fracht, die in Chrome standardmäßig High Priority bekommt – parallel zum LCP-Bild-Download.

Der schnellste Hebel: fetchpriority="low" auf alle Third-Party-<script>-Tags im <head>, sobald deren Loader nicht render-blockierend eingebunden ist:

<!-- Google Tag Manager als Low-Priority -->
<script
  src="https://www.googletagmanager.com/gtm.js?id=GTM-XXXX"
  async
  fetchpriority="low"></script>

<!-- Consent Management Platform -->
<script
  src="https://cdn.cmp.example.com/loader.js"
  async
  fetchpriority="low"></script>

<!-- Live-Chat -->
<script
  src="https://widget.intercom.io/widget/APP_ID"
  async
  fetchpriority="low"
  defer></script>

Die Ausnahme: Consent-Manager-Skripte, die vor jedem anderen Tracking laufen müssen (Google Consent Mode), brauchen ihre normale Priorität. Für diese Fälle habe ich gute Erfahrungen mit einem Zwei-Phasen-Loader gemacht – der eigentliche CMP-Loader läuft mit auto, aber das nachgelagerte Analytics- und Retargeting-Netz bekommt low. Wenn Sie tiefer in die Third-Party-Kontrolle gehen wollen, lohnt sich unser Deep Dive zu Third-Party-Scripts optimieren, wo ich Partytown, Facades und Delayed Loading vergleiche.

Chrome DevTools: Prioritäten sichtbar machen

Ehrlich gesagt: Ich habe früher fetchpriority-Attribute nach Bauchgefühl gesetzt und mich gewundert, warum sich der LCP kaum bewegt hat. Bevor Sie also irgendein Attribut vergeben, sollten Sie die aktuellen Prioritäten Ihrer Seite kennen. In Chrome DevTools:

Öffnen Sie DevTools (F12) und wechseln Sie zum Network-Tab.
Klicken Sie mit rechts auf die Spaltenüberschriften und aktivieren Sie Priority.
Laden Sie die Seite neu (Strg+R / Cmd+R).
Sortieren Sie nach der Priority-Spalte. Sie sehen Werte wie "Highest", "High", "Medium", "Low", "Lowest".

Der zweite Trick ist die Big Requests-Filterung: In der URL-Filterleiste können Sie priority:High larger-than:100k eingeben, um alle High-Priority-Requests über 100 KB zu isolieren. Alles, was hier auftaucht und nicht LCP-relevant ist, ist ein Kandidat für fetchpriority="low".

Im Performance-Tab (früher "Timings") sehen Sie zusätzlich die "Priority Boost"-Marker, wenn Chrome während des Layout-Passes ein Bild vom Low- auf High-Level hochstuft. Jeder solche Boost ist ein möglicher fetchpriority="high"-Kandidat, weil Sie den Boost vor den Layout-Pass verlegen können. Für Feld-Messungen ergänzt der offizielle Chrome-DevRel-Beitrag zu Fetch Priority die Lab-Perspektive um CrUX-Daten.

Browser-Support und Fallback-Strategie

Priority Hints haben mittlerweile robusten Browser-Support:

Browser	Unterstützung seit	fetchpriority auf img	fetchpriority auf link/preload	priority-Option in fetch()
Chrome / Edge	101 (April 2022)	Ja	Ja	Ja
Safari	17.2 (Dezember 2023)	Ja	Ja	Ja
Firefox	132 (Oktober 2024)	Ja	Ja	Ja
Samsung Internet	19+ (2023)	Ja	Ja	Ja

Für 2026 bedeutet das: Über 96 % des globalen Traffics unterstützen Priority Hints laut CrUX. Legacy-Browser (Safari < 17.2, Firefox < 132, IE11) ignorieren das Attribut ohne Fehler – es gibt keinen Grund für Feature Detection oder Polyfills. Sie können Priority Hints heute bedenkenlos in Produktion einsetzen; die schlimmste Wirkung in einem alten Browser ist "wie vorher, ohne Vorteil".

Ergänzend zu Priority Hints lohnt sich ein Blick auf die Speculation Rules API für Prerender und Prefetch – zusammen ergeben beide Mechanismen ein umfassendes Priorisierungs-Toolset für den kritischen Rendering-Pfad.

Häufige Fehler bei Priority Hints

Aus meinen letzten fünf Perf-Reviews im Team habe ich die immer wieder gleichen Anti-Patterns gesammelt:

1. Zu viele High-Priority-Ressourcen

Wenn Sie fetchpriority="high" auf fünf Bilder, drei Skripte und die Fonts setzen, ist keine davon mehr wirklich hoch priorisiert. Regel: Maximal eine Ressource pro Seite als LCP-Kandidat plus höchstens zwei kritische Skripte oder Fonts.

2. High Priority auf Below-the-fold-Bildern

Manche CMS-Templates setzen fetchpriority="high" automatisch auf das erste Bild jedes Artikels – auch wenn das über der Falzlinie liegende Bild eigentlich das Logo im Header ist. Prüfen Sie im Chrome-Lighthouse-Report unter "LCP element", welches Element wirklich Ihr LCP ist.

3. Verwechslung mit loading="eager"

loading="eager" deaktiviert nur Lazy-Loading, es priorisiert nicht. Für ein LCP-Bild brauchen Sie fetchpriority="high" oder überhaupt kein loading-Attribut (Standard ist eager).

4. Preload ohne Match zum späteren img-Tag

Wenn Sie <link rel="preload" as="image" href="hero.jpg" fetchpriority="high"> setzen und das spätere <img> ein srcset hat, das ein anderes Bild ausliefert, laden Sie zwei Bilder statt eins – ein Netto-Verlust. Immer imagesrcset, imagesizes und type im Preload-Tag mitgeben, damit der Browser Requests deduplizieren kann.

5. Priority Hint auf render-blockierendes CSS

CSS im <head> hat bereits die höchste interne Priorität ("VeryHigh"); ein zusätzliches fetchpriority="high" hat keinen Effekt. Verschwendete Attribut-Bytes und irreführender Code.

Wenn Sie Priority Hints ernsthaft in Ihre Perf-Pipeline aufnehmen wollen, gehört eine automatisierte Regel in Ihr CI: Ein Lighthouse- oder Core Web Vitals-Audit, das prüft, ob genau ein LCP-Element fetchpriority="high" hat und dass keine Below-the-fold-Assets fälschlich hoch priorisiert wurden. Das verhindert Regressionen, wenn nächste Woche jemand aus dem Marketing-Team ein neues Hero-Karussell einbaut.

Häufig gestellte Fragen

Was ist der Unterschied zwischen preload und fetchpriority?

preload teilt dem Browser mit, dass eine Ressource überhaupt existiert und früh geladen werden soll – es entdeckt die Ressource. fetchpriority hingegen weist eine Priorität zu (high/low/auto). Beide sind ergänzend: <link rel="preload" as="image" fetchpriority="high"> nutzt sowohl frühe Entdeckung als auch hohe Priorität.

Verbessert fetchpriority den LCP-Wert wirklich messbar?

Ja. Google berichtet über eine ~10 %-Verbesserung des 75. LCP-Perzentils bei Sites, die das Attribut korrekt einsetzen. In der Praxis sehe ich 150–500 ms Feld-LCP-Reduktion, wenn fetchpriority="high" auf einem echten LCP-Bild-Kandidaten gesetzt wird und keine konkurrierenden High-Priority-Ressourcen vorhanden sind.

Kann ich fetchpriority auf mehreren Bildern gleichzeitig setzen?

Technisch ja, aber es hebt sich auf. Wenn drei Bilder fetchpriority="high" haben, teilt Chrome die Bandbreite unter ihnen auf – kein einzelnes wird schneller. Regel: Ein High pro Seite (das LCP-Element). Below-the-fold-Bilder bekommen fetchpriority="low" plus loading="lazy".

Funktioniert fetchpriority in Safari?

Ja, seit Safari 17.2 (Dezember 2023) für alle Ressourcentypen. Ältere Safari-Versionen ignorieren das Attribut folgenlos, ein Polyfill ist nicht notwendig. Im Juli 2026 unterstützen laut CrUX über 96 % des globalen Traffics Priority Hints nativ.

Sollte ich fetchpriority auf jedem Bild setzen?

Nein. Bilder ohne Attribut nutzen die auto-Heuristik von Chrome – für die meisten Fälle völlig ausreichend. Priority Hints gehören nur auf Ressourcen, bei denen Sie mehr wissen als der Browser: das LCP-Bild (high) und explizit unwichtige Assets wie Analytics-Scripts oder Below-the-fold-Iframes (low).