Preload, preconnect és fetchpriority helyes használata

Scheo · 2026-10-11 · olvasási idő ~10 perc · Szerző: Schmidt Péter

A böngésző magától is elég jól kitalálja, milyen sorrendben töltse le egy oldal fájljait. Az erőforrás-tippekkel (angolul resource hints) ebbe a sorrendbe szólhatsz bele. Ha jó helyen teszed, a fő tartalom hamarabb jelenik meg. Ha rossz helyen, a fontos fájlok a kevésbé fontosak mögött várakoznak, és az oldal lassabb lesz, mint tipp nélkül. Ez a cikk a három leggyakrabban használt eszközt veszi végig, a preloadot, a preconnectet és a fetchpriority attribútumot, majd megmutatja, hogyan ellenőrizd őket egy WordPress-oldalon.

A cikkben háromféle jelölést használunk, hogy lásd, mi mennyire biztos.

• Hivatalosan igazolt, ami a WHATWG HTML-szabványban, a böngészőgyártók vagy a Google dokumentációjában szerepel.
• Saját tapasztalat, ami oldalak mérése és javítása közben visszatérően előjön.
• Szakmai feltételezés, ami indokolt következtetés, de általánosan nincs rá bizonyíték.

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

A preload egy konkrét fájlt kér le előre, a preconnect csak a hálózati kapcsolatot építi ki egy másik szerverrel, a fetchpriority pedig nem indít új letöltést, csak a meglévő kérés fontosságát jelzi a böngészőnek.

Hivatalosan igazolt. A rel='preload' azt mondja a böngészőnek, hogy ezt a fájlt az aktuális oldalon biztosan használni fogod, ezért kezdje el letölteni, mielőtt a HTML vagy a CSS feldolgozása odáig érne. Az as attribútum kötelező, ebből tudja a böngésző, milyen típusú fájlról van szó és milyen prioritást adjon neki. A rel='preconnect' előre lefuttatja a DNS-feloldást, a TCP-kapcsolatot és a TLS-kézfogást egy másik domainnel, de fájlt nem tölt le. A fetchpriority attribútum értéke high, low vagy auto lehet, és a böngésző saját prioritási döntését tolja feljebb vagy lejjebb.

Két rokon tippet érdemes elkülöníteni. A dns-prefetch csak a domain nevét oldja fel, olcsóbb és kevésbé hatásos, mint a preconnect. A prefetch pedig a következő oldalhoz szükséges fájlt kéri le alacsony prioritással, ezért az aktuális oldal betöltését nem gyorsítja.

Mit érdemes előtölteni, és mit nem?

Azt érdemes előtölteni, amire a látható tartalomhoz rögtön szükség van, de a böngésző csak későn fedezné föl. Ez leggyakrabban az LCP-kép és a hajtás feletti szöveg betűtípusa.

Az LCP (Largest Contentful Paint) a látható terület legnagyobb eleme, sok oldalon a fejléc nagy képe. Ha ez a kép egy sima img tagben szerepel a HTML elején, a böngésző magától gyorsan megtalálja, és preload nélkül is jó eséllyel időben letölti. A preload ott segít, ahol a kép rejtve van. Tipikus helyzet a CSS-háttérkép, a JavaScripttel felépített csúszka, vagy a lusta betöltő bővítmény, amely az igazi címet data-src attribútumba teszi.

Az LCP-kép előtöltése reszponzív képnél

Ha mobilon és asztali gépen más méretű kép jelenik meg, a preloadnak ugyanazt a képválasztást kell követnie, különben a böngésző rossz fájlt tölt le, majd utána a jót is. Erre szolgál az imagesrcset és az imagesizes attribútum.

<link rel='preload' as='image' href='/kepek/hos-1200.avif' imagesrcset='/kepek/hos-600.avif 600w, /kepek/hos-1200.avif 1200w' imagesizes='100vw' fetchpriority='high'>

A betűtípus előtöltése és a crossorigin csapda

Hivatalosan igazolt. A betűtípusokat a böngésző mindig CORS-módban kéri le, akkor is, ha a saját domainedről jönnek. Ezért a betűtípus preloadjához kell a crossorigin attribútum. Ha hiányzik, a böngésző nem tudja párosítani az előtöltött fájlt a CSS kérésével, és a betűtípust kétszer tölti le.

<link rel='preload' as='font' type='font/woff2' href='/fonts/inter-latin-400.woff2' crossorigin>

