Preload: teljes útmutató
A preload egy HTML- vagy HTTP-jelzés, amellyel a webhely megmondja a böngészőnek, hogy egy adott fájlra az aktuális oldalon biztosan és korán szükség lesz, ezért azonnal, magas prioritással töltse le. Akkor hasznos, ha a böngésző egy fontos erőforrást, például betűtípust vagy fő képet, magától csak későn fedezne fel. Túlzott használata viszont lassít.
Alapfogalmak
A böngésző egy oldal betöltésekor sorban fedezi fel, mire van szüksége. Először a HTML érkezik meg, abból derül ki, milyen stíluslapok, szkriptek és képek kellenek. Egyes erőforrások azonban mélyebben rejtőznek: a betűtípust a stíluslap hivatkozza, a háttérképet szintén a CSS, egy komponens képét pedig csak egy szkript lefutása után ismeri meg a böngésző. Ezeket a böngésző csak akkor kezdi letölteni, amikor a hivatkozó fájlt már letöltötte és feldolgozta. Ez láncot hoz létre, amelyben minden lépés várakozással jár.
A preload ezt a láncot rövidíti le. A webhely előre, már a HTML elején vagy a válaszfejlécben közli: ezt a fájlt ezen az oldalon biztosan használni fogom, kezdd el most letölteni. A böngésző ilyenkor nem vár arra, hogy a hivatkozást magától megtalálja. A preload nem futtat és nem alkalmaz semmit, csak letölt és a gyorsítótárban tart, amíg a fájlra ténylegesen szükség nem lesz.
A resource hint család
| Jelzés | Mit csinál | Mire való |
|---|---|---|
preload | Letölti az erőforrást magas prioritással | Az aktuális oldalon biztosan szükséges, későn felfedezett fájl |
modulepreload | Letölti és előkészíti a JavaScript modult | Modul alapú szkriptek az aktuális oldalon |
preconnect | Előre kiépíti a kapcsolatot egy másik hoszttal | Külső hoszt, ahonnan hamarosan fájl érkezik |
dns-prefetch | Csak a névfeloldást végzi el előre | Könnyebb változat, ha a preconnect túl sok |
prefetch | Alacsony prioritással letölt egy fájlt | Egy valószínű következő oldal erőforrása |
Preload és prefetch különbsége
A két fogalmat gyakran összekeverik, pedig az irányuk ellentétes. A preload a jelenre szól: az aktuális oldal betöltéséhez kell, sürgős. A prefetch a jövőre: egy olyan oldalhoz kell, amelyre a látogató valószínűleg továbblép, ezért ráér, és csak akkor töltődik, amikor a böngésző amúgy sem csinál semmi fontosat. Ha egy fájl az aktuális oldalhoz kell, preload; ha a következőhöz, prefetch.
Mikor érdemes gondolni rá?
- Betűtípus, amelyet a stíluslap hivatkoz, és amely nélkül a szöveg későn vagy csúszva jelenik meg.
- Fő kép, amely CSS háttérként vagy szkriptből kerül az oldalra, és az LCP eleme.
- Kritikus szkript, amelyet egy másik szkript tölt be.
Hogyan működik?
A preload kétféleképpen adható meg. Az egyik egy link elem a HTML head részében, például <link rel="preload" href="/fonts/alap.woff2" as="font" type="font/woff2" crossorigin>. A másik egy HTTP-válaszfejléc: Link: </fonts/alap.woff2>; rel=preload; as=font; crossorigin. A fejléces változat előnye, hogy a böngésző már a HTML törzsének feldolgozása előtt látja. Hatásuk egyébként azonos.
Amikor a böngésző találkozik a jelzéssel, azonnal elindítja a letöltést az as attribútumnak megfelelő prioritással, és a fájlt a memóriában tartja. Amikor később a stíluslap vagy a szkript ténylegesen hivatkozik rá, a böngésző a már letöltött példányt használja. Ha a hivatkozás adatai nem egyeznek a preload adataival, például más a cím, vagy más a CORS mód, a böngésző nem ismeri fel az egyezést, és a fájlt másodszor is letölti.
Az as attribútum szerepe
Az as attribútum megadása kötelező. Ebből tudja a böngésző, milyen típusú erőforrásról van szó, milyen prioritást adjon neki, milyen fejlécekkel kérje le, és hogyan feleltesse meg a későbbi hivatkozásnak. A gyakori értékek: font, image, style, script, fetch. Ha hiányzik vagy hibás, a letöltés vagy nem történik meg, vagy a böngésző nem tudja újrahasznosítani, és kétszer tölt.
A crossorigin és a betűtípusok
A böngészők a betűtípusokat CORS módban kérik le, akkor is, ha ugyanarról a hosztról érkeznek. Ezért a betűtípus preloadjához mindig kell a crossorigin attribútum. Ha elmarad, a preload egy másik módban tölti le a fájlt, mint ahogy a stíluslap később kéri, és a böngésző nem ismeri fel egyezésként. Ez az egyik leggyakoribb oka a kétszeres betűtípus-letöltésnek.
Early Hints: preload még a válasz előtt
A 103 Early Hints egy tájékoztató HTTP-státuszkód, amellyel a szerver még a végleges válasz előtt elküldheti a preload és preconnect fejléceket. Ez akkor hasznos, ha a HTML előállítása időbe telik: amíg a szerver dolgozik, a böngésző már tölti a kritikus fájlokat. A támogatás a szerver, a CDN és a böngésző oldalán is feltétel, ezért bevezetés előtt ellenőrizni kell. A régebbi HTTP/2 server push hasonló célt szolgált, de a Chrome eltávolította a támogatását, ma a preload és az Early Hints a javasolt út. A protokollokról a HTTP/2 és a HTTP/3 útmutató szól.
Fő módszerek
A preload jó használata inkább visszafogottság, mint lelkesedés kérdése. Néhány jól kiválasztott fájl sokat segít, a túl sok viszont egymással verseng, és a valóban fontos erőforrásoktól veszi el a sávszélességet.
Betűtípus előtöltése
A leggyakoribb és leghasznosabb eset a hajtás felett használt fő betűtípus. A preload miatt a betűtípus nem a stíluslap letöltése és feldolgozása után indul, hanem vele párhuzamosan. Így rövidebb ideig látszik a helyettesítő betű, és kisebb az esélye a szöveg átrendeződésének, ami a CLS szempontjából is számít. Csak azt a betűtípust és azt a változatot érdemes előtölteni, amely tényleg megjelenik a hajtás felett, jellemzően egy vagy két fájlt.
A fő kép előtöltése
Ha az oldal LCP eleme egy kép, amely a HTML-ben egy hagyományos img elemként szerepel, a böngésző azt amúgy is korán megtalálja. Ilyenkor általában elég a fetchpriority="high" attribútum. Ha viszont a kép CSS háttérből vagy szkriptből érkezik, a preload hozza előre a felfedezést. Reszponzív képnél a imagesrcset és imagesizes attribútumokkal a preload is képes a megfelelő méretű változatot választani, így nem egy felesleges nagy kép töltődik le mobilon. A fő kép soha ne legyen egyszerre előtöltve és lazy loading jelöléssel ellátva, mert a kettő ellentmond egymásnak.
Preconnect külső hosztokhoz
Ha a kritikus fájlok egy másik hosztról érkeznek, például egy betűtípus-szolgáltatótól vagy egy külön CDN hosztról, a kapcsolat kiépítése, vagyis a DNS feloldás, a TCP és a TLS kézfogás, időbe telik. A preconnect ezt előre elvégzi. Csak azokhoz a hosztokhoz érdemes használni, ahonnan az oldal elején biztosan jön valami, mert a nyitott, de nem használt kapcsolat erőforrást köt le.
Preload a gyakorlatban: hol helyezd el?
A HTML-ben a preload sorokat a head elejére érdemes tenni, a stíluslapok elé vagy közvetlenül melléjük, hogy a böngésző minél korábban lássa őket. Ha az oldalt egy tartalomkezelő rendszer vagy keretrendszer állítja elő, a preload listát oldaltípusonként érdemes kezelni: a cikkoldal más fájlokat igényel, mint a nyitóoldal vagy egy termékoldal. A fejléces változat akkor praktikus, ha a HTML-hez nehéz hozzányúlni, vagy ha a CDN képes Early Hints válaszként továbbadni.
Döntési szabály
| Helyzet | Javasolt jelzés |
|---|---|
| A hajtás felett használt betűtípus, CSS-ből hivatkozva | preload, as="font", crossorigin |
LCP kép a HTML-ben, img elemként | fetchpriority="high", preload általában nem kell |
| LCP kép CSS háttérből vagy szkriptből | preload, as="image" |
| Kritikus fájlok külső hosztról | preconnect az adott hosztra |
| A következő valószínű oldal fájljai | prefetch, nem preload |
| Hajtás alatti kép, nem kritikus szkript | Semmilyen preload |
Gyakori hibák
A preload hibái jellemzően nem látszanak az oldalon, a hatásuk a betöltés sorrendjében és időzítésében jelenik meg. Ezért csak méréssel vehetők észre.
Túl sok preload
Ha minden fontosnak tűnő fájl preloadot kap, a böngésző egyszerre sok magas prioritású letöltést indít, és ezek egymással versengenek. A valóban kritikus stíluslap vagy a fő kép emiatt később érkezhet, mint preload nélkül. A preload a sorrendet módosítja, nem teremt új sávszélességet. Ha minden elsőbbséget kap, semmi sem kap.
Előtöltött, de nem használt fájl
Ha egy fájl preloadot kap, de az oldal végül nem használja, a letöltés teljesen felesleges volt. A Chrome ilyenkor figyelmeztetést ír a konzolba, amely szerint az erőforrást előtöltötték, de a betöltés után rövid időn belül nem használták fel. Gyakori ok, hogy a sablon minden oldalra kiírja ugyanazt a preload listát, holott az adott fájl csak néhány oldalon kell.
Eltérő attribútumok, kétszeres letöltés
A hiányzó crossorigin a betűtípusnál, a rossz as érték, vagy egy eltérő URL, például más paraméterrel, mind ahhoz vezet, hogy a böngésző nem ismeri fel a preloadot, és a fájlt másodszor is letölti. Ez rosszabb, mint ha nem lenne preload.
Tévhit: a preload rangsorolási jelzés
A preload a keresőnek nem jelez semmit a tartalomról, és önmagában nem befolyásolja a rangsorolást. Csak a betöltés sebességén keresztül hat, amely a Core Web Vitals mutatókban és a látogatói élményben jelenik meg. Aki SEO trükként tekint rá, és minden oldalra sok preloadot tesz, jó eséllyel ront a helyzeten.
Preload a hajtás alatti tartalomra
Előfordul, hogy egy sablon a lap alján lévő galéria képeit vagy egy csak görgetés után látható szekció betűtípusát is előtölti. Ezek a fájlok a látogató első képernyőjén nem játszanak szerepet, a preload mégis az oldal elejére hozza őket, pont abba az időszakba, amikor a böngésző a legfontosabb elemekért küzd. Ami a hajtás alatt van, annak a késleltetett betöltés a helye, nem az előtöltés.
Ellenpélda: amikor a preload tényleg kell
Nem minden preload gyanús. Ha egy webhely saját betűtípussal jeleníti meg a teljes címsort a hajtás felett, és a Network lapon látszik, hogy a betűtípus csak a stíluslap után indul, a preload pontosan erre a helyzetre való. A kérdés mindig az, hogy a fájl későn fedeződik-e fel, és szükség van-e rá azonnal. Ha mindkettőre igen a válasz, a preload indokolt.
Egyéb hibák röviden
- Prefetch helyett preload. A következő oldal fájljai az aktuális oldal elől veszik el a sávszélességet.
- Elavult preload a sablonban. Egy korábbi betűtípus vagy kép neve maradt benne, a fájl már nem létezik, és 404 hibát ad.
- Preload mindkét helyen. HTML-ben és fejlécben is szerepel, eltérő attribútumokkal.
- Túl sok preconnect. Sok hosztra nyitott kapcsolat, amelyből csak kevés kell.
Mérés
A preload hatását a betöltési sorrend és a fő mutatók változása alapján lehet megítélni. Egy preload akkor jó, ha a kritikus fájl korábban érkezik, és közben semmi más fontos nem lassul.
Fejlesztői eszközök
A böngésző fejlesztői eszközeinek Network lapján a vízesés nézetben látszik, mikor indul az egyes fájlok letöltése, és milyen prioritással. Egy működő betűtípus-preloadnál a betűtípus a stíluslappal párhuzamosan indul, nem utána. A kétszeres letöltés is itt vehető észre: ugyanaz a fájl kétszer szerepel a listában. A Console lapon megjelennek a fel nem használt preloadokra vonatkozó figyelmeztetések. A Performance lap felvétele megmutatja, mikor jelenik meg az LCP elem, és mi késleltette.
Lighthouse és PageSpeed Insights
A Lighthouse és a PageSpeed Insights elemzi az LCP elem betöltését, és jelzi, ha a kép felfedezése késett, vagy ha a preconnect segíthetne. A javaslatokat érdemes egyenként mérlegelni, nem automatikusan elfogadni. A terepi adatok, a Chrome felhasználói adatai és a Search Console Core Web Vitals jelentése, gördülő időablakban frissülnek, ezért a változás hatása csak később látszik bennük.
Kidolgozott példa: a betűtípus, ami kétszer töltődött
Egy szolgáltató webhely fejlesztője a fő betűtípusra preloadot tett, de a Network lapon azt látja, hogy a fájl kétszer töltődik le. A preload sorából hiányzik a crossorigin attribútum. Pótolja, a második letöltés eltűnik, a betűtípus a stíluslappal párhuzamosan érkezik. Ugyanekkor észreveszi, hogy a sablon három másik betűtípus-változatot is előtölt, amelyek csak a láblécben szerepelnek. Ezeket kiveszi, így a fő kép letöltése előrébb kerül a vízesésben.
Kidolgozott példa: háttérkép mint LCP elem
Egy nyitóoldal fő látványeleme CSS háttérképként szerepel. A Lighthouse szerint ez az LCP elem, és a felfedezése későn történik, mert a böngésző csak a stíluslap feldolgozása után tud róla. A fejlesztő a HTML fejébe preloadot tesz a képre, as="image" értékkel, mobilra és asztalira külön változattal. A vízesésben a kép letöltése előrébb kerül, a mérések pedig azt mutatják, hogy az LCP korábban következik be.
Ellenőrzőlista
- Csak az aktuális oldalon biztosan használt, későn felfedezett fájl kap preloadot.
- Minden preloadnál helyes az
asérték. - A betűtípusok preloadja tartalmazza a
crossoriginattribútumot. - Nincs kétszeres letöltés a Network lapon.
- A Console nem jelez fel nem használt preloadot.
- A fő kép nem egyszerre előtöltött és lazy.
- A következő oldal fájljai prefetch-et kapnak, nem preloadot.
Kapcsolódó részletes útmutatók
Csináltassuk meg helyetted
Ha ez sok, mi elvégezzük. Egy munkanapon belül konkrét ajánlatot kapsz.