Web Performance

Preload, prefetch a preconnect: kedy každý z nich skutočne pomáha

Resource hints sú užitočné vtedy, keď zodpovedajú skutočným úzkym miestam v prehliadači. Pri slepom používaní pridávajú šum v prioritách a niekedy stránky spomaľujú.

The Wux Webtools Team The Wux Webtools Team 12 min čítania Pomocou AI, kontrolované človekom
A simplified browser loading waterfall showing early resource hints for a web page.
Obsah
  1. Resource hints nie sú mágia
  2. Čo už prehliadač zvláda dobre
  3. Preload: pre zdroje aktuálnej stránky objavené príliš neskoro
  4. Preload a LCP obrázky
  5. Prefetch: pre ďalšiu stránku, nie túto
  6. Preconnect: pre drahé spojenia s dôležitými originmi
  7. DNS-prefetch: ľahší príbuzný
  8. Ako sa rozhodnúť: praktický postup
  9. 1. Identifikujte úzke miesto
  10. 2. Pridávajte vždy jeden hint
  11. 3. Skontrolujte vedľajšie účinky priorít
  12. 4. Overte hlavičky a cacheovanie
  13. Bežné chyby
  14. Príliš veľa preloadu
  15. Používanie prefetchu pre povinné zdroje
  16. Preconnect ku každej third party
  17. Zabúdanie na mobilné podmienky
  18. Jednoduchá rozhodovacia tabuľka
  19. Pokojné pravidlo

Resource hints nie sú mágia

preload, prefetch a preconnect sa často berú ako kontrolný zoznam výkonu. Pridať pár tagov do <head>, znova spustiť Lighthouse, mať lepší pocit. Takto však nefungujú.

Tieto hinty sú pokyny pre načítavaciu pipeline prehliadača. Môžu pomôcť, keď viete niečo, čo prehliadač nedokáže zistiť dostatočne skoro. Môžu uškodiť, keď hádate, príliš uprednostníte nekritickú prácu alebo predhrievate spojenia, ktoré používatelia nikdy nebudú potrebovať.

Krátka verzia:

  • Použite preload pre zdroje potrebné pre aktuálnu stránku, ktoré sa však objavia príliš neskoro.
  • Použite prefetch pre pravdepodobné zdroje budúcej navigácie, nie pre nevyhnutnosti aktuálnej stránky.
  • Použite preconnect pre dôležité third-party originy, pri ktorých je nadviazanie spojenia skutočným oneskorením.

Praktická otázka neznie „ktorý hint je najrýchlejší?“ Znie: „na čo prehliadač čaká a dokáže tento hint toto čakanie odstrániť?“

Čo už prehliadač zvláda dobre

Moderné prehliadače nie sú pasívne sťahovače súborov. Parsujú HTML, skenujú dopredu zdroje, priraďujú priority, opätovne používajú spojenia, odkladajú prácu, ktorá nie je viditeľná, a prispôsobujú sa sieťovým podmienkam.

To znamená, že resource hints by sa mali používať selektívne. Ak je stylesheet, script, image alebo font už objavený skoro a má správnu prioritu, pridanie hintu nemusí urobiť nič. Horšie je, že môže súťažiť so zdrojmi, na ktorých záleží viac.

Pred pridaním hintov si pozrite waterfall trace v DevTools alebo laboratórny report. Ak používate Lighthouse, začnite diagnostikou, nie skóre; máme samostatný návod, ako čítať Lighthouse report bez paniky — no všimnite si, že správna URL rozlišuje veľké a malé písmená, preto v prípade potreby použite prepojený článok z navigácie svojho webu.

Skutočný dôkaz býva zvyčajne viditeľný na troch miestach:

  1. Kritický zdroj sa začne načítavať neskoro, pretože ho prehliadač objaví neskoro.
  2. Spojenie s dôležitým originom trvá citeľne dlho pred prvou požiadavkou.
  3. Zdroj pre ďalšiu stránku je veľmi predvídateľný a lacno sa dá načítať v nečinnosti.

Ak nič z toho neplatí, hint je pravdepodobne len dekorácia.

Preload: pre zdroje aktuálnej stránky objavené príliš neskoro

preload hovorí prehliadaču: „Načítaj tento zdroj teraz, pretože aktuálna stránka ho bude potrebovať.“

Typickým príkladom je webový font odkazovaný v CSS. Prehliadač musí stiahnuť HTML, objaviť CSS, stiahnuť CSS, sparsovať ho, objaviť font a až potom si font vyžiadať. Ak je tento font dôležitý pre text nad ohybom stránky, objavenie môže byť dosť neskoré na to, aby spôsobilo posuny rozloženia alebo oneskorené vykreslenie textu.

