Preload, prefetch és preconnect: mikor segít valóban melyik
Az erőforrás-utalások akkor hasznosak, ha valódi böngészőbeli szűk keresztmetszetekhez illeszkednek. Vak használatuk prioritási zajt ad hozzá, és néha lassítja az oldalakat.
Tartalomjegyzék
- Az erőforrás-utalások nem varázslatok
- Amit a böngésző már eleve jól csinál
- Preload: túl későn felfedezett aktuális oldali erőforrásokhoz
- Preload és LCP képek
- Prefetch: a következő oldalhoz, nem ehhez
- Preconnect: költséges kapcsolatokhoz fontos eredetek felé
- DNS-prefetch: a könnyebb rokon
- Hogyan dönts: gyakorlati munkafolyamat
- 1. Azonosítsd a szűk keresztmetszetet
- 2. Egyszerre egy utalást adj hozzá
- 3. Ellenőrizd a prioritási mellékhatásokat
- 4. Ellenőrizd a fejléceket és a gyorsítótárazást
- Gyakori hibák
- Túl sok preload
- Prefetch használata kötelező erőforrásokhoz
- Preconnect minden külső félhez
- A mobilkörülmények elfelejtése
- Egyszerű döntési táblázat
- A nyugodt szabály
Az erőforrás-utalások nem varázslatok
A preload, a prefetch és a preconnect gyakran teljesítmény-ellenőrzőlistaként jelenik meg. Adjunk hozzá néhány taget a <head> részhez, futtassuk újra a Lighthouse-t, és máris jobban érezzük magunkat. Nem így működnek.
Ezek az utalások utasítások a böngésző betöltési folyamatának. Akkor segíthetnek, ha tudsz valamit, amit a böngésző nem tud elég korán felfedezni. Árthatnak, ha csak találgatsz, túl magas prioritást adsz nem kritikus munkának, vagy olyan kapcsolatokat melegítesz elő, amelyekre a felhasználóknak soha nincs szükségük.
A rövid változat:
- Használd a
preloadutalást az aktuális oldalhoz szükséges, de túl későn felfedezett erőforrásokhoz. - Használd a
prefetchutalást valószínű jövőbeli navigációs erőforrásokhoz, ne az aktuális oldal alapvető elemeihez. - Használd a
preconnectutalást fontos külső eredetekhez, ahol a kapcsolatfelépítés valódi késleltetést okoz.
A gyakorlati kérdés nem az, hogy „melyik utalás a leggyorsabb?”. Hanem az, hogy „mire vár a böngésző, és ez az utalás meg tudja-e szüntetni ezt a várakozást?”.
Amit a böngésző már eleve jól csinál
A modern böngészők nem passzív fájlletöltők. Elemzik a HTML-t, előre pásztázzák az erőforrásokat, prioritásokat rendelnek hozzájuk, újrahasznosítják a kapcsolatokat, késleltetik a nem látható munkát, és alkalmazkodnak a hálózati feltételekhez.
Ez azt jelenti, hogy az erőforrás-utalásokat szelektíven kell használni. Ha egy stíluslapot, szkriptet, képet vagy betűtípust a böngésző már korán felfedez, és megfelelő prioritást kap, egy utalás hozzáadása lehet, hogy semmit sem ér. Rosszabb esetben versenyezhet olyan erőforrásokkal, amelyek fontosabbak.
Mielőtt utalásokat adnál hozzá, nézz meg egy vízesésnézetet a DevToolsban vagy egy laborteszt jelentésében. Ha Lighthouse-t használsz, a pontszám helyett a diagnosztikával kezdd; van egy külön útmutatónk arról, hogyan olvass Lighthouse-jelentést pánik nélkül — de vedd figyelembe, hogy a helyes URL kis- és nagybetűérzékeny, ezért szükség esetén használd a webhelyed navigációjából elérhető hivatkozott cikket.
A valódi bizonyíték általában három helyen látható:
- Egy kritikus erőforrás későn indul, mert a böngésző későn fedezi fel.
- Egy fontos eredethez tartó kapcsolat az első kérés előtt észrevehető időt vesz igénybe.
- Egy következő oldali erőforrás nagy biztonsággal előre jelezhető, és üresjáratban olcsón lekérhető.
Ha ezek közül egyik sem igaz, az utalás valószínűleg csak dekoráció.
Preload: túl későn felfedezett aktuális oldali erőforrásokhoz
A preload ezt mondja a böngészőnek: „Töltsd le ezt az erőforrást most, mert az aktuális oldalnak szüksége lesz rá.”
Tipikus példa egy CSS-ben hivatkozott webes betűtípus. A böngészőnek le kell töltenie a HTML-t, fel kell fedeznie a CSS-t, le kell töltenie a CSS-t, elemeznie kell, fel kell fedeznie a betűtípust, majd kérnie kell a betűtípust. Ha ez a betűtípus fontos a hajtás feletti szöveghez, a felfedezés elég késői lehet ahhoz, hogy elrendezés-eltolódást vagy késleltetett szövegmegjelenítést okozzon.
Egy preload előrébb hozhatja ezt a kérést:
<link rel='preload' href='/fonts/inter-var.woff2' as='font' type='font/woff2' crossorigin>Az as attribútum számít. Megmondja a böngészőnek, milyen típusú erőforrásról van szó, ami hatással van a prioritásra, a gyorsítótárazásra, a tartalombiztonsági szabályzatra és a kérés fejléceire. A betűtípusokhoz általában crossorigin is kell, még akkor is, ha ugyanarról a webhelyről szolgálják ki őket, mert a betűtípusok lekérése CORS módban történik.
Jó preload jelöltek:
- A látható szöveghez használt elsődleges webes betűtípus.
- Egy hero kép, amely a Largest Contentful Paint elem, és nem fedezhető fel korán.
- Egy közvetetten betöltött kritikus CSS-fájl.
- Egy modul vagy szkript, amelyre nagyon korán szükség van, de egy másik szkript mögé van rejtve.
Rossz preload jelöltek:
- A dizájnerendszer összes betűvastagsága.
- A hajtás alatti képek.
- Olyan szkriptek, amelyek nem szükségesek a kezdeti rendereléshez.
- Olyan erőforrások, amelyeket a böngésző már az első HTML-darabban felfedez.
A preload azért erős, mert az aktuális oldal prioritásaira hat. Éppen ezért könnyű rosszul használni. Ha öt nagy eszközt preloadolsz, már nem segíted a böngészőt. Vitatkozol vele.
A betűtípusok a klasszikus eset. Egy elsődleges betűtípusfájl preloadolása segíthet. Hat vastagság és dőlt változat preloadolása általában ront a helyzeten. Ha a betűtípusok jelentik a szűk keresztmetszetet, először a betűkészletet javítsd; az útmutatónk arról, hogy a webes betűtípusok miért jelentik még mindig a legegyszerűbb teljesítménynyereséget a legtöbb webhelyen, részletesebben tárgyalja ezt a rendbetételt.
Preload és LCP képek
Egy LCP kép preloadolása hasznos lehet, ha a kép nem látható a kezdeti HTML-ben. Gyakori okok a CSS háttérképek, a kliensoldalon renderelt komponensek vagy a későn megjelenő reszponzív képlogika.
De ha a hero képed már a HTML-ben van egy <img> elemként, ésszerű srcset, sizes, méretek és lazy loading nélkül, a böngésző valószínűleg gyorsan megtalálja. Ebben az esetben az oldaltól függően a fetchpriority='high' megfelelőbb lehet, mint a preload.
Jó teszt: ha a képkérés későn indul a vízesésben, és LCP elemmé válik, fontold meg a preloadot. Ha korán indul, de lassan töltődik le, a probléma a méret, a formátum, a CDN viselkedése vagy a szerverkésleltetés — nem a felfedezés. A képformátumokkal kapcsolatos döntésekhez lásd: mikor veri az AVIF a WebP-t, és mikor nem.
Prefetch: a következő oldalhoz, nem ehhez
A prefetch ezt mondja a böngészőnek: „Erre az erőforrásra hamarosan szükség lehet, de most nincs rá szükség.”
Ez a különbség fontos. A prefetch szándékosan alacsony prioritású. A böngésző üresjáratban lekérheti, és későbbi használatra eltárolhatja. Gyenge kapcsolaton, adattakarékos módban vagy memóriahiány esetén akár ki is hagyhatja.
A prefetch akkor használandó, ha a felhasználói szándék elég erős ahhoz, hogy a következő erőforrás valószínű legyen.
Jó prefetch jelöltek:
- Egy többoldalas fizetési folyamat következő lépése.
- Keresési eredmények, miután a felhasználó elkezd beírni egy lekérdezést, ha a következő útvonal előre jelezhető.
- Tartalomjegyzékből hivatkozott dokumentációs oldalak, amikor a felhasználó aktívan olvas közeli tartalmat.
- Útvonalcsomagok egy single-page appban, miután a felhasználó rámutat vagy fókuszt helyez egy navigációs elemre.
Rossz prefetch jelöltek:
- A teljes navigációs fád.
- Nagy videók vagy képgalériák.
- Külső szkriptek „hátha” alapon.
- Olyan oldalak, amelyeket a felhasználók ritkán látogatnak meg következőként.
A prefetch esetében a visszafogottság megtérül. Egy lekért, de soha nem használt erőforrás nem ingyenes. Sávszélességet, szerverkapacitást, energiát és esetleg felhasználói adatkeretet fogyaszt. Mobilhálózatokon a spekulatív lekérés kifejezetten barátságtalan lehet.
Sok webhely számára a legjobb prefetch stratégia szándékalapú. Ne prefetchold az árazási oldalt azonnal, amikor a kezdőlap betöltődik. Akkor prefetchold, amikor a felhasználó megnyitja az árazási menüt, rámutat az árazási linkre, vagy egy olyan call-to-action közelébe görget, amely erősen előre jelzi a navigációt.
Arra is emlékezz, hogy a böngészők viselkedése eltérő. Egyes böngészők óvatosak a prefetch használatával; bizonyos adatvédelmi beállítások csökkentik vagy letiltják a spekulatív betöltést. A prefetchre alkalmi javításként tekints, ne helyességi mechanizmusként.
Preconnect: költséges kapcsolatokhoz fontos eredetek felé
A preconnect ezt mondja a böngészőnek: „Kezdd el most felépíteni a kapcsolatot ehhez az eredethez.”
Ez magában foglalhat DNS-feloldást, TCP-kapcsolatot és TLS-egyeztetést. Külső eredeteknél ez a felépítés több száz milliszekundumot vehet igénybe, különösen nagy késleltetésű hálózatokon. Ha az oldalnak hamarosan kritikus kérésre van szüksége erről az eredetről, a preconnect gyorsabbá teheti a későbbi kérést.
Példa:
<link rel='preconnect' href='https://fonts.gstatic.com' crossorigin>Jó preconnect jelöltek:
- Renderelést blokkoló szöveghez használt betűtípus-eredet.
- Kezdeti interakció során szükséges kritikus API-eredet.
- Hajtás feletti eszközöket kiszolgáló CDN-eredet.
- Fizetési vagy identitásszolgáltató, amelyre közvetlenül felhasználói művelet után szükség van.
Rossz preconnect jelöltek:
- Analitikai és hirdetési végpontok, amelyek nem felhasználó-kritikusak.
- Csak bizonyos munkamenetekben használt eredetek.
- Hosszú külső listák.
- Azonos eredetű erőforrások, ahol a böngészőnek már van kapcsolata, vagy hamarosan megnyitja azt.
A preconnectnek fenntartási költsége van. A nyitott socketek memóriát és hálózati erőforrásokat fogyasztanak. A böngészők bezárják a nem használt kapcsolatokat, de ettől a szükségtelen preconnectek nem válnak ártalmatlanná.
Hasznos szabály: egy oldalon legfeljebb egy-két nagy biztonságú külső eredetre használj preconnectet. Ha ennél többet szeretnél hozzáadni, valószínűleg a külső szolgáltatások architektúráját kell felülvizsgálni, nem az utalásokat bővíteni.
DNS-prefetch: a könnyebb rokon
Láthatod még a dns-prefetch utalást is:
<link rel='dns-prefetch' href='https://example-cdn.com'>Ez csak a domainnevet oldja fel. Nem nyit TCP- vagy TLS-kapcsolatot. Olcsóbb, mint a preconnect, de kevésbé is hasznos.
A DNS-prefetch ésszerű lehet alacsonyabb biztonságú külső eredetekhez, ahol a teljes preconnect túl agresszívnek tűnik. A gyakorlatban, ha egy eredet kritikus és biztosan hamarosan használatba kerül, részesítsd előnyben a preconnectet. Ha csak lehetséges, használj DNS-prefetch-et, vagy ne csinálj semmit.
Hogyan dönts: gyakorlati munkafolyamat
Méréssel kezdj, ne tagekkel.
1. Azonosítsd a szűk keresztmetszetet
Nyiss meg egy teljesítmény-nyomkövetést, és keresd a késői felfedezést. A betűtípus-, hero kép- vagy szkriptkérés csak azután indult el, hogy egy másik fájlt letöltöttek és elemeztek? Ez preload jelölt.
Ha egy kérés csak egy hosszú DNS/TCP/TLS felépítés után indul egy külső eredet felé, az preconnect jelölt.
Ha az aktuális oldal rendben van, de a következő navigáció előre jelezhetően lassú, a prefetch segíthet.
2. Egyszerre egy utalást adj hozzá
Az erőforrás-utalások kölcsönhatásban vannak. Adj hozzá egyet, teszteld, és csak akkor tartsd meg, ha a vízesés javul, és a felhasználói metrikák nem romlanak.
Preload esetén figyeld, hogy az utalt erőforrás valóban hamar használatba kerül-e. A Chrome figyelmeztethet, ha egy előre betöltött erőforrást nem használnak röviddel a betöltés után. Vedd komolyan ezt a figyelmeztetést.
3. Ellenőrizd a prioritási mellékhatásokat
Egy preload elveheti a sávszélességet fontosabb CSS-től, JavaScripttől vagy képektől. Egy preconnect lefoglalhat egy kapcsolathelyet. Egy prefetch háttérforgalmat adhat hozzá.
A jó eredmény nem az, hogy „az utalt fájl korábban indul”. A jó eredmény az, hogy „az oldal érezhetően jobb lesz a felhasználóknak”. Nézd az LCP-t, INP-t, CLS-t és ahol lehet, a valós felhasználói monitorozást.
4. Ellenőrizd a fejléceket és a gyorsítótárazást
Az utalások HTML-ben vagy HTTP Link fejlécekben küldhetők. A fejlécek hasznosak, ha a szerver korán tudja, mire lesz szüksége az oldalnak, de alkalmi ellenőrzéskor nehezebb őket vizsgálni. Ha azt hibakeresed, hogy egy utalás valóban jelen van-e éles környezetben, a nyers fejlécek számítanak; pontosan ilyen helyzeteket tárgyal az átirányítások és HTTP-fejlécek éles környezetbeli hibakereséséről szóló útmutatónk.
A gyorsítótárazás is számít. Egy eltérő hitelesítési adatokkal, rossz as értékkel vagy eltérő URL-paraméterekkel preloadolt erőforrás duplikált letöltéseket okozhat. Ez az egyik leggyakoribb módja annak, hogy egy jó szándékú preload teljesítményhibává váljon.
Gyakori hibák
Túl sok preload
Ha minden kritikus, semmi sem az. Korlátozd a preloadot a kezdeti rendereléshez vagy azonnali interaktivitáshoz szükséges erőforrásokra. Egy tipikus oldalon nulla-három preload legyen, ne húsz.
Prefetch használata kötelező erőforrásokhoz
A prefetch alacsony prioritású és opcionális. Ne használd az aktuális oldal által megkövetelt eszközökhöz. Ha az oldalnak most van rá szüksége, fontold meg a preloadot vagy a normál HTML-felfedezést.
Preconnect minden külső félhez
A sok külső szolgáltatást használó oldalaknak gyakran tíz vagy több külső eredetük van. Mindegyikre preconnectet használni zajt kelt. Válaszd ki azt az egyet-kettőt, amely egyszerre kritikus és előre jelezhetően használatba kerül.
A mobilkörülmények elfelejtése
Az erőforrás-utalások lassabb kapcsolatokon a legértékesebbek, de ott a legveszélyesebbek is. Egy elpazarolt prefetch egy gyors asztali kapcsolaton kerekítési hiba. Egy korlátozott mobilcsomagon rossz csere.
Egyszerű döntési táblázat
| Helyzet | Legjobb utalás | Miért | |---|---:|---| | CSS-en keresztül felfedezett kritikus betűtípus | preload | Az aktuális oldalnak szüksége van rá, a felfedezés késői | | CSS vagy kliensoldali renderelés mögé rejtett hero kép | preload | Javíthatja az LCP-t, ha a kép későn indul | | Valószínű következő útvonal felhasználói szándék után | prefetch | Segíti a jövőbeli navigációt anélkül, hogy blokkolná az aktuális oldalt | | Kritikus külső betűtípus-/API-eredet | preconnect | Kiveszi a kapcsolatfelépítést a kritikus útvonalból | | Lehetséges, de bizonytalan külső eredet | dns-prefetch vagy semmi | Alacsonyabb költség, alacsonyabb biztonság | | Hajtás alatti kép | semmi | Hagyd működni a lazy loadingot és a böngésző prioritásait |
A nyugodt szabály
Az erőforrás-utalások akkor működnek a legjobban, ha unalmasak és konkrétak. Egy betűtípus. Egy LCP kép. Egy fontos külső eredet. Egy valószínű következő útvonal szándék után.
Rosszul működnek, ha optimizmusként használják őket: hátha a felhasználónak szüksége lesz erre, hátha a böngészőnek le kellene töltenie azt, hátha a több utalás több sebességet jelent.
A böngészők már eleve agresszívan optimalizálnak. Nem az a feladatod, hogy minden kérést mikromenedzselj. Az a feladatod, hogy kijavítsd azt a néhány esetet, amikor a böngészőnek a megfelelő pillanatban nincs elég információja.
Gyakran ismételt kérdések
Érdemes az összes betűtípusomat preloadolni?
Biztonságos minden belső linkhez prefetch-et használni?
Mi a különbség a preconnect és a dns-prefetch között?
Javíthatják az erőforrás-utalások a Core Web Vitals értékeket?
Az erőforrás-utalásokat HTML-ben vagy HTTP-fejlécekben érdemes hozzáadni?
Források és további olvasmányok