Saját tapasztalat. Általában egy, legfeljebb két betűtípus-fájl előtöltése indokolt, a törzsszöveg alapvastagsága és esetleg a címsoroké. Minden vastagság és dőlt változat előtöltése ellenkező hatást ér el, mert a kritikus CSS és a kép elől veszi el a sávszélességet.

Nem érdemes előtölteni az oldal alján megjelenő képeket, a hajtás alatti szekciók betűtípusait, az analitikai és csevegő-szkripteket, és azt a CSS-fájlt, amely már a head elején amúgy is szerepel.

Mikor hasznos a külső domainre adott preconnect?

Akkor, ha egy kritikus fájl másik domainről érkezik, és a böngésző az első egy-két másodpercben kérni fogja. Ilyenkor a kapcsolatfelépítés ideje megspórolható.

Tipikus példa a külső CDN-ről érkező hős kép, vagy a Google Fonts, ahol a CSS a fonts.googleapis.com, maga a betűfájl pedig a fonts.gstatic.com domainről jön. A második domainhez crossorigin is kell, mert betűtípust szolgál ki.

<link rel='preconnect' href='https://fonts.gstatic.com' crossorigin>

Hivatalosan igazolt. A Chrome csapatának web.dev oldalon közölt útmutatója szerint a fel nem használt előre kiépített kapcsolatot a böngésző néhány másodperc után lezárja, így a ráfordított munka elvész. A preconnect ráadásul processzoridőt is visz, ezért a dokumentáció takarékos használatot javasol.

Saját tapasztalat. Kettő-három preconnect fölött ritkán látunk további javulást, gyakrabban azt, hogy a felesleges kapcsolatok a fontos kéréseket lassítják. A késve betöltődő elemekhez (analitika, hirdetési címkék, csevegőablak) inkább dns-prefetch illik, vagy semmi. Ha a betűtípusokat a saját szervereden tárolod, a Google Fonts preconnect egyszerűen törölhető.

Hogyan működik a fetchpriority attribútum?

A fetchpriority a böngésző saját prioritását módosítja egy adott elemnél. A high érték előrébb sorolja a kérést, a low hátrébb, az auto a böngészőre bízza a döntést.

Hivatalosan igazolt. Az attribútum az img, a link és a script elemen használható, a JavaScript fetch() hívásnál pedig a priority opció felel meg neki. A Chrome, a Safari és a Firefox friss verziói egyaránt támogatják, a régebbi böngészők figyelmen kívül hagyják, így kárt nem okoz. A Chrome a képeket alapból alacsony vagy közepes prioritással kezdi, és csak az elrendezés kiszámítása után emeli meg azt, amelyik a látható területre esik. A fetchpriority='high' ezt a késést spórolja meg.

<img src='/kepek/hos.avif' width='1200' height='600' alt='Az üzlet bejárata' fetchpriority='high'>

A low érték ugyanilyen hasznos. Egy karusszel második és harmadik képe, vagy egy hajtás alatti térkép-szkript kaphat fetchpriority='low' értéket, így nem versenyez a hős képpel.

Két dolgot a fetchpriority nem old meg. Ha a kép későn kerül elő (CSS-háttér, JavaScript), az img tagen lévő attribútum hiába áll ott, ilyenkor a preload linkre kell tenni. A másik az LCP-képen hagyott loading='lazy', amely a magas prioritás ellenére is visszatartja a letöltést. Hivatalosan igazolt, hogy a WordPress a 6.3-as verzió óta automatikusan fetchpriority='high' értéket tesz a valószínű LCP-képre, és az első képekről leveszi a lusta betöltést.

Hogyan néz ki a túlhasznált preload a vízesés-diagramon?

A túlhasznált preload jele, hogy a vízesés tetején sok magas prioritású kérés torlódik, és az LCP-kép vagy a fő CSS csak ezek után indul.

A vízesés-diagram (waterfall) sorban mutatja az oldal összes kérését és azt, hogy mikor kezdődtek és fejeződtek be. A Chrome DevTools Network paneljén és a WebPageTest eredményében is megtalálod. Saját tapasztalat alapján ezek a leggyakoribb tünetek.

• A lista elején öt-tíz preload sor áll, többségük betűtípus vagy szkript, és a Priority oszlopban mind High vagy Highest.
• Az LCP-kép csak a betűtípusok után indul, holott a látogató a képet várja.
• Ugyanaz a betűfájl kétszer szerepel a listában, ami szinte mindig a hiányzó crossorigin jele.
• A konzolban a böngésző figyelmeztet, hogy egy előtöltött fájlt nem használt fel a betöltés utáni néhány másodpercben.
• A főoldal hős képe az aloldalakon is előtöltődik, ahol meg sem jelenik.