Preload môže túto požiadavku posunúť skôr:

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

Na atribúte as záleží. Hovorí prehliadaču, o aký typ zdroja ide, čo ovplyvňuje prioritu, cacheovanie, content security policy a hlavičky požiadavky. Fonty tiež zvyčajne potrebujú crossorigin, aj keď sú servované z toho istého webu, pretože načítavanie fontov používa režim CORS.

Dobré kandidáty na preload zahŕňajú:

  • Primárny webový font použitý pre viditeľný text.
  • Hero image, ktorý je prvkom Largest Contentful Paint a nedá sa objaviť skoro.
  • Kritický CSS súbor načítaný nepriamo.
  • Modul alebo script potrebný veľmi skoro, no skrytý za iným scriptom.

Zlé kandidáty na preload zahŕňajú:

  • Každú hrúbku fontu v design systeme.
  • Obrázky pod ohybom stránky.
  • Scripty, ktoré nie sú potrebné pre počiatočné vykreslenie.
  • Zdroje, ktoré prehliadač už objaví v prvom kúsku HTML.

Preload je silný, pretože ovplyvňuje prioritu aktuálnej stránky. Práve preto sa dá aj ľahko použiť nesprávne. Ak preloadujete päť veľkých assetov, prehliadaču už nepomáhate. Hádate sa s ním.

Fonty sú klasický prípad. Preload jedného primárneho súboru fontu môže pomôcť. Preload šiestich hrúbok a kurzív zvyčajne veci zhorší. Ak sú fonty vaše úzke miesto, najprv upracte sadu fontov; náš sprievodca tým, prečo web fonts sú stále najjednoduchšou výkonnostnou výhrou na väčšine webov, tento poriadok rozoberá podrobnejšie.

Preload a LCP obrázky

Preload LCP obrázka môže byť užitočný, keď obrázok nie je viditeľný v počiatočnom HTML. Bežné príčiny zahŕňajú CSS background images, klientom renderované komponenty alebo responzívnu logiku obrázkov, ktorá sa objaví neskoro.

Ak je však váš hero image už v HTML ako <img> so zmysluplnými srcset, sizes, rozmermi a bez lazy loadingu, prehliadač ho pravdepodobne nájde rýchlo. V takom prípade môže byť v závislosti od stránky vhodnejšie pridať fetchpriority='high' než preload.

Dobrý test: ak sa požiadavka na obrázok vo waterfalle začne neskoro a obrázok sa stane LCP prvkom, zvážte preload. Ak sa začne skoro, ale sťahuje sa pomaly, problémom je veľkosť, formát, správanie CDN alebo latencia servera — nie objavenie. Pri rozhodovaní o formátoch obrázkov si pozrite kedy AVIF poráža WebP a kedy nie.

Prefetch: pre ďalšiu stránku, nie túto

prefetch hovorí prehliadaču: „Tento zdroj môže byť čoskoro potrebný, ale nie je potrebný práve teraz.“

Toto rozlíšenie je dôležité. Prefetch má zámerne nízku prioritu. Prehliadač ho môže načítať počas nečinnosti a uložiť na neskoršie použitie. Môže ho tiež preskočiť pri slabých spojeniach, v režimoch šetrenia dát alebo pri tlaku na pamäť.

Používajte prefetch vtedy, keď je zámer používateľa dostatočne silný na to, aby bol ďalší zdroj pravdepodobný.

Dobré kandidáty na prefetch zahŕňajú:

  • Ďalší krok vo viacstránkovom checkout procese.
  • Výsledky vyhľadávania po tom, čo používateľ začne písať dopyt, ak je ďalšia route predvídateľná.
  • Stránky dokumentácie odkazované z obsahu, keď používateľ aktívne číta blízky obsah.
  • Route chunky v single-page app po tom, čo používateľ prejde myšou alebo zameria navigačnú položku.

Zlé kandidáty na prefetch zahŕňajú:

  • Celý váš navigačný strom.
  • Veľké videá alebo obrázkové galérie.
  • Third-party scripty „pre istotu“.
  • Stránky, ktoré používatelia zriedka navštívia ako ďalšie.

Pri prefetchi sa striedmosť vypláca. Zdroj, ktorý sa načíta a nikdy nepoužije, nie je zadarmo. Spotrebúva šírku pásma, kapacitu servera, energiu a prípadne dáta používateľa. V mobilných sieťach môže byť špekulatívne načítavanie vyslovene neohľaduplné.

Pre mnohé weby je najlepšia stratégia prefetchu založená na zámere. Neprefetchujte pricing page hneď po načítaní home page. Prefetchujte ju vtedy, keď používateľ otvorí pricing menu, prejde myšou nad pricing link alebo doscrolluje blízko call-to-action, ktorý silno predpovedá navigáciu.

Pamätajte tiež, že správanie prehliadačov sa líši. Niektoré prehliadače sú pri prefetchi konzervatívne; niektoré nastavenia súkromia obmedzujú alebo vypínajú špekulatívne načítavanie. Berte prefetch ako oportunistické zlepšenie, nie ako mechanizmus správnosti.

Preconnect: pre drahé spojenia s dôležitými originmi

preconnect hovorí prehliadaču: „Začni teraz pripravovať spojenie s týmto originom.“

To môže zahŕňať DNS lookup, TCP connection a TLS negotiation. Pri third-party originoch môže toto nastavenie trvať stovky milisekúnd, najmä v sieťach s vysokou latenciou. Ak stránka čoskoro potrebuje kritickú požiadavku z tohto originu, preconnect môže neskoršiu požiadavku zrýchliť.

Príklad:

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

Dobré kandidáty na preconnect zahŕňajú:

  • Font origin použitý pre text blokujúci renderovanie.
  • Kritický API origin potrebný počas počiatočnej interakcie.
  • CDN origin servujúci assety nad ohybom stránky.
  • Poskytovateľ platieb alebo identity potrebný okamžite po akcii používateľa.

Zlé kandidáty na preconnect zahŕňajú:

  • Analytics a advertising endpointy, ktoré nie sú kritické pre používateľa.
  • Originy používané iba v niektorých reláciách.
  • Dlhé zoznamy third parties.
  • Same-origin zdroje, pri ktorých už prehliadač spojenie má alebo ho čoskoro otvorí.

Preconnect má náklady na udržiavanie. Otvorené sockety spotrebúvajú pamäť a sieťové zdroje. Prehliadače nepoužité spojenia zavrú, ale to zbytočné preconnecty nerobí neškodnými.

Užitočné pravidlo: na stránke používajte preconnect najviac na jeden alebo dva vysoko isté third-party originy. Ak vás láka pridať viac, vaša third-party architektúra pravdepodobne potrebuje revíziu viac než vaše hinty rozšírenie.

DNS-prefetch: ľahší príbuzný

Môžete sa stretnúť aj s dns-prefetch:

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

Toto iba rozlíši názov domény. Neotvára TCP ani TLS spojenie. Je lacnejší než preconnect, ale aj menej užitočný.

DNS-prefetch môže dávať zmysel pri third-party originoch s nižšou istotou, kde plný preconnect pôsobí príliš agresívne. V praxi platí: ak je origin kritický a určite sa čoskoro použije, uprednostnite preconnect. Ak je to iba možné, použite buď DNS-prefetch, alebo neurobte nič.

Ako sa rozhodnúť: praktický postup

Začnite meraním, nie tagmi.

1. Identifikujte úzke miesto

Otvorte performance trace a hľadajte neskoré objavenie. Začala požiadavka na font, hero image alebo script až po stiahnutí a sparsovaní iného súboru? To je kandidát na preload.

Ak sa požiadavka začne až po dlhom DNS/TCP/TLS nastavovaní voči third-party originu, je to kandidát na preconnect.

Ak je aktuálna stránka v poriadku, ale ďalšia navigácia je predvídateľne pomalá, môže pomôcť prefetch.

2. Pridávajte vždy jeden hint

Resource hints sa navzájom ovplyvňujú. Pridajte jeden, otestujte ho a nechajte ho iba vtedy, ak sa waterfall zlepší a metriky viditeľné pre používateľa sa nezhoršia.

Pri preloade sledujte, či sa naznačený zdroj skutočne čoskoro použije. Chrome môže upozorniť, keď sa preloadovaný zdroj nepoužije krátko po načítaní. Berte toto upozornenie vážne.

3. Skontrolujte vedľajšie účinky priorít

Preload môže odobrať šírku pásma CSS, JavaScriptu alebo obrázkom, na ktorých záleží viac. Preconnect môže obsadiť connection slot. Prefetch môže pridať prevádzku na pozadí.

Správny výsledok nie je „naznačený súbor sa začne skôr“. Správny výsledok je „stránka sa pre používateľov zmysluplne zlepší“. Sledujte LCP, INP, CLS a tam, kde je to možné, real-user monitoring.

4. Overte hlavičky a cacheovanie

Hinty sa dajú posielať v HTML alebo v HTTP Link hlavičkách. Hlavičky sú užitočné, keď server už skoro vie, čo bude stránka potrebovať, no náhodne sa kontrolujú ťažšie. Ak debugujete, či je hint v produkcii skutočne prítomný, záleží na raw hlavičkách; presne takýto typ situácie pokrýva náš sprievodca debugovaním redirectov a HTTP hlavičiek.

Záleží aj na cacheovaní. Preload zdroja s nezhodnými credentials, nesprávnym as alebo odlišnými URL parametrami môže spôsobiť duplicitné sťahovania. Je to jeden z najčastejších spôsobov, ako sa dobre myslený preload stane výkonnostnou chybou.

Bežné chyby

Príliš veľa preloadu

Ak je kritické všetko, nie je kritické nič. Obmedzte preload na zdroje potrebné pre počiatočné vykreslenie alebo okamžitú interaktivitu. Typická stránka by mala mať nula až tri preloads, nie dvadsať.

Používanie prefetchu pre povinné zdroje

Prefetch má nízku prioritu a je voliteľný. Nepoužívajte ho pre assety, ktoré aktuálna stránka vyžaduje. Ak ho stránka potrebuje teraz, zvážte preload alebo bežné objavenie cez HTML.

Preconnect ku každej third party

Stránky s veľkým množstvom third-party prvkov často majú desať alebo viac externých originov. Preconnect ku všetkým vytvára šum. Vyberte jeden alebo dva, ktoré sú zároveň kritické a predvídateľne používané.

Zabúdanie na mobilné podmienky

Resource hints sú najcennejšie na pomalších spojeniach, no práve tam sú aj najnebezpečnejšie. Premrhaný prefetch na rýchlom desktopovom pripojení je zanedbateľný. Pri obmedzenom mobilnom paušáli je to zlý obchod.

Jednoduchá rozhodovacia tabuľka

| Situácia | Najlepší hint | Prečo | |---|---:|---| | Kritický font objavený cez CSS | preload | Aktuálna stránka ho potrebuje, objavenie je neskoré | | Hero image skrytý za CSS alebo klientskym renderovaním | preload | Môže zlepšiť LCP, ak sa obrázok začne načítavať neskoro | | Pravdepodobná ďalšia route po zámere používateľa | prefetch | Pomáha budúcej navigácii bez blokovania aktuálnej stránky | | Kritický third-party font/API origin | preconnect | Odstraňuje nastavovanie spojenia z kritickej cesty | | Možný, ale neistý third-party origin | dns-prefetch alebo nič | Nižšie náklady, nižšia istota | | Obrázok pod ohybom stránky | nič | Nechajte pracovať lazy loading a priority prehliadača |

Pokojné pravidlo

Resource hints fungujú najlepšie, keď sú nudné a konkrétne. Jeden font. Jeden LCP obrázok. Jeden dôležitý third-party origin. Jedna pravdepodobná ďalšia route po prejavení zámeru.

Fungujú zle, keď sa používajú ako optimizmus: možno to používateľ bude potrebovať, možno by mal prehliadač načítať tamto, možno viac hintov znamená viac rýchlosti.

Prehliadače už optimalizujú agresívne. Vašou úlohou nie je mikromanažovať každú požiadavku. Vašou úlohou je opraviť tých pár prípadov, v ktorých prehliadaču v správnom momente chýba informácia.

Často kladené otázky

Mal by som preloadovať všetky svoje fonty?
Nie. Preloadujte iba súbory fontov potrebné pre viditeľný text na začiatku stránky. Preload každej hrúbky a štýlu zvyčajne plytvá šírkou pásma a môže oneskoriť dôležitejšie zdroje.
Je bezpečné používať prefetch pre každý interný odkaz?
Zvyčajne nie. Môže vytvárať zbytočnú prevádzku na pozadí a míňať dáta používateľa. Uprednostnite prefetch založený na zámere, napríklad po hoveri, focuse, otvorení menu alebo pri predvídateľnom ďalšom kroku.
Aký je rozdiel medzi preconnect a dns-prefetch?
Preconnect vykoná DNS, TCP a TLS nastavenie pre origin. DNS-prefetch iba rozlíši názov domény. Preconnect je silnejší, ale nákladnejší, preto by sa mal používať s väčšou istotou.
Môžu resource hints zlepšiť Core Web Vitals?
Áno, najmä LCP, keď opravujú neskoré objavenie alebo nastavovanie spojenia pre kritický zdroj. Nepomôžu, ak je skutočným problémom príliš veľký asset, pomalá odozva servera, render-blocking kód alebo zlé cacheovanie.
Mali by sa resource hints pridávať v HTML alebo v HTTP hlavičkách?
Fungovať môže oboje. HTML sa pri hintoch špecifických pre stránku ľahšie posudzuje. HTTP Link hlavičky môžu byť užitočné, keď server pozná kritické zdroje ešte pred parsovaním HTML, no vyžadujú dôkladné testovanie, aby nevznikli duplicity alebo zastarané hinty.

Zdroje a ďalšie čítanie

  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 autorovi
The Wux Webtools Team

Posledná aktualizácia:

Pokračujte v čítaní