Web Performance

Preload, prefetch i preconnect: kada svaki od njih zaista pomaže

Resource hints su korisni kada odgovaraju stvarnim uskim grlima u browseru. Kada se koriste naslepo, dodaju šum u prioritetima i ponekad usporavaju stranice.

The Wux Webtools Team The Wux Webtools Team 10 min čitanja Pomoć veštačke inteligencije, pregledano od strane ljudi
A simplified browser loading waterfall showing early resource hints for a web page.
Sadržaj
  1. Resource hints nisu magija
  2. Šta browser već dobro radi
  3. Preload: za resurse trenutne stranice koji se otkrivaju prekasno
  4. Preload i LCP slike
  5. Prefetch: za sledeću stranicu, ne za ovu
  6. Preconnect: za skupe konekcije ka važnim originima
  7. DNS-prefetch: lakši rođak
  8. Kako odlučiti: praktičan tok rada
  9. 1. Identifikujte usko grlo
  10. 2. Dodajte jedan hint po jedan
  11. 3. Proverite sporedne efekte prioriteta
  12. 4. Proverite zaglavlja i keširanje
  13. Česte greške
  14. Previše preloadovanja
  15. Korišćenje prefetch za obavezne resurse
  16. Preconnect ka svakoj trećoj strani
  17. Zaboravljanje mobilnih uslova
  18. Jednostavna tabela odlučivanja
  19. Mirno pravilo

Resource hints nisu magija

preload, prefetch i preconnect često se tretiraju kao kontrolna lista za performanse. Dodajte nekoliko tagova u <head>, ponovo pokrenite Lighthouse, osećajte se bolje. To nije način na koji funkcionišu.

Ovi hintovi su instrukcije za browserov proces učitavanja. Mogu pomoći kada znate nešto što browser ne može da otkrije dovoljno rano. Mogu odmoći kada nagađate, dodelite previsok prioritet ne-kritičnom radu ili unapred zagrejete konekcije koje korisnicima nikada neće trebati.

Kratka verzija:

  • Koristite preload za resurse koji su potrebni trenutnoj stranici, ali se otkrivaju prekasno.
  • Koristite prefetch za resurse verovatne buduće navigacije, ne za ključne resurse trenutne stranice.
  • Koristite preconnect za važne third-party origine gde je uspostavljanje konekcije stvarno kašnjenje.

Praktično pitanje nije „koji hint je najbrži?” Već „šta browser čeka i može li ovaj hint da ukloni to čekanje?”

Šta browser već dobro radi

Moderni browseri nisu pasivni preuzimači fajlova. Oni parsiraju HTML, skeniraju unapred u potrazi za resursima, dodeljuju prioritete, ponovo koriste konekcije, odlažu rad koji nije vidljiv i prilagođavaju se mrežnim uslovima.

To znači da resource hints treba koristiti selektivno. Ako se stylesheet, script, image ili font već otkriva rano i dobija pravi prioritet, dodavanje hinta možda neće uraditi ništa. Još gore, može se takmičiti sa resursima koji su važniji.

Pre nego što dodate hintove, pogledajte waterfall trace u DevTools ili laboratorijski izveštaj. Ako koristite Lighthouse, počnite od dijagnostike, a ne od ocene; imamo poseban vodič o čitanju Lighthouse izveštaja bez panike — ali imajte na umu da je tačan URL osetljiv na velika i mala slova, pa po potrebi koristite povezani članak iz navigacije vašeg sajta.

Pravi dokazi se obično vide na tri mesta:

  1. Kritični resurs počinje kasno zato što ga browser kasno otkriva.
  2. Konekcija ka važnom originu traje primetno dugo pre prvog zahteva.
  3. Resurs sledeće stranice je vrlo predvidljiv i jeftin za preuzimanje u idle vremenu.

Ako ništa od toga nije tačno, hint je verovatno dekoracija.

Preload: za resurse trenutne stranice koji se otkrivaju prekasno

preload govori browseru: „Preuzmi ovaj resurs sada jer će trenutnoj stranici biti potreban.”

Tipičan primer je web font referenciran unutar CSS-a. Browser mora da preuzme HTML, otkrije CSS, preuzme CSS, parsira ga, otkrije font, pa zatim zatraži font. Ako je taj font važan za tekst iznad prevoja, otkrivanje može biti dovoljno kasno da izazove pomeranja layouta ili odloženo renderovanje teksta.

