A böngésző a HTML feldolgozása közben maga osztja el, melyik hálózati kérés mennyire sürgős. Ez többnyire jól működik, de a nyitóképnél könnyű félrevezetni: a kép csak kliensoldali render után jelenik meg, CSS-háttérként bújik meg, vagy egyszerűen versenyzik egy rakás korán felfedezett erőforrással. Ilyenkor az HTML fetchpriority attribútuma adhat egy szűk, célzott jelzést a böngészőnek.
Nem a letöltési sebességet növeli, és nem írja felül a böngésző döntését. A high, low és auto értékek csak prioritási hintek: azt mondják, hogy az adott kérés a többihez képest fontosabb vagy kevésbé fontos. A HTML szabvány ezért szándékosan nem garantál sorrendet. Pont ez a jó mentális modell: ne globális teljesítménykapcsolónak, hanem a böngésző becslésének ritka korrekciójára tekintsünk rá.
Az egy kép, amely valóban előrébb kerülhet
A legjobb jelölt általában az első nézetben lévő tartalmi kép, amelyből a Largest Contentful Paint (LCP) lesz. Egy termékoldal nagy fotója vagy egy cikk valódi hero illusztrációja ilyen lehet. Ha a böngésző az <img>-et már a kezdeti HTML-ben megtalálja, elég lehet közvetlenül erre tenni az attribútumot:
<img
src="/images/termek-1440.webp"
srcset="/images/termek-768.webp 768w, /images/termek-1440.webp 1440w"
sizes="(max-width: 768px) 100vw, 1440px"
width="1440"
height="810"
fetchpriority="high"
alt="Az alkalmazás fő funkcióját bemutató képernyőkép">A width és height itt nem dísz: a böngésző ebből tudja előre lefoglalni a helyet, így a kép betöltése nem okoz elrendezés-ugrást. A reszponzív srcset maradjon meg; a prioritás nem indok arra, hogy minden kijelzőre a legnagyobb fájlt küldjük. Az <img> fetchPriority tulajdonsága JavaScriptből is állítható, de az LCP esetében ez rendszerint késő: a parser által rögtön látott HTML gyorsabb jelzés.
Józan szűrő, hogy egy átlagos oldalnak többnyire egyetlen high képe van. A fejlécben lévő logó általában kicsi, a carousel második diáját pedig a felhasználó még nem látja; egyik sem előzheti meg automatikusan a fő tartalmat. A Network panelben ellenőrizhető, mikor indul a kérés és milyen prioritást kap. Ha a kép már korán indul és mégis késő az LCP, valószínűleg nem az ütemezés, hanem a túl nagy fájl, a szerverválasz vagy a renderelés a gond.
Mikor kevés az <img>?
Ha a kép csak későn derül ki — például a kliensoldali alkalmazás indítja el, vagy CSS background-image-ként érkezik —, a prioritás nem pótolja a felfedezés késlekedését. Itt jön szóba az as="image" preload. Az alábbi minta ugyanazt a reszponzív választási logikát adja a preloadnak, mint később az <img>-nek; így nem egy második, rossz méretű képet töltetünk le.
<link rel="preload" as="image"
href="/images/termek-1440.webp"
imagesrcset="/images/termek-768.webp 768w, /images/termek-1440.webp 1440w"
imagesizes="(max-width: 768px) 100vw, 1440px"
fetchpriority="high">A preload csak az egyértelműen kritikus képre való. A web.dev útmutatója is arra figyelmeztet, hogy a túl sok magas prioritás önmagát oltja ki: ugyanazért a véges hálózati kapacitásért versenyeztetjük a dokumentumot, a CSS-t, a betűkészleteket és a képeket. A több high nem „még gyorsabb”, hanem csak kevésbé informatív ütemezési jel.
Három gyakori félreértés
- Nem a
loading="lazy"ellenszere. A kezdeti nézet LCP-képét eleve ne lazy-loadold. Ahighnem teszi korán felfedezhetővé azt, amit a lusta betöltés későbbre halaszt. - Nem mérés helyett való. Előbb azonosítsd a valós LCP-elemet a valós felhasználói adatokból vagy a DevTools Performance/Lighthouse futásból. A LCP optimalizálási útmutató külön kezeli a felfedezést, a letöltést és a renderelést; a
fetchprioritycsak a középső problémát érinti. - A
lowis hasznos lehet. Egy kezdőképernyő alatti carousel-kép vagy nem sürgős script kaphat alacsony prioritást. Ezt is óvatosan mérd: a láthatóvá válás időpontja, a hálózati kapcsolat és a böngésző saját heurisztikája számít.
Egy rövid ellenőrzőlista
Először tedd a valódi LCP-képet a kezdeti HTML-be, adj neki korrekt méretet és reszponzív forrásokat. Ezután próbáld ki rajta az fetchpriority="high"-t. Preloadot csak akkor adj hozzá, ha a Network waterfall azt mutatja, hogy a böngésző későn fedezi fel. Végül hasonlítsd össze a módosítás előtti és utáni LCP-t valódi eszközökről is. Ha nincs mérhető javulás, vedd ki: a jó teljesítményoptimalizálás nem attribútumgyűjtemény, hanem a szűk keresztmetszet felszámolása.