Preload, prefetch a preconnect: kdy skutečně pomáhají
Resource hints jsou užitečné, když odpovídají skutečným úzkým místům v prohlížeči. Použité naslepo přidávají šum v prioritách a někdy stránky zpomalují.
Obsah
- Resource hints nejsou kouzlo
- Co už prohlížeč umí dobře
- Preload: pro zdroje aktuální stránky objevené příliš pozdě
- Preload a LCP obrázky
- Prefetch: pro další stránku, ne tuto
- Preconnect: pro drahá spojení k důležitým originům
- DNS-prefetch: lehčí příbuzný
- Jak se rozhodnout: praktický workflow
- 1. Identifikujte úzké místo
- 2. Přidávejte jednu nápovědu po druhé
- 3. Zkontrolujte vedlejší dopady na priority
- 4. Ověřte hlavičky a caching
- Časté chyby
- Příliš mnoho preload
- Použití prefetch pro vyžadované zdroje
- Preconnect ke každé třetí straně
- Zapomínání na mobilní podmínky
- Jednoduchá rozhodovací tabulka
- Klidné pravidlo
Resource hints nejsou kouzlo
preload, prefetch a preconnect se často berou jako kontrolní seznam pro výkon. Přidat pár značek do <head>, znovu spustit Lighthouse a mít lepší pocit. Takto ale nefungují.
Tyto nápovědy jsou instrukce pro načítací pipeline prohlížeče. Mohou pomoct, když víte něco, co prohlížeč nedokáže zjistit dostatečně brzy. Mohou uškodit, když hádáte, přidělujete příliš vysokou prioritu nekritické práci nebo zahříváte spojení, která uživatelé nikdy nepotřebují.
Krátká verze:
- Používejte
preloadpro zdroje vyžadované aktuální stránkou, které jsou ale objeveny příliš pozdě. - Používejte
prefetchpro pravděpodobné zdroje budoucí navigace, ne pro nezbytnosti aktuální stránky. - Používejte
preconnectpro důležité third-party origins, u nichž je navázání spojení skutečným zpožděním.
Praktická otázka nezní „která nápověda je nejrychlejší?“ Zní „na co prohlížeč čeká a dokáže tato nápověda toto čekání odstranit?“
Co už prohlížeč umí dobře
Moderní prohlížeče nejsou pasivní stahovače souborů. Parsují HTML, dopředu skenují zdroje, přiřazují priority, znovu používají spojení, odkládají práci, která není viditelná, a přizpůsobují se síťovým podmínkám.
To znamená, že resource hints by měly být selektivní. Pokud je stylesheet, script, obrázek nebo font už objeven brzy a dostane správnou prioritu, přidání nápovědy nemusí udělat nic. Horší je, že může soupeřit se zdroji, na kterých záleží víc.
Než přidáte nápovědy, podívejte se na waterfall trace v DevTools nebo na laboratorní report. Pokud používáte Lighthouse, začněte diagnostikou, ne skóre; máme samostatný návod, jak číst report Lighthouse bez paniky — ale pozor, správná URL je case-sensitive, takže v případě potřeby použijte odkazovaný článek z navigace svého webu.
Skutečné důkazy bývají obvykle vidět na třech místech:
- Kritický zdroj začíná pozdě, protože ho prohlížeč objeví pozdě.
- Spojení k důležitému originu trvá znatelnou dobu před prvním požadavkem.
- Zdroj pro další stránku je vysoce předvídatelný a levný k načtení během nečinnosti.
Pokud nic z toho neplatí, nápověda je pravděpodobně jen dekorace.
Preload: pro zdroje aktuální stránky objevené příliš pozdě
preload říká prohlížeči: „Načti tento zdroj teď, protože ho aktuální stránka bude potřebovat.“
Typickým příkladem je webový font odkazovaný uvnitř CSS. Prohlížeč musí stáhnout HTML, objevit CSS, stáhnout CSS, parsovat ho, objevit font a teprve potom si font vyžádat. Pokud je tento font důležitý pro text nad ohybem stránky, objevení může přijít dost pozdě na to, aby způsobilo posuny layoutu nebo zpožděné vykreslení textu.
Preload může tento požadavek posunout dřív:
<link rel='preload' href='/fonts/inter-var.woff2' as='font' type='font/woff2' crossorigin>Na atributu as záleží. Říká prohlížeči, o jaký druh zdroje jde, což ovlivňuje prioritu, caching, content security policy a hlavičky požadavku. Fonty také obvykle potřebují crossorigin, i když jsou servírovány ze stejného webu, protože načítání fontů používá režim CORS.
Dobří kandidáti pro preload zahrnují:
- Primární webový font použitý pro viditelný text.
- Hero image, který je prvkem Largest Contentful Paint a není objevitelný brzy.
- Kritický CSS soubor načítaný nepřímo.
- Modul nebo script potřebný velmi brzy, ale skrytý za jiným scriptem.
Špatní kandidáti pro preload zahrnují:
- Každou tloušťku fontu v design systému.
- Obrázky pod ohybem stránky.
- Scripty, které nejsou potřeba pro počáteční vykreslení.
- Zdroje, které prohlížeč už objeví v prvním chunku HTML.
Preload je silný, protože ovlivňuje prioritu aktuální stránky. Právě proto se také snadno používá špatně. Pokud přednačtete pět velkých assetů, už prohlížeči nepomáháte. Hádáte se s ním.
Fonty jsou klasický případ. Přednačtení jednoho primárního souboru fontu může pomoct. Přednačtení šesti tlouštěk a kurzív obvykle věci zhorší. Pokud jsou vaším úzkým místem fonty, nejprve opravte sadu fontů; náš průvodce tím, proč jsou webové fonty na většině webů stále nejsnazším výkonnostním vítězstvím, popisuje tento úklid podrobněji.
Preload a LCP obrázky
Přednačtení LCP obrázku může být užitečné, když obrázek není viditelný v počátečním HTML. Mezi časté příčiny patří CSS background images, client-rendered komponenty nebo responzivní logika obrázků, která se objeví pozdě.
Pokud je ale váš hero image už v HTML jako <img> se smysluplným srcset, sizes, rozměry a bez lazy loadingu, prohlížeč ho pravděpodobně najde rychle. V takovém případě může být podle stránky vhodnější přidat fetchpriority='high' než preload.
Dobrý test: pokud požadavek na obrázek začíná ve waterfall pozdě a stane se prvkem LCP, zvažte preload. Pokud začíná brzy, ale stahuje se pomalu, problémem je velikost, formát, chování CDN nebo latence serveru — ne objevení. K rozhodování o formátu obrázků viz kdy AVIF překoná WebP a kdy ne.
Prefetch: pro další stránku, ne tuto
prefetch říká prohlížeči: „Tento zdroj může být brzy potřeba, ale není vyžadován právě teď.“
Toto rozlišení je důležité. Prefetch má záměrně nízkou prioritu. Prohlížeč ho může načíst během nečinnosti a uložit pro pozdější použití. Může ho také přeskočit při špatném připojení, v režimech úspory dat nebo pod tlakem na paměť.
Používejte prefetch, když je záměr uživatele dost silný na to, aby byl další zdroj pravděpodobný.
Dobří kandidáti pro prefetch zahrnují:
- Další krok ve vícestránkovém checkoutu.
- Výsledky vyhledávání poté, co uživatel začne psát dotaz, pokud je další route předvídatelná.
- Dokumentační stránky odkazované z obsahu, když uživatel aktivně čte okolní obsah.
- Route chunky v single-page app poté, co uživatel najede myší na navigační položku nebo ji zaměří.
Špatní kandidáti pro prefetch zahrnují:
- Celý váš navigační strom.
- Velká videa nebo galerie obrázků.
- Third-party scripty „pro jistotu“.
- Stránky, které uživatelé jen zřídka navštíví jako další.
Prefetch je místo, kde se zdrženlivost vyplácí. Zdroj načtený a nikdy nepoužitý není zadarmo. Spotřebovává bandwidth, kapacitu serveru, energii a případně data uživatele. Na mobilních sítích může být spekulativní načítání aktivně nepřívětivé.
Pro mnoho webů je nejlepší strategie prefetch založená na záměru. Nepřednačíte stránku s cenami hned po načtení domovské stránky. Přednačtěte ji, když uživatel otevře cenové menu, najede na odkaz ceníku nebo doscrolluje k call-to-action, které silně předpovídá navigaci.
Pamatujte také, že chování prohlížečů se liší. Některé prohlížeče jsou s prefetch konzervativní; některá nastavení soukromí spekulativní načítání omezují nebo vypínají. Berte prefetch jako oportunistické vylepšení, ne jako mechanismus správnosti.
Preconnect: pro drahá spojení k důležitým originům
preconnect říká prohlížeči: „Začni teď navazovat spojení k tomuto originu.“
To může zahrnovat DNS lookup, TCP connection a TLS negotiation. U third-party origins může toto navázání trvat stovky milisekund, zejména na sítích s vysokou latencí. Pokud stránka brzy potřebuje kritický požadavek z tohoto originu, preconnect může pozdější požadavek urychlit.
Příklad:
<link rel='preconnect' href='https://fonts.gstatic.com' crossorigin>Dobří kandidáti pro preconnect zahrnují:
- Font origin použitý pro render-blocking text.
- Kritický API origin potřebný během počáteční interakce.
- CDN origin servírující assety nad ohybem stránky.
- Platební nebo identitní provider potřebný bezprostředně po akci uživatele.
Špatní kandidáti pro preconnect zahrnují:
- Analytics a reklamní endpointy, které nejsou pro uživatele kritické.
- Originy používané jen v některých relacích.
- Dlouhé seznamy třetích stran.
- Same-origin zdroje, kde prohlížeč spojení už má nebo ho brzy otevře.
Preconnect má náklady na držení. Otevřené sockety spotřebovávají paměť a síťové zdroje. Prohlížeče nevyužitá spojení zavřou, ale to zbytečné preconnecty nečiní neškodnými.
Užitečné pravidlo: na stránce použijte preconnect nejvýše k jednomu nebo dvěma third-party originům s vysokou jistotou. Pokud máte chuť přidat další, vaše third-party architektura pravděpodobně potřebuje revizi víc než vaše nápovědy rozšíření.
DNS-prefetch: lehčí příbuzný
Můžete se setkat také s dns-prefetch:
<link rel='dns-prefetch' href='https://example-cdn.com'>Ten pouze přeloží název domény. Neotevírá TCP ani TLS spojení. Je levnější než preconnect, ale také méně užitečný.
DNS-prefetch může dávat smysl pro third-party origins s nižší jistotou, kde plný preconnect působí příliš agresivně. V praxi platí: pokud je origin kritický a určitě bude brzy použit, dejte přednost preconnect. Pokud je to jen možné, použijte buď DNS-prefetch, nebo nedělejte nic.
Jak se rozhodnout: praktický workflow
Začněte měřením, ne značkami.
1. Identifikujte úzké místo
Otevřete performance trace a hledejte pozdní objevení. Začal požadavek na font, hero image nebo script až poté, co byl stažen a parsován jiný soubor? To je kandidát na preload.
Pokud požadavek začíná až po dlouhém DNS/TCP/TLS navazování k third-party originu, je to kandidát na preconnect.
Pokud je aktuální stránka v pořádku, ale další navigace je předvídatelně pomalá, může pomoct prefetch.
2. Přidávejte jednu nápovědu po druhé
Resource hints se navzájem ovlivňují. Přidejte jednu, otestujte ji a ponechte ji jen tehdy, když se waterfall zlepší a metriky viditelné pro uživatele se nezhorší.
U preload sledujte, zda je naznačený zdroj skutečně brzy použit. Chrome může varovat, když přednačtený zdroj není krátce po načtení použit. Berte toto varování vážně.
3. Zkontrolujte vedlejší dopady na priority
Preload může odtáhnout bandwidth od CSS, JavaScriptu nebo obrázků, na kterých záleží víc. Preconnect může obsadit slot pro spojení. Prefetch může přidat provoz na pozadí.
Správný výsledek není „naznačený soubor začíná dřív“. Správný výsledek je „stránka je pro uživatele smysluplně lepší“. Sledujte LCP, INP, CLS a pokud možno real-user monitoring.
4. Ověřte hlavičky a caching
Nápovědy lze posílat v HTML nebo v HTTP Link headers. Hlavičky jsou užitečné, když server brzy ví, co bude stránka potřebovat, ale hůř se zběžně kontrolují. Pokud ladíte, zda je nápověda skutečně přítomná v produkci, raw headers jsou důležité; přesně takové situaci se věnuje náš průvodce laděním redirectů a HTTP hlaviček.
Záleží také na cachingu. Preload zdroje s nesouladnými credentials, špatným as nebo jinými parametry URL může způsobit duplicitní stahování. To je jeden z nejběžnějších způsobů, jak se dobře míněný preload změní ve výkonnostní chybu.
Časté chyby
Příliš mnoho preload
Pokud je kritické všechno, není kritické nic. Omezte preload na zdroje potřebné pro počáteční vykreslení nebo okamžitou interaktivitu. Typická stránka by měla mít nula až tři preloads, ne dvacet.
Použití prefetch pro vyžadované zdroje
Prefetch má nízkou prioritu a je volitelný. Nepoužívejte ho pro assety vyžadované aktuální stránkou. Pokud je stránka potřebuje teď, zvažte preload nebo běžné objevení přes HTML.
Preconnect ke každé třetí straně
Stránky zatížené third-party zdroji mají často deset nebo více externích originů. Preconnect ke všem vytváří šum. Vyberte jeden nebo dva, které jsou kritické a zároveň předvídatelně používané.
Zapomínání na mobilní podmínky
Resource hints jsou nejcennější na pomalejších připojeních, ale tam jsou také nejnebezpečnější. Zbytečný prefetch na rychlém desktopovém připojení je zaokrouhlovací chyba. U omezeného mobilního tarifu je to špatná výměna.
Jednoduchá rozhodovací tabulka
| Situace | Nejlepší nápověda | Proč | |---|---:|---| | Kritický font objevený přes CSS | preload | Aktuální stránka ho potřebuje, objevení je pozdní | | Hero image skrytý za CSS nebo client renderingem | preload | Může zlepšit LCP, pokud obrázek začíná pozdě | | Pravděpodobná další route po záměru uživatele | prefetch | Pomáhá budoucí navigaci bez blokování aktuální stránky | | Kritický third-party font/API origin | preconnect | Odstraňuje navázání spojení z kritické cesty | | Možný, ale nejistý third-party origin | dns-prefetch nebo nic | Nižší náklady, nižší jistota | | Obrázek pod ohybem stránky | nic | Nechte fungovat lazy loading a prioritu prohlížeče |
Klidné pravidlo
Resource hints fungují nejlépe, když jsou nudné a konkrétní. Jeden font. Jeden LCP obrázek. Jeden důležitý third-party origin. Jedna pravděpodobná další route po projeveném záměru.
Fungují špatně, když se používají jako optimismus: možná to uživatel bude potřebovat, možná by prohlížeč měl načíst tamto, možná více nápověd znamená více rychlosti.
Prohlížeče už optimalizují agresivně. Vaším úkolem není mikromanagovat každý požadavek. Vaším úkolem je opravit těch několik případů, kdy prohlížeči ve správný okamžik chybí informace.
Často kladené otázky
Mám použít preload pro všechny své fonty?
Je bezpečné používat prefetch pro každý interní odkaz?
Jaký je rozdíl mezi preconnect a dns-prefetch?
Mohou resource hints zlepšit Core Web Vitals?
Mají se resource hints přidávat v HTML, nebo v HTTP hlavičkách?
Zdroje a další čtení