Preload može da pomeri taj zahtev ranije:

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

Atribut as je važan. On govori browseru koja je vrsta resursa u pitanju, što utiče na prioritet, keširanje, content security policy i zaglavlja zahteva. Fontovima je takođe obično potreban crossorigin, čak i kada se isporučuju sa istog sajta, jer preuzimanje fontova koristi CORS režim.

Dobri kandidati za preload uključuju:

  • Primarni web font koji se koristi za vidljiv tekst.
  • Hero sliku koja je Largest Contentful Paint element i ne može se rano otkriti.
  • Kritični CSS fajl koji se učitava indirektno.
  • Modul ili script potreban vrlo rano, ali sakriven iza drugog scripta.

Loši kandidati za preload uključuju:

  • Svaku debljinu fonta u design systemu.
  • Slike ispod prevoja.
  • Scriptove koji nisu potrebni za početno renderovanje.
  • Resurse koje browser već otkriva u prvom HTML komadu.

Preload je moćan jer utiče na prioritet trenutne stranice. Upravo zato ga je lako pogrešno upotrebiti. Ako preloadujete pet velikih asseta, više ne pomažete browseru. Raspravljate se s njim.

Fontovi su klasičan slučaj. Preload jednog primarnog font fajla može pomoći. Preload š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 i dalje najlakša pobeda za performanse na većini sajtova detaljnije pokriva to čišćenje.

Preload i LCP slike

Preload LCP slike može biti koristan kada slika nije vidljiva u početnom HTML-u. Česti uzroci uključuju CSS background images, komponente renderovane na klijentu ili responsive image logiku koja se pojavljuje kasno.

Ali ako je vaša hero slika već u HTML-u kao <img> sa razumnim srcset, sizes, dimenzijama i bez lazy loadinga, browser je verovatno može brzo pronaći. U tom slučaju dodavanje fetchpriority='high' može biti prikladnije od preload, u zavisnosti od stranice.

Dobar test: ako zahtev 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 servera — ne otkrivanje. Za odluke o formatima slika pogledajte kada AVIF pobeđuje WebP, a kada ne.

Prefetch: za sledeću stranicu, ne za ovu

prefetch govori browseru: „Ovaj resurs će možda uskoro biti potreban, ali nije potreban baš sada.”

Ta razlika je važna. Prefetch je namerno niskog prioriteta. Browser ga može preuzeti tokom idle vremena i sačuvati za kasniju upotrebu. Takođe ga može preskočiti na lošim konekcijama, u režimima uštede podataka ili pod pritiskom memorije.

Koristite prefetch kada je namera korisnika dovoljno jaka da sledeći resurs učini verovatnim.

Dobri kandidati za prefetch uključuju:

  • Sledeći korak u višestraničnom checkoutu.
  • Rezultate pretrage nakon što korisnik počne da kuca upit, ako je sledeć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 hoveruje ili fokusira stavku navigacije.

Loši kandidati za prefetch uključuju:

  • Celo vaše navigaciono stablo.
  • Velike video snimke ili galerije slika.
  • Third-party scriptove „za svaki slučaj”.
  • Stranice koje korisnici retko posećuju sledeće.

Prefetch je mesto gde se uzdržanost isplati. Resurs koji je preuzet i nikada upotrebljen nije besplatan. Troši bandwidth, kapacitet servera, energiju i moguće korisničke podatke. Na mobilnim mrežama, spekulativno preuzimanje može biti izrazito neprijateljsko prema korisniku.

Za mnoge sajtove, najbolja prefetch strategija je zasnovana na nameri. Nemojte prefetchovati stranicu sa cenama čim se početna stranica učita. Prefetchujte je kada korisnik otvori meni sa cenama, hoveruje link ka cenama ili skroluje blizu call-to-action elementa koji snažno predviđa navigaciju.

Takođe zapamtite da se ponašanje browsera razlikuje. Neki browseri su konzervativni sa prefetch; neka podešavanja privatnosti smanjuju ili onemogućavaju spekulativno učitavanje. Tretirajte prefetch kao oportunističko poboljšanje, ne kao mehanizam ispravnosti.

Preconnect: za skupe konekcije ka važnim originima

preconnect govori browseru: „Počni sada da uspostavljaš konekciju ka ovom originu.”

