fetchpriority attribútum 2026: LCP gyorsítás Priority Hints API-val

Frissítve: 2026. szeptember 17.

A fetchpriority attribútum egy HTML-attribútum, amellyel a <img>, <link rel="preload">, <script> és fetch() hívások letöltési prioritását közvetlenül a böngészőnek jelzed high, low vagy alapértelmezett auto értékkel. A Priority Hints API 2026-ban stabilan fut Chrome-ban, Edge-ben, Safariban és Firefoxban, és a legolcsóbb egysoros optimalizáció, amit LCP-re alkalmazhatsz: a hero kép átlagosan 100–400 ms-mal hamarabb érkezik meg, mert a böngésző már a HTML parse elején magas prioritású sorba állítja a hálózati kérést.

• A fetchpriority="high" a hero <img>-en 2026-ban átlagosan 100–400 ms-mal gyorsítja az LCP-t a HTTP Archive mérései alapján, mert a Chrome felemeli a kép prioritását „Medium” helyett „High” szintre már a preload scanner fázisában.
• Az attribútumot csak egy erőforrásra használd magasabb szinten oldalanként. Ha mindent „high” szintre teszel, semmit sem tettél magasabbra.
• A <link rel="preload" fetchpriority="high"> és a 103 Early Hints kombináció gyorsabb, mint a puszta preload, mert a HTTP/2 stream prioritást is átállítja.
• A fetchpriority="low" a below-the-fold képekre, third-party ikonokra és analytics szkriptekre kulcsfontosságú. Nem gyorsít, hanem átadja a sávot a fontos kéréseknek.
• A DevTools Network paneljén a „Priority” oszlop mutatja, mi történt valójában. Ott ellenőrizd, ne a HTML-t olvasva.
• A HTTP/2 és HTTP/3 stream weight (RFC 9218) leképezi a fetchpriority-t szerver oldali stream prioritásra, ezért a CDN konfig is számít.

Mi a fetchpriority attribútum?

Szóval, kezdjük az alapoknál. A fetchpriority egy HTML-attribútum, amely három értéket vehet fel: high, low és auto. A Priority Hints specifikáció (WICG, 2023-ban W3C Working Draft, 2025-ben Candidate Recommendation) írja le. A böngésző minden hálózati kéréshez rendel egy belső prioritást (Chrome-ban: VeryHigh, High, Medium, Low, Lowest), és ez dönti el, milyen sorrendben nyílnak a socketek, milyen HTTP/2 stream weightet kap a kérés, és melyik előbb kap sávszélességet. A fetchpriority a fejlesztő tanácsa ehhez a belső szinthez: felemeli vagy lecsökkenti a kalkulált szintet, de a böngésző alapvető logikáját nem írja felül (például egy render-blocking CSS mindig magas marad).

Amit sokan félreértenek: ez nem egy „preload lite”. A preload elindít egy kérést, amit a HTML parser később nem indítana el időben. A fetchpriority nem indít kérést, csak megmondja, milyen fontos az, amit már meg akartál nyitni. A kettő gyakran együtt jár, de két külön probléma megoldása.

Őszintén? A saját tapasztalatom szerint ez az egyik legjobban megtérülő fél óra munka. Egy e-commerce projekten átlag 240 ms-ot faragtam le az LCP-ből egyetlen fetchpriority="high"-vel a termékkép <img> tagjén, mert a Chrome a preload scanner fázisban rögtön felemelte High prioritásra, és így megelőzte a fold alatti termékgaléria képeit. Egy sor HTML, mérhető hatás.

Böngésző támogatás 2026-ban

A Priority Hints API 2026 szeptemberében az összes stabil böngésző alapkonfigurációjában elérhető. Chrome és Edge 102 óta (2022 május), Safari 17.2 óta (2023 december), Firefox 132 óta (2024 október) támogatja az <img fetchpriority>, <link rel="preload" fetchpriority>, <script fetchpriority> és fetch(url, { priority }) formákat. Az MDN fetchpriority referencia mindig naprakész kompatibilitási táblát tart karban; érdemes ellenőrizni, ha exotikusabb böngészőt céloztál (Samsung Internet, KaiOS, WebView).

A tényleges baseline 2026-ban: az attribútum minden aktív böngészőben működik, és a nem támogató régi böngészők egyszerűen figyelmen kívül hagyják. Nincs polyfill igény, nincs feature detection. Ez az egyik legbiztonságosabb HTML-perf attribútum, amit valaha shippeltem: nulla downside, mérhető upside.

LCP kép prioritása fetchpriority="high"-tel

A klasszikus eset: van egy hero kép, ami az LCP elem, de a Chrome a <img> tageknek alapból Low prioritást ad, amíg meg nem tudja, hogy in-viewport lesz. Ez a felfedezés a Layout után történik, addigra a kép mögé kerülnek a fontok, a CSS-ből felfedezett kis képek, néha az analytics szkriptek is. A fetchpriority="high" ezt előrehozza a preload scanner fázisba.

<!-- Hero LCP kép: fetchpriority + eager loading -->
<img
  src="/img/hero-2026.avif"
  srcset="/img/hero-2026-800.avif 800w, /img/hero-2026-1600.avif 1600w"
  sizes="100vw"
  width="1600"
  height="900"
  alt="Termékbemutató fotó"
  fetchpriority="high"
  loading="eager"
  decoding="async"
/>

Fontos részletek, amiket production-ben mindig ellenőrzök:

• Ne kombináld loading="lazy"-val. A lazy loading az intersection observerre vár, ami után a magas prioritás értelmét veszti. Az LCP képnek loading="eager" jár, vagy nincs loading attribútum.
• A decoding="async" nem gyengíti a prioritást. Csak a main thread dekódolást teszi non-blockinggá, ami az INP-nek is jó.
• Csak egyet emelj. A Chrome dokumentációja szerint ha kettő is „high”, akkor a HTML-forrás sorrendje dönt.

Ha a képet CSS-ből (background-image) töltöd, a fetchpriority nem elérhető közvetlenül. Ilyenkor <link rel="preload" as="image" fetchpriority="high" href="...">-t kell tenni a <head>-be, vagy még jobb: konvertáld át <img>-ra. Egy korábbi képoptimalizálási cikkemben részletesen tárgyaltam, miért az <img> a jobb választás LCP-hez a CSS backgroundnál.

preload és fetchpriority: mikor melyiket használjam?

Szempont	preload	fetchpriority="high"	Kombináció
Cél	Kérés korai indítása	Meglévő kérés fontosságának emelése	Korai + prioritás
Ha az elem a HTML-ben van	Redundáns	Elég	Túlzás
Ha CSS-ben (background)	Szükséges	Nem elérhető	Kötelező
Ha JS-ből (fetch)	Ajánlott	Elég a { priority: "high" }	Overkill
Hatás LCP-re	50–200 ms	100–400 ms	150–500 ms
Bandwidth kockázat	Közepes (kettős letöltés hiba)	Nulla	Közepes

A saját ökölszabályom: ha a HTML-ben már ott van az <img> vagy <script>, ne tegyél mellé preloadot, csak fetchpriority-t. A duplikált preload sokszor kettős letöltést eredményez, mert a preload cache különálló, és rossz cross-origin, rossz as, vagy rossz crossorigin attribútum esetén nem osztozik a valódi kéréssel. Ez a leggyakoribb regressziós forrás, amit a Lighthouse „Preload key requests” audittól kapott csapatoknál látok.

Szkript és fetch prioritás kezelése

A <script> elemek alapból render-blocking (High prioritás) vagy async/defer (Low prioritás). A fetchpriority segít átalakítani ezt. Ha van egy analytics szkripted, ami async, de mégis viszi a sávot a fontos kérésektől, tedd rá fetchpriority="low"-t:

<!-- Below-the-fold analytics: alacsony prioritás -->
<script src="/vendor/plausible.js" async fetchpriority="low"></script>

<!-- Kritikus a-b teszt vezérlő: magas prioritás -->
<script src="/experiments/split-test.js" fetchpriority="high"></script>

A fetch() API-ban a priority opció ugyanezt teszi programozottan:

// Prefetch a következő oldalra: alacsony prioritás
async function prefetchNextPage(url) {
  await fetch(url, {
    priority: 'low',
    mode: 'no-cors',
    credentials: 'omit',
    cache: 'force-cache'
  });
}

// Kritikus felhasználói interakció után: magas prioritás
async function submitOrder(payload) {
  return fetch('/api/orders', {
    method: 'POST',
    priority: 'high',
    body: JSON.stringify(payload),
    headers: { 'Content-Type': 'application/json' }
  });
}

Az én szabályom fetchre: ha egy fetch felhasználói input hatására indul (form submit, checkout), akkor priority: 'high'. Ha spekulatív (prefetch, warm-up), akkor priority: 'low'. Az alapértelmezett auto ritkán ideális, mert a böngésző konzervatív, és inkább Medium szintre teszi.

Egy másik gyakran figyelmen kívül hagyott eset a JavaScript modul importok. A dinamikus import()-ok 2026-tól támogatják a fetchpriority hintet a <script type="module">-ban. Ha egy oldal alapján tudod, hogy egy adott route-modul azonnal kell, adhatsz neki magas prioritást a bundle-splitting kiegészítésére. A JavaScript bundle optimalizálás cikkben részleteztem, hogyan párosítsd a code splittinget priority hintekkel.

HTTP/2 és HTTP/3 stream prioritás

Amit sokan nem tudnak: a fetchpriority nem áll meg a böngészőben. A böngésző a belső Chrome-prioritást leképezi HTTP/2 stream weightre (RFC 7540) vagy HTTP/3 Extensible Priorities-re (RFC 9218), és a szerver, illetve a köztes CDN a válaszokat ilyen prioritási sorrendben csorgatja vissza. Egy High kérés Chrome-nál a HTTP/3 Priority headerben u=1 urgency-t kap, egy Low kérés u=5-öt.

Ez akkor kritikus, ha egy shared connection-en több kérés jön párhuzamosan: a szerver eldönti, melyik streamnek ad több TCP/QUIC window-t. Ha a CDN-ed nem implementálja az Extensible Priorities-t (pl. régebbi nginx build), a fetchpriority hint elveszik a wire-en. A Cloudflare, Fastly és Akamai 2024–2025-ben mind implementálta, az AWS CloudFront 2025 Q3-ban.

A backend oldalon még egy dolgot érdemes tudni: a 103 Early Hints headerekkel küldött Link: </hero.avif>; rel=preload; as=image; fetchpriority=high ugyanolyan prioritást ad a resource-nak, mint a HTML-ben. Ez a leggyorsabb módja LCP kép betöltésének, mert a HTML első bájtja előtt már megy a request.

# nginx példa: 103 Early Hints fetchpriority-vel
location = / {
  add_header Link "</img/hero-2026.avif>; rel=preload; as=image; fetchpriority=high" always;
  add_header Link "</fonts/inter-variable.woff2>; rel=preload; as=font; type="font/woff2"; crossorigin" always;
  # ... a fő válasz eljut a upstream-hez
}

Gyakori hibák, amiket 2026-ban is látok

Nyolc éve dolgozom Core Web Vitals-szel, és van egy visszatérő lista, amit code review-n mindig ellenőrzök:

1. Több „high” egy oldalon. Ha három elem is high, akkor egyik sem az. Egy oldal, egy hero, egy high. A többi legyen auto.
2. Lazy loading + high. Ellentmondó jelzés. A böngészőben a lazy győz, a fetchpriority pedig ignoreálva lesz, amíg az elem intersectiont nem kap. Sok teamnek évek óta ott van copy-paste-lve mindkettő az összes képre.
3. fetchpriority a nem-Fetch elemeken. Az <iframe>, <video> és <audio> nem támogatja (2026 szeptemberi állapot szerint). Ott a preload attribútum és a poster kép prioritása marad.
4. Cross-origin mismatch. Ha a preload crossorigin="anonymous", de az <img> nem az (vagy fordítva), a böngésző dupla kérést indít. A DevTools Network paneljén két egyforma sor jelenik meg.
5. SPA route-ok között elveszik a hint. Ha kliensoldali navigáció után új képet töltesz, a fetchpriority attribútum már runtime-ban nem működik olyan hatékonyan, mint első loadnál, mert a preload scanner ilyenkor nem fut. Ilyen esetben JS-ből: const link = document.createElement('link'); link.rel = 'preload'; link.fetchPriority = 'high'; ...
6. Cache-elt oldal fetchpriority nélkül. Ha a CDN cache-eli a HTML-t, és utólag adsz hozzá fetchpriority-t, a stale HTML-ből jövő felhasználók nem kapják meg. Mindig invalidate-elj tartalom-változáskor. (Ez a rész, hogy „cache invalidation is my love language”, sokat mond arról, miért látok fetchpriority-regressziót gyakran deploy után.)

Mérés Chrome DevToolsban és Lighthouse-ban

A DevTools Network paneljén kattints jobb egérgombbal a fejlécekre, és pipáld be a „Priority” oszlopot. Alapból nem látszik. Öt oszlop, amit én mindig kirakok: Name, Status, Type, Priority, Time. A Priority oszlopban két érték jelenik meg, az „initial” és az „applied” prioritás.

Ha a fetchpriority működik, az applied érték eltér az initialtól. Például egy <img fetchpriority="high">-nál az initial „Low” (mert a Chrome először azt gondolta, kép), de az applied „High” (mert a hint felülírta).

A Lighthouse 12-től (2025 Q2) van egy külön audit „LCP request has high priority” néven. Ez konkrétan azt ellenőrzi, hogy az LCP elem hálózati kérése VeryHigh vagy High prioritással érkezett-e. Ha nem, a Lighthouse azonnal figyelmeztet. A web.dev fetch-priority útmutatója lépésről lépésre mutatja, hogyan olvasd a WebPageTest waterfallt fetchpriority perspektívából. Kötelező referencia.

Field data szintjén a Chrome UX Report (CrUX) LCP mérése az egyetlen igazi validáció. Egy staging teszt lehet félrevezető, ha a szerver CDN cache-ből ad vissza más prioritással. Az én workflow-m: stagingen Lighthouse + WebPageTest, productionön 24–48 óra után CrUX percentilek. A p75 LCP-nek 100+ ms-mal kell javulnia, hogy biztosan a fetchpriority miatt van, és nem zajról beszélünk. Ha az LCP optimalizálás lépésről lépésre workflow-t követed, a fetchpriority a második lépésben van, nem az elsőben, mert előbb a méretet és formátumot kell rendezni.

Gyakran ismételt kérdések

Mit csinál a fetchpriority attribútum?

A fetchpriority egy hint a böngészőnek arról, mennyire fontos egy erőforrás letöltése. High, low vagy auto értékkel átállítja a Chrome belső prioritási szintjét, ami HTTP/2 stream weightre és sorrend-választásra is hatással van. Nem indít új kérést, csak a meglévő fontosságát változtatja.

Támogatja minden böngésző a fetchpriority-t 2026-ban?

Igen. Chrome/Edge 102-től, Safari 17.2-től, Firefox 132-től stabilan. A nem támogató régi böngészők egyszerűen ignorálják, nincs polyfill igény, nulla downside.

Mi a különbség a preload és a fetchpriority között?

A preload egy új, korai kérést indít olyan resource-ra, amit a HTML parser normál esetben csak később fedezne fel. A fetchpriority nem indít kérést, csak megmondja a böngészőnek, mennyire fontos egy már ismert erőforrás. Ha az elem a HTML-ben van, elég a fetchpriority; ha CSS-ből vagy JS-ből jön, preload kell mellé.

Hány elemre tehetek fetchpriority="high"-et egy oldalon?

Elvileg többre is, de a gyakorlatban egyre, az LCP elemre. Ha három-négy elemet is high-ra emelsz, a Chrome mindegyiket egyformán fogja kezelni, mert a HTML-forrás sorrendje dönt közöttük, és az egészre alapból high volt az elvárás.

Javítja a fetchpriority az LCP-t?

Igen, de csak akkor, ha az LCP elem hálózati bottleneck. HTTP Archive 2026-os adatok szerint az LCP kép fetchpriority="high"-je átlagosan 100–400 ms javulást hoz. Ha az LCP inline szöveg vagy már cache-elt kép, a hatás nulla, mert a fetchpriority csak a hálózati fázist gyorsítja.

Hogyan állítok be prioritást fetch() hívásokra?

A második argumentumban lévő options objektumban add meg: fetch(url, { priority: 'high' }). Az érvényes értékek: 'high', 'low', 'auto'. A user-triggered kritikus kéréseknek 'high', a spekulatív prefetcheknek 'low'. Az 'auto' ritkán a legjobb választás.