Preload, prefetch i preconnect: kada svaki od njih zaista pomaže
Resource hints korisni su kada odgovaraju stvarnim uskim grlima u pregledniku. Ako se koriste naslijepo, dodaju šum u prioritetima i ponekad usporavaju stranice.
Sadržaj
- Resource hints nisu magija
- Što preglednik već dobro radi
- Preload: za resurse trenutačne stranice otkrivene prekasno
- Preload i LCP slike
- Prefetch: za sljedeću stranicu, ne za ovu
- Preconnect: za skupe veze prema važnim origin-ima
- DNS-prefetch: lakši rođak
- Kako odlučiti: praktičan tijek rada
- 1. Prepoznajte usko grlo
- 2. Dodajte jednu naznaku odjednom
- 3. Provjerite nuspojave prioriteta
- 4. Provjerite zaglavlja i caching
- Česte pogreške
- Preloading previše toga
- Korištenje prefetch za obvezne resurse
- Preconnecting prema svakoj trećoj strani
- Zaboravljanje mobilnih uvjeta
- Jednostavna tablica odluka
- Mirno pravilo
Resource hints nisu magija
preload, prefetch i preconnect često se tretiraju kao kontrolni popis za performanse. Dodajte nekoliko tagova u <head>, ponovno pokrenite Lighthouse, osjećajte se bolje. To ne funkcionira tako.
Te su naznake upute za preglednikov proces učitavanja. Mogu pomoći kada znate nešto što preglednik ne može otkriti dovoljno rano. Mogu štetiti kada nagađate, pretjerano prioritizirate nekritičan rad ili unaprijed zagrijavate veze koje korisnicima nikada neće trebati.
Kratka verzija:
- Koristite
preloadza resurse potrebne za trenutačnu stranicu, ali otkrivene prekasno. - Koristite
prefetchza vjerojatne resurse buduće navigacije, ne za ključne resurse trenutačne stranice. - Koristite
preconnectza važne origin-e trećih strana gdje je uspostava veze stvarno kašnjenje.
Praktično pitanje nije „koja je naznaka najbrža?” Nego „što preglednik čeka i može li ova naznaka ukloniti to čekanje?”
Što preglednik već dobro radi
Moderni preglednici nisu pasivni preuzimači datoteka. Parsiraju HTML, skeniraju unaprijed za resurse, dodjeljuju prioritete, ponovno koriste veze, odgađaju rad koji nije vidljiv i prilagođavaju se mrežnim uvjetima.
To znači da resource hints treba koristiti selektivno. Ako su stylesheet, skripta, slika ili font već rano otkriveni i dobili su pravi prioritet, dodavanje naznake možda neće učiniti ništa. Još gore, može se natjecati s resursima koji su važniji.
Prije dodavanja naznaka, pogledajte waterfall prikaz u DevTools ili laboratorijskom izvješću. Ako koristite Lighthouse, počnite s dijagnostikom, a ne s ocjenom; imamo zaseban vodič o čitanju Lighthouse izvješća bez panike — ali imajte na umu da ispravan URL razlikuje velika i mala slova, pa po potrebi koristite povezani članak iz navigacije svoje stranice.
Pravi dokaz obično je vidljiv na tri mjesta:
- Kritičan resurs počinje kasno jer ga preglednik kasno otkriva.
- Veza prema važnom origin-u traje zamjetno dugo prije prvog zahtjeva.
- Resurs sljedeće stranice vrlo je predvidljiv i jeftin za dohvaćanje u stanju mirovanja.
Ako ništa od toga nije točno, naznaka je vjerojatno ukras.
Preload: za resurse trenutačne stranice otkrivene prekasno
preload govori pregledniku: „Dohvati ovaj resurs sada jer će ga trenutačna stranica trebati.”
Tipičan primjer je web font referenciran unutar CSS-a. Preglednik mora preuzeti HTML, otkriti CSS, preuzeti CSS, parsirati ga, otkriti font, a zatim zatražiti font. Ako je taj font važan za tekst iznad preklopa, otkrivanje može biti dovoljno kasno da uzrokuje pomake layouta ili odgođeno renderiranje teksta.
Preload može pomaknuti taj zahtjev ranije:
<link rel='preload' href='/fonts/inter-var.woff2' as='font' type='font/woff2' crossorigin>Atribut as je važan. Govori pregledniku o kojoj je vrsti resursa riječ, što utječe na prioritet, caching, content security policy i zaglavlja zahtjeva. Fontovi također obično trebaju crossorigin, čak i kada se poslužuju s iste stranice, jer dohvaćanje fontova koristi CORS način rada.
Dobri kandidati za preload uključuju:
- Primarni web font koji se koristi za vidljivi tekst.
- Hero sliku koja je Largest Contentful Paint element i nije rano otkriva.
- Kritičnu CSS datoteku učitanu neizravno.
- Modul ili skriptu potrebnu vrlo rano, ali skrivenu iza druge skripte.
Loši kandidati za preload uključuju:
- Svaku debljinu fonta u dizajn sustavu.
- Slike ispod preklopa.
- Skripte koje nisu potrebne za početno renderiranje.
- Resurse koje preglednik već otkriva u prvom HTML fragmentu.
Preload je moćan jer utječe na prioritet trenutačne stranice. Upravo ga je zato lako pogrešno koristiti. Ako preloadate pet velikih asseta, više ne pomažete pregledniku. Raspravljate se s njim.
Fontovi su klasičan slučaj. Preloading jedne primarne datoteke fonta može pomoći. Preloading šest debljina i kurziva obično pogoršava stvari. Ako su fontovi vaše usko grlo, prvo sredite skup fontova; naš vodič o tome zašto su web fontovi još uvijek najlakša pobjeda za performanse na većini stranica detaljnije pokriva to čišćenje.
Preload i LCP slike
Preloading LCP slike može biti koristan kada slika nije vidljiva u početnom HTML-u. Česti uzroci uključuju CSS pozadinske slike, komponente renderirane na klijentu ili logiku responzivnih slika koja se pojavljuje kasno.
Ali ako je vaša hero slika već u HTML-u kao <img> s razumnim srcset, sizes, dimenzijama i bez lazy loadinga, preglednik je vjerojatno može brzo pronaći. U tom slučaju dodavanje fetchpriority='high' može biti prikladnije od preloada, ovisno o stranici.
Dobar test: ako zahtjev za sliku počinje kasno u waterfallu i postaje LCP element, razmotrite preload. Ako počinje rano, ali se sporo preuzima, problem je veličina, format, ponašanje CDN-a ili latencija poslužitelja — ne otkrivanje. Za odluke o formatima slika pogledajte kada AVIF pobjeđuje WebP, a kada ne.
Prefetch: za sljedeću stranicu, ne za ovu
prefetch govori pregledniku: „Ovaj resurs mogao bi uskoro biti potreban, ali nije potreban upravo sada.”
Ta je razlika važna. Prefetch je namjerno niskog prioriteta. Preglednik ga može dohvatiti tijekom mirovanja i spremiti za kasniju upotrebu. Može ga i preskočiti na lošim vezama, u načinima štednje podataka ili pod pritiskom memorije.
Koristite prefetch kada je namjera korisnika dovoljno jaka da sljedeći resurs bude vjerojatan.
Dobri kandidati za prefetch uključuju:
- Sljedeći korak u višestraničnoj naplati.
- Rezultate pretraživanja nakon što korisnik počne upisivati upit, ako je sljedeća ruta predvidljiva.
- Stranice dokumentacije povezane iz sadržaja kada korisnik aktivno čita obližnji sadržaj.
- Route chunkove u single-page app nakon što korisnik prijeđe mišem preko navigacijske stavke ili je fokusira.
Loši kandidati za prefetch uključuju:
- Cijelo vaše navigacijsko stablo.
- Velike videozapise ili galerije slika.
- Skripte trećih strana „za svaki slučaj”.
- Stranice koje korisnici rijetko posjećuju sljedeće.
Prefetch je mjesto gdje se suzdržanost isplati. Resurs koji je dohvaćen, a nikada nije upotrijebljen, nije besplatan. Troši propusnost, kapacitet poslužitelja, energiju i moguće korisničke podatke. Na mobilnim mrežama spekulativno dohvaćanje može biti aktivno neprijateljsko prema korisniku.
Za mnoge stranice najbolja strategija prefetchinga temelji se na namjeri. Nemojte prefetchati stranicu s cijenama čim se početna stranica učita. Prefetchajte je kada korisnik otvori izbornik s cijenama, prijeđe mišem preko poveznice za cijene ili se pomakne blizu poziva na akciju koji snažno predviđa navigaciju.
Također imajte na umu da se ponašanje preglednika razlikuje. Neki su preglednici konzervativni s prefetchom; neke postavke privatnosti smanjuju ili onemogućuju spekulativno učitavanje. Tretirajte prefetch kao oportunističko poboljšanje, ne kao mehanizam ispravnosti.
Preconnect: za skupe veze prema važnim origin-ima
preconnect govori pregledniku: „Počni uspostavljati vezu s ovim origin-om sada.”
To može uključivati DNS lookup, TCP vezu i TLS pregovaranje. Za origin-e trećih strana ta uspostava može trajati stotine milisekundi, osobito na mrežama visoke latencije. Ako stranica uskoro treba kritičan zahtjev s tog origin-a, preconnect može ubrzati kasniji zahtjev.
Primjer:
<link rel='preconnect' href='https://fonts.gstatic.com' crossorigin>Dobri kandidati za preconnect uključuju:
- Origin fontova koji se koristi za tekst koji blokira renderiranje.
- Kritičan API origin potreban tijekom početne interakcije.
- CDN origin koji poslužuje assete iznad preklopa.
- Pružatelja plaćanja ili identiteta potrebnog odmah nakon korisničke radnje.
Loši kandidati za preconnect uključuju:
- Analytics i oglašivačke endpointove koji nisu kritični za korisnika.
- Origin-e koji se koriste samo u nekim sesijama.
- Duge popise trećih strana.
- Resurse istog origin-a, gdje preglednik već ima ili će uskoro otvoriti vezu.
Preconnect ima trošak držanja. Otvoreni socketi troše memoriju i mrežne resurse. Preglednici će zatvoriti neiskorištene veze, ali to ne čini nepotrebne preconnecte bezopasnima.
Korisno pravilo: preconnectajte se na najviše jedan ili dva origin-a trećih strana s visokom sigurnošću na stranici. Ako vas privlači dodati ih više, vašoj arhitekturi trećih strana vjerojatno treba revizija više nego što vašim naznakama treba proširenje.
DNS-prefetch: lakši rođak
Možete vidjeti i dns-prefetch:
<link rel='dns-prefetch' href='https://example-cdn.com'>To samo razrješava naziv domene. Ne otvara TCP ili TLS vezu. Jeftinije je od preconnecta, ali i manje korisno.
DNS-prefetch može biti razuman za origin-e trećih strana s nižom razinom sigurnosti, gdje puni preconnect djeluje preagresivno. U praksi, ako je origin kritičan i sigurno će se uskoro koristiti, preferirajte preconnect. Ako je tek moguć, upotrijebite DNS-prefetch ili nemojte učiniti ništa.
Kako odlučiti: praktičan tijek rada
Počnite s mjerenjem, ne s tagovima.
1. Prepoznajte usko grlo
Otvorite performance trace i potražite kasno otkrivanje. Je li zahtjev za font, hero sliku ili skriptu počeo tek nakon što je druga datoteka preuzeta i parsirana? To je kandidat za preload.
Ako zahtjev počinje tek nakon duge DNS/TCP/TLS uspostave prema origin-u treće strane, to je kandidat za preconnect.
Ako je trenutačna stranica u redu, ali je sljedeća navigacija predvidljivo spora, prefetch može pomoći.
2. Dodajte jednu naznaku odjednom
Resource hints međusobno djeluju. Dodajte jednu, testirajte je i zadržite je samo ako se waterfall poboljša, a metrike okrenute korisniku ne nazaduju.
Za preload pratite koristi li se naznačeni resurs doista uskoro. Chrome može upozoriti kada se preloaded resurs ne upotrijebi ubrzo nakon učitavanja. Shvatite to upozorenje ozbiljno.
3. Provjerite nuspojave prioriteta
Preload može odvući propusnost od CSS-a, JavaScripta ili slika koje su važnije. Preconnect može zauzeti slot za vezu. Prefetch može dodati pozadinski promet.
Pravi ishod nije „naznačena datoteka počinje ranije.” Pravi ishod je „stranica postaje smisleno bolja za korisnike.” Gledajte LCP, INP, CLS i real-user monitoring gdje je moguće.
4. Provjerite zaglavlja i caching
Naznake se mogu slati u HTML-u ili HTTP Link zaglavljima. Zaglavlja su korisna kada poslužitelj rano zna što će stranici trebati, ali ih je teže usputno pregledati. Ako debugirate je li naznaka doista prisutna u produkciji, sirova zaglavlja su važna; upravo takvu situaciju pokriva naš vodič za debugging redirecta i HTTP zaglavlja.
Caching je također važan. Preloading resursa s neusklađenim vjerodajnicama, pogrešnim as ili različitim URL parametrima može uzrokovati dvostruka preuzimanja. To je jedan od najčešćih načina na koji dobronamjeran preload postaje performance bug.
Česte pogreške
Preloading previše toga
Ako je sve kritično, ništa nije. Ograničite preload na resurse potrebne za početno renderiranje ili neposrednu interaktivnost. Tipična stranica trebala bi imati nula do tri preloada, ne dvadeset.
Korištenje prefetch za obvezne resurse
Prefetch je niskog prioriteta i opcionalan. Nemojte ga koristiti za assete potrebne trenutačnoj stranici. Ako stranica nešto treba sada, razmotrite preload ili normalno HTML otkrivanje.
Preconnecting prema svakoj trećoj strani
Stranice opterećene trećim stranama često imaju deset ili više vanjskih origin-a. Preconnecting prema svima njima stvara šum. Odaberite jedan ili dva koji su istodobno kritični i predvidljivo korišteni.
Zaboravljanje mobilnih uvjeta
Resource hints najvrjedniji su na sporijim vezama, ali su ondje i najopasniji. Uzaludan prefetch na brzoj desktop vezi zanemariva je razlika. Na ograničenom mobilnom paketu to je loša razmjena.
Jednostavna tablica odluka
| Situacija | Najbolja naznaka | Zašto | |---|---:|---| | Kritičan font otkriven kroz CSS | preload | Trenutačna stranica ga treba, otkrivanje je kasno | | Hero slika skrivena iza CSS-a ili klijentskog renderiranja | preload | Može poboljšati LCP ako slika počinje kasno | | Vjerojatna sljedeća ruta nakon korisničke namjere | prefetch | Pomaže budućoj navigaciji bez blokiranja trenutačne stranice | | Kritičan font/API origin treće strane | preconnect | Uklanja uspostavu veze s kritičnog puta | | Moguć, ali nesiguran origin treće strane | dns-prefetch ili ništa | Niži trošak, niža sigurnost | | Slika ispod preklopa | ništa | Prepustite posao lazy loadingu i prioritetima preglednika |
Mirno pravilo
Resource hints najbolje funkcioniraju kada su dosadni i specifični. Jedan font. Jedna LCP slika. Jedan važan origin treće strane. Jedna vjerojatna sljedeća ruta nakon namjere.
Loše funkcioniraju kada se koriste kao optimizam: možda će korisniku ovo trebati, možda bi preglednik trebao dohvatiti ono, možda više naznaka znači više brzine.
Preglednici već agresivno optimiziraju. Vaš posao nije mikroupravljati svakim zahtjevom. Vaš je posao ispraviti nekoliko slučajeva u kojima pregledniku nedostaje informacija u pravom trenutku.
Često postavljana pitanja
Trebam li preloadati sve svoje fontove?
Je li prefetch sigurno koristiti za svaku internu poveznicu?
Koja je razlika između preconnect i dns-prefetch?
Mogu li resource hints poboljšati Core Web Vitals?
Treba li resource hints dodati u HTML ili HTTP zaglavlja?
Izvori i daljnje čitanje