To može uključiti DNS lookup, TCP konekciju i TLS pregovaranje. Za third-party origine, ovo podešavanje može trajati stotine milisekundi, naročito na mrežama sa visokom latencijom. Ako stranici uskoro treba kritični zahtev sa tog origina, preconnect može ubrzati kasniji zahtev.

Primer:

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

Dobri kandidati za preconnect uključuju:

  • Origin fontova koji se koristi za render-blocking tekst.
  • Kritični API origin potreban tokom početne interakcije.
  • CDN origin koji isporučuje assete iznad prevoja.
  • Payment ili identity provider potreban odmah nakon korisničke akcije.

Loši kandidati za preconnect uključuju:

  • Analytics i advertising endpointi koji nisu kritični za korisnika.
  • Origini koji se koriste samo u nekim sesijama.
  • Dugi spiskovi third-party servisa.
  • Same-origin resursi, gde browser već ima ili će uskoro otvoriti konekciju.

Preconnect ima cenu držanja. Otvoreni socketi troše memoriju i mrežne resurse. Browseri će zatvoriti nekorišćene konekcije, ali to ne čini nepotrebne preconnecte bezopasnim.

Korisno pravilo: preconnectujte najviše jedan ili dva third-party origina sa visokim nivoom sigurnosti na stranici. Ako ste u iskušenju da dodate više, vašoj third-party arhitekturi verovatno je potrebna revizija više nego što je vašim hintovima potrebno proširenje.

DNS-prefetch: lakši rođak

Možda ćete videti i dns-prefetch:

<link rel='dns-prefetch' href='https://example-cdn.com'>

Ovo samo razrešava ime domena. Ne otvara TCP ili TLS konekciju. Jeftinije je od preconnect, ali je i manje korisno.

DNS-prefetch može biti razuman za third-party origine sa manjim nivoom sigurnosti, gde pun preconnect deluje previše agresivno. U praksi, ako je origin kritičan i sigurno će se uskoro koristiti, preferirajte preconnect. Ako je samo moguć, koristite DNS-prefetch ili ne radite ništa.

Kako odlučiti: praktičan tok rada

Počnite merenjem, ne tagovima.

1. Identifikujte usko grlo

Otvorite performance trace i potražite kasno otkrivanje. Da li zahtev za font, hero sliku ili script počinje tek nakon što je drugi fajl preuzet i parsiran? To je kandidat za preload.

Ako zahtev počinje tek nakon dugog DNS/TCP/TLS uspostavljanja ka third-party originu, to je kandidat za preconnect.

Ako je trenutna stranica u redu, ali je sledeća navigacija predvidljivo spora, prefetch može pomoći.

2. Dodajte jedan hint po jedan

Resource hints međusobno utiču jedni na druge. Dodajte jedan, testirajte ga i zadržite ga samo ako se waterfall poboljša, a metrike koje korisnik oseća ne nazaduju.

Za preload pratite da li se naznačeni resurs zaista uskoro koristi. Chrome može upozoriti kada se preloaded resurs ne upotrebi ubrzo nakon učitavanja. Shvatite to upozorenje ozbiljno.

3. Proverite sporedne efekte prioriteta

Preload može povući bandwidth od CSS-a, JavaScript-a ili slika koje su važnije. Preconnect može zauzeti connection slot. Prefetch može dodati pozadinski saobraćaj.

Pravi rezultat nije „hintovani fajl počinje ranije”. Pravi rezultat je „stranica postaje smisleno bolja za korisnike”. Gledajte LCP, INP, CLS i real-user monitoring gde je moguće.

4. Proverite zaglavlja i keširanje

Hintovi se mogu poslati u HTML-u ili HTTP Link zaglavljima. Zaglavlja su korisna kada server rano zna šta će stranici biti potrebno, ali ih je teže usputno pregledati. Ako debagujete da li je hint zaista prisutan u produkciji, sirova zaglavlja su važna; to je upravo vrsta situacije obrađena u našem vodiču za debagovanje redirecta i HTTP zaglavlja.

Keširanje je takođe važno. Preload resursa sa neusklađenim credentials, pogrešnim as ili različitim URL parametrima može izazvati duplirana preuzimanja. To je jedan od najčešćih načina na koji dobronamerni preload postaje performance bug.

Česte greške

Previše preloadovanja

Ako je sve kritično, ništa nije. Ograničite preload na resurse potrebne za početno renderovanje ili neposrednu interaktivnost. Tipična stranica treba da ima nula do tri preloada, ne dvadeset.

Korišćenje prefetch za obavezne resurse

Prefetch je niskog prioriteta i opcion. Ne koristite ga za assete potrebne trenutnoj stranici. Ako je stranici potreban sada, razmotrite preload ili normalno HTML otkrivanje.

Preconnect ka svakoj trećoj strani

Stranice opterećene third-party resursima često imaju deset ili više eksternih origina. Preconnect ka svima njima stvara šum. Izaberite jedan ili dva koji su i kritični i predvidljivo korišćeni.

Zaboravljanje mobilnih uslova

Resource hints su najvredniji na sporijim konekcijama, ali su tamo i najopasniji. Protraćen prefetch na brzoj desktop konekciji je zanemarljiva greška. Na ograničenom mobilnom paketu, to je loša razmena.

Jednostavna tabela odlučivanja

| Situacija | Najbolji hint | Zašto | |---|---:|---| | Kritični font otkriven kroz CSS | preload | Trenutnoj stranici je potreban, otkrivanje je kasno | | Hero slika sakrivena iza CSS-a ili klijentskog renderovanja | preload | Može poboljšati LCP ako slika počinje kasno | | Verovatna sledeća ruta nakon korisničke namere | prefetch | Pomaže budućoj navigaciji bez blokiranja trenutne stranice | | Kritični third-party font/API origin | preconnect | Uklanja uspostavljanje konekcije iz kritične putanje | | Moguć, ali neizvestan third-party origin | dns-prefetch ili ništa | Niži trošak, niža sigurnost | | Slika ispod prevoja | ništa | Pustite lazy loading i prioritet browsera da rade |

Mirno pravilo

Resource hints najbolje rade kada su dosadni i konkretni. Jedan font. Jedna LCP slika. Jedan važan third-party origin. Jedna verovatna sledeća ruta nakon namere.

Loše rade kada se koriste kao optimizam: možda će korisniku ovo trebati, možda browser treba da preuzme ono, možda više hintova znači više brzine.

Browseri već agresivno optimizuju. Vaš posao nije da mikromenadžujete svaki zahtev. Vaš posao je da ispravite nekoliko slučajeva u kojima browseru nedostaje informacija u pravom trenutku.

Često postavljana pitanja

Da li treba da preloadujem sve svoje fontove?
Ne. Preloadujte samo font fajlove potrebne za vidljiv tekst rano na stranici. Preload svake debljine i stila obično rasipa bandwidth i može odložiti važnije resurse.
Da li je prefetch bezbedno koristiti za svaki interni link?
Obično nije. Može stvoriti nepotreban pozadinski saobraćaj i trošiti korisničke podatke. Preferirajte prefetch zasnovan na nameri, na primer nakon hovera, fokusa, otvaranja menija ili predvidljivog sledećeg koraka.
Koja je razlika između preconnect i dns-prefetch?
Preconnect obavlja DNS, TCP i TLS uspostavljanje za origin. DNS-prefetch samo razrešava ime domena. Preconnect je snažniji, ali skuplji, pa ga treba koristiti sa većim nivoom sigurnosti.
Mogu li resource hints poboljšati Core Web Vitals?
Da, naročito LCP, kada poprave kasno otkrivanje ili uspostavljanje konekcije za kritični resurs. Neće pomoći ako je stvarni problem preveliki asseti, spor odgovor servera, render-blocking kod ili loše keširanje.
Da li resource hints treba dodavati u HTML ili HTTP zaglavlja?
Oba pristupa mogu raditi. HTML je lakši za razumevanje kod hintova specifičnih za stranicu. HTTP Link zaglavlja mogu biti korisna kada server zna kritične resurse pre parsiranja HTML-a, ali zahtevaju pažljivo testiranje da bi se izbegli duplikati ili zastareli hintovi.

Izvori i dalja literatura

  1. MDN: rel=preload
  2. MDN: Resource hints
  3. web.dev: Preconnect and DNS-prefetch
  4. W3C: Resource Hints
#performance #resource-hints #html #browser #optimization
O autoru
The Wux Webtools Team

Poslednje ažurirano:

Nastavite sa čitanjem