Így nézd meg lépésről lépésre.

1. Nyisd meg az oldalt inkognitó ablakban, majd a DevTools Network panelt.
2. Kapcsold be a lassított hálózatot (például Fast 4G) és a gyorsítótár tiltását.
3. Jobb kattintással a fejlécen kapcsold be a Priority oszlopot.
4. Töltsd újra az oldalt, és nézd meg, hányadikként indul az LCP-kép. Az LCP elemet a Performance panel mutatja meg.
5. Szűrj rá a font típusra, és ellenőrizd, nincs-e duplikált letöltés.
6. Vess össze egy mérést a tippekkel és egyet nélkülük. Ha a különbség a mérési szóráson belül marad, a tipp felesleges.

Mit ellenőrizz a WordPress-bővítmények automatikus tippjeinél?

WordPress-oldalon a mag, a téma, az oldalépítő és a gyorsító bővítmény egymástól függetlenül is beszúrhat tippeket, ezért a ténylegesen kimenő HTML-t kell átnézni, nem a beállítási felületet.

Saját tapasztalat. A gyorsító bővítmények (például WP Rocket, LiteSpeed Cache, Perfmatters, Autoptimize) és az oldalépítők gyakran kínálnak betűtípus-előtöltést, preconnect-listát és LCP-kép kezelést. Egyenként mind ésszerű, együtt viszont könnyen egymásra rakódnak. Ezt az ellenőrzőlistát érdemes végigvinni.

1. Nézd meg a forráskódot (Ctrl+U), és keress rá a preload, preconnect, dns-prefetch és fetchpriority szavakra. Írd fel, hány darab van.
2. Ellenőrizd, hogy pontosan egy kép kap fetchpriority='high' értéket, és az tényleg az LCP-elem. Ha a mag és egy bővítmény is kioszt egyet, két kép versenyez.
3. Nézd meg, hogy az LCP-képen nincs-e loading='lazy' vagy data-src, amit egy lusta betöltő tett rá.
4. Az előtöltött betűtípusok mindegyikénél legyen crossorigin, és csak a hajtás felett használt fájlok szerepeljenek.
5. Ha a betűtípusokat helyben tárolod, töröld a Google Fonts domainekre mutató preconnectet.
6. A preconnect-listában csak olyan domain maradjon, ahonnan a betöltés első másodperceiben kritikus fájl jön.
7. Nézz meg egy aloldalt és egy blogbejegyzést is. A főoldalhoz beállított kép-előtöltés ne fusson le minden oldalon.
8. Mobil nézetben is mérj, mert ott sokszor más kép az LCP-elem, mint asztali gépen.
9. Gyorsítótár-ürítés után mérd újra, és csak az a beállítás maradjon bekapcsolva, amely mérhetően segít.

Szakmai feltételezés. A bővítményfrissítések időnként új alapértelmezett tippeket kapcsolnak be, ezért egy nagyobb frissítés után érdemes az első lépést megismételni.

Mennyit javíthat ez a Core Web Vitals értékeken és a láthatóságon?

A jól beállított tippek jó eséllyel javítják az LCP-t, de a mérték oldalanként nagyon eltér, és a keresési helyezésre gyakorolt hatás nem jósolható meg előre.

Hivatalosan igazolt. A Google Search Central szerint a Core Web Vitals az oldalélmény része, és a rangsorolás sok jelzés együttes figyelembevételével történik, ahol a tartalom relevanciája a meghatározó. Saját tapasztalat, hogy a legnagyobb javulás ott szokott jönni, ahol az LCP-kép korábban rejtve volt, vagy lusta betöltést kapott. Ahol a kép eleve jól elérhető, a tippek hatása gyakran a mérési szóráson belül marad. Szakmai feltételezés, hogy a gyors, stabilan betöltődő oldal az AI-alapú válaszmotorok szemében is megbízhatóbb forrás, de erre nincs nyilvános, mért bizonyíték.

Források és további olvasnivalók

• WHATWG HTML Living Standard, a preload és preconnect linktípusok, valamint a fetchpriority attribútum leírása
• W3C Resource Hints és Preload specifikáció
• web.dev (Google Chrome csapat), Optimize resource loading with the Fetch Priority API
• web.dev, Preload critical assets to improve loading speed és Establish network connections early
• Google Search Central, Page experience és Core Web Vitals dokumentáció
• MDN Web Docs, rel=preload, rel=preconnect és fetchpriority
• Make WordPress Core blog, Image performance enhancements in WordPress 6.3
• Chrome DevTools dokumentáció, Network és Performance panel