Web Performance

Preload, prefetch ir preconnect: kada kiekvienas iš jų iš tiesų padeda

Resource hints naudingi tada, kai atitinka tikras naršyklės kliūtis. Naudojami aklai, jie sukuria prioritetų triukšmą ir kartais sulėtina puslapius.

The Wux Webtools Team The Wux Webtools Team 10 min skaityti Pagal AI, peržiūrėta žmogaus
A simplified browser loading waterfall showing early resource hints for a web page.
Turinys
  1. Resource hints nėra magija
  2. Ką naršyklė jau daro gerai
  3. Preload: dabartinio puslapio ištekliams, aptinkamiems per vėlai
  4. Preload ir LCP vaizdai
  5. Prefetch: kitam puslapiui, ne šiam
  6. Preconnect: brangiems ryšiams su svarbiomis kilmėmis
  7. DNS-prefetch: lengvesnis giminaitis
  8. Kaip nuspręsti: praktinė eiga
  9. 1. Nustatykite kliūtį
  10. 2. Pridėkite po vieną užuominą
  11. 3. Patikrinkite prioritetų šalutinius poveikius
  12. 4. Patikrinkite antraštes ir talpyklą
  13. Dažnos klaidos
  14. Per daug preload
  15. Prefetch naudojimas būtiniems ištekliams
  16. Preconnect su kiekviena trečiąja šalimi
  17. Mobiliųjų sąlygų pamiršimas
  18. Paprasta sprendimų lentelė
  19. Rami taisyklė

Resource hints nėra magija

preload, prefetch ir preconnect dažnai laikomi našumo kontroliniu sąrašu. Į <head> pridėkite kelias žymas, dar kartą paleiskite Lighthouse ir pasijuskite geriau. Taip jie neveikia.

Šios užuominos yra instrukcijos naršyklės įkėlimo procesui. Jos gali padėti, kai žinote tai, ko naršyklė negali pakankamai anksti aptikti pati. Jos gali pakenkti, kai spėjate, per daug sureikšminate nekritinį darbą arba iš anksto paruošiate ryšius, kurių naudotojams niekada neprireiks.

Trumpai:

  • Naudokite preload ištekliams, kurių reikia dabartiniam puslapiui, bet kurie aptinkami per vėlai.
  • Naudokite prefetch tikėtiniems būsimos navigacijos ištekliams, o ne dabartinio puslapio būtinybėms.
  • Naudokite preconnect svarbioms trečiųjų šalių kilmėms, kai ryšio užmezgimas iš tiesų sukelia delsą.

Praktinis klausimas nėra „kuri užuomina greičiausia?“ Jis yra „ko laukia naršyklė ir ar ši užuomina gali tą laukimą pašalinti?“

Ką naršyklė jau daro gerai

Šiuolaikinės naršyklės nėra pasyvios failų atsisiuntėjos. Jos analizuoja HTML, iš anksto skenuoja išteklius, priskiria prioritetus, pakartotinai naudoja ryšius, atideda nematomą darbą ir prisitaiko prie tinklo sąlygų.

Tai reiškia, kad resource hints turėtų būti naudojami pasirinktinai. Jei stilių failas, scenarijus, vaizdas ar šriftas jau aptinkamas anksti ir gauna tinkamą prioritetą, papildoma užuomina gali nieko nepakeisti. Dar blogiau — ji gali konkuruoti su svarbesniais ištekliais.

Prieš pridėdami užuominų, pažiūrėkite į waterfall pėdsaką DevTools arba laboratorinę ataskaitą. Jei naudojate Lighthouse, pradėkite nuo diagnostikos, o ne nuo balo; turime atskirą vadovą, kaip skaityti Lighthouse ataskaitą nepanikuojant — tačiau atkreipkite dėmesį, kad teisingas URL yra jautrus raidžių registrui, todėl prireikus naudokite susietą straipsnį iš savo svetainės navigacijos.

Tikrieji įrodymai paprastai matomi trijose vietose:

  1. Kritinis išteklius pradedamas krauti vėlai, nes naršyklė jį aptinka vėlai.
  2. Ryšys su svarbia kilme užtrunka pastebimai ilgai iki pirmos užklausos.
  3. Kito puslapio išteklius yra labai nuspėjamas ir pigus atsisiųsti neveikos metu.

Jei nė vienas iš šių teiginių netinka, užuomina greičiausiai yra tik dekoracija.

Preload: dabartinio puslapio ištekliams, aptinkamiems per vėlai

preload naršyklei sako: „Atsisiųsk šį išteklių dabar, nes dabartiniam puslapiui jo reikės.“

Tipinis pavyzdys — žiniatinklio šriftas, nurodytas CSS viduje. Naršyklė turi atsisiųsti HTML, aptikti CSS, atsisiųsti CSS, jį išanalizuoti, aptikti šriftą ir tik tada paprašyti šrifto. Jei tas šriftas svarbus matomam tekstui virš pirmo ekrano, aptikimas gali būti pakankamai vėlyvas, kad sukeltų maketo poslinkius arba uždelstą teksto atvaizdavimą.

Preload gali perkelti tą užklausą anksčiau:

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

as atributas svarbus. Jis naršyklei pasako, kokio tipo tai išteklius, o tai veikia prioritetą, talpyklą, turinio saugumo politiką ir užklausos antraštes. Šriftams taip pat paprastai reikia crossorigin, net kai jie pateikiami iš tos pačios svetainės, nes šriftų gavimas naudoja CORS režimą.

Geri preload kandidatai:

  • Pagrindinis žiniatinklio šriftas, naudojamas matomam tekstui.
  • Hero vaizdas, kuris yra Largest Contentful Paint elementas ir nėra aptinkamas anksti.
  • Kritinis CSS failas, įkeliamas netiesiogiai.
  • Modulis arba scenarijus, kurio reikia labai anksti, bet kuris paslėptas už kito scenarijaus.

Blogi preload kandidatai:

  • Kiekvienas šrifto svoris dizaino sistemoje.
  • Vaizdai žemiau pirmo ekrano.
  • Scenarijai, kurių nereikia pradiniam atvaizdavimui.
  • Ištekliai, kuriuos naršyklė jau aptinka pirmajame HTML fragmente.

Preload yra galingas, nes veikia dabartinio puslapio prioritetą. Būtent todėl jį lengva panaudoti netinkamai. Jei iš anksto įkeliate penkis didelius išteklius, naršyklei nebepadeda­te. Jūs su ja ginčijatės.

Šriftai yra klasikinis atvejis. Vieno pagrindinio šrifto failo preload gali padėti. Šešių svorių ir kursyvų preload paprastai pablogina padėtį. Jei šriftai yra jūsų kliūtis, pirmiausia sutvarkykite šriftų rinkinį; mūsų vadove apie tai, kodėl web fonts are still the easiest performance win on most sites, šis valymas aptariamas išsamiau.

Preload ir LCP vaizdai

LCP vaizdo preload gali būti naudingas, kai vaizdas nėra matomas pradiniame HTML. Dažnos priežastys: CSS fono vaizdai, kliento pusėje atvaizduojami komponentai arba vėlai pasirodanti responsive image logika.

Bet jei jūsų hero vaizdas jau yra HTML kaip <img> su protingais srcset, sizes, matmenimis ir be lazy loading, naršyklė tikriausiai gali jį greitai rasti. Tokiu atveju, priklausomai nuo puslapio, fetchpriority='high' pridėjimas gali būti tinkamesnis nei preload.

Geras testas: jei vaizdo užklausa waterfall diagramoje prasideda vėlai ir tampa LCP elementu, apsvarstykite preload. Jei ji prasideda anksti, bet siunčiasi lėtai, problema yra dydis, formatas, CDN elgsena arba serverio delsa — ne aptikimas. Dėl vaizdų formato sprendimų žr. when AVIF beats WebP and when it does not.

Prefetch: kitam puslapiui, ne šiam

prefetch naršyklei sako: „Šio ištekliaus netrukus gali prireikti, bet jo nereikia dabar.“

Šis skirtumas svarbus. Prefetch sąmoningai yra žemo prioriteto. Naršyklė gali jį atsisiųsti neveikos metu ir išsaugoti vėlesniam naudojimui. Ji taip pat gali jį praleisti prastų ryšių, duomenų taupymo režimų arba atminties spaudimo atvejais.

Naudokite prefetch tada, kai naudotojo ketinimas pakankamai stiprus, kad kitas išteklius būtų tikėtinas.

Geri prefetch kandidatai:

  • Kitas žingsnis kelių puslapių atsiskaitymo procese.
  • Paieškos rezultatai naudotojui pradėjus vesti užklausą, jei kitas maršrutas nuspėjamas.
  • Dokumentacijos puslapiai, susieti iš turinio lentelės, kai naudotojas aktyviai skaito netoliese esantį turinį.
  • Maršrutų fragmentai vieno puslapio programoje po to, kai naudotojas užveda pelę ant navigacijos elemento arba jį sufokusuoja.

Blogi prefetch kandidatai:

  • Visas jūsų navigacijos medis.
  • Dideli vaizdo įrašai arba vaizdų galerijos.
  • Trečiųjų šalių scenarijai „dėl visa ko“.
  • Puslapiai, į kuriuos naudotojai retai eina toliau.

Prefetch yra sritis, kur santūrumas atsiperka. Atsisiųstas ir niekada nepanaudotas išteklius nėra nemokamas. Jis naudoja pralaidumą, serverio pajėgumus, energiją ir galbūt naudotojo duomenis. Mobiliuosiuose tinkluose spekuliatyvus atsisiuntimas gali būti aktyviai nedraugiškas.

Daugeliui svetainių geriausia prefetch strategija yra pagrįsta ketinimu. Nenaudokite prefetch kainodaros puslapiui vos tik įkėlus pradžios puslapį. Naudokite jį tada, kai naudotojas atidaro kainodaros meniu, užveda pelę ant kainodaros nuorodos arba slenka prie raginimo veikti, kuris stipriai prognozuoja navigaciją.

Taip pat atminkite, kad naršyklių elgsena skiriasi. Kai kurios naršyklės su prefetch elgiasi konservatyviai; kai kurie privatumo nustatymai sumažina arba išjungia spekuliatyvų įkėlimą. Laikykite prefetch oportunistiniu patobulinimu, o ne korektiškumo mechanizmu.

Preconnect: brangiems ryšiams su svarbiomis kilmėmis

preconnect naršyklei sako: „Pradėk užmegzti ryšį su šia kilme dabar.“

Tai gali apimti DNS paiešką, TCP ryšį ir TLS derybas. Trečiųjų šalių kilmėms šis paruošimas gali užtrukti šimtus milisekundžių, ypač didelės delsos tinkluose. Jei puslapiui netrukus reikės kritinės užklausos iš tos kilmės, preconnect gali pagreitinti vėlesnę užklausą.

Pavyzdys:

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

Geri preconnect kandidatai:

  • Šrifto kilmė, naudojama atvaizdavimą blokuojančiam tekstui.
  • Kritinė API kilmė, reikalinga pradinės sąveikos metu.
  • CDN kilmė, pateikianti virš pirmo ekrano esančius išteklius.
  • Mokėjimų arba tapatybės teikėjas, reikalingas iš karto po naudotojo veiksmo.

Blogi preconnect kandidatai:

  • Analitikos ir reklamos galiniai taškai, kurie nėra kritiški naudotojui.
  • Kilmės, naudojamos tik kai kuriose sesijose.
  • Ilgi trečiųjų šalių sąrašai.
  • Tos pačios kilmės ištekliai, kuriems naršyklė jau turi arba netrukus atidarys ryšį.

Preconnect turi laikymo kainą. Atviri socket'ai naudoja atmintį ir tinklo išteklius. Naršyklės uždarys nenaudojamus ryšius, bet tai nereiškia, kad nereikalingi preconnect yra nekenksmingi.

Naudinga taisyklė: viename puslapyje naudokite preconnect daugiausia vienai ar dviem didelio pasitikėjimo trečiųjų šalių kilmėms. Jei kyla pagunda pridėti daugiau, jūsų trečiųjų šalių architektūrai tikriausiai labiau reikia peržiūros nei užuominoms — plėtros.

DNS-prefetch: lengvesnis giminaitis

Taip pat galite matyti dns-prefetch:

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

Tai tik išsprendžia domeno vardą. Tai neatidaro TCP ar TLS ryšio. Tai pigiau nei preconnect, bet ir mažiau naudinga.

DNS-prefetch gali būti pagrįstas mažesnio pasitikėjimo trečiųjų šalių kilmėms, kai pilnas preconnect atrodo per agresyvus. Praktikoje, jei kilmė yra kritinė ir tikrai netrukus bus naudojama, rinkitės preconnect. Jei ji tik galbūt bus naudojama, rinkitės DNS-prefetch arba nedarykite nieko.

Kaip nuspręsti: praktinė eiga

Pradėkite nuo matavimo, ne nuo žymų.

1. Nustatykite kliūtį

Atidarykite našumo pėdsaką ir ieškokite vėlyvo aptikimo. Ar šrifto, hero vaizdo arba scenarijaus užklausa prasidėjo tik po to, kai kitas failas buvo atsisiųstas ir išanalizuotas? Tai preload kandidatas.

Jei užklausa prasideda tik po ilgo DNS/TCP/TLS paruošimo trečiosios šalies kilmei, tai preconnect kandidatas.

Jei dabartinis puslapis veikia gerai, bet kita navigacija nuspėjamai lėta, prefetch gali padėti.

2. Pridėkite po vieną užuominą

Resource hints sąveikauja tarpusavyje. Pridėkite vieną, ją ištestuokite ir palikite tik tada, jei waterfall pagerėja, o naudotojui matomi rodikliai nepablogėja.

Naudodami preload stebėkite, ar nurodytas išteklius iš tiesų greitai panaudojamas. Chrome gali įspėti, kai iš anksto įkeltas išteklius nepanaudojamas netrukus po įkėlimo. Į šį įspėjimą žiūrėkite rimtai.

3. Patikrinkite prioritetų šalutinius poveikius

Preload gali atitraukti pralaidumą nuo CSS, JavaScript arba svarbesnių vaizdų. Preconnect gali užimti ryšio vietą. Prefetch gali pridėti foninio srauto.

Tinkamas rezultatas nėra „užuominą gavęs failas pradedamas krauti anksčiau“. Tinkamas rezultatas yra „puslapis naudotojams tampa prasmingai geresnis“. Žiūrėkite į LCP, INP, CLS ir, kur įmanoma, realių naudotojų stebėseną.

4. Patikrinkite antraštes ir talpyklą

Užuominos gali būti siunčiamos HTML arba HTTP Link antraštėse. Antraštės naudingos, kai serveris anksti žino, ko puslapiui reikės, bet jas sunkiau greitai apžiūrėti. Jei derinate, ar užuomina iš tiesų yra produkcinėje aplinkoje, svarbios neapdorotos antraštės; tai būtent tokia situacija, kuri aptariama mūsų vadove apie peradresavimų ir HTTP antraščių derinimą.

Talpykla taip pat svarbi. Iš anksto įkėlus išteklių su nesutampančiais kredencialais, neteisingu as arba skirtingais URL parametrais, gali atsirasti dvigubi atsisiuntimai. Tai vienas dažniausių būdų, kaip gerų ketinimų preload tampa našumo klaida.

Dažnos klaidos

Per daug preload

Jei viskas kritiška, niekas nėra kritiška. Apribokite preload ištekliais, reikalingais pradiniam atvaizdavimui arba tiesioginei interaktyviai sąveikai. Tipinis puslapis turėtų turėti nuo nulio iki trijų preload, o ne dvidešimt.

Prefetch naudojimas būtiniems ištekliams

Prefetch yra žemo prioriteto ir neprivalomas. Nenaudokite jo ištekliams, kurių reikia dabartiniam puslapiui. Jei puslapiui to reikia dabar, apsvarstykite preload arba įprastą HTML aptikimą.

Preconnect su kiekviena trečiąja šalimi

Trečiųjų šalių gausūs puslapiai dažnai turi dešimt ar daugiau išorinių kilmių. Preconnect visoms joms sukuria triukšmą. Pasirinkite vieną ar dvi, kurios yra ir kritinės, ir nuspėjamai naudojamos.

Mobiliųjų sąlygų pamiršimas

Resource hints vertingiausios lėtesniuose ryšiuose, bet ten jos ir pavojingiausios. Iššvaistytas prefetch greitame stalinio kompiuterio ryšyje yra nereikšmingas nuokrypis. Ribotame mobiliajame plane tai blogas kompromisas.

Paprasta sprendimų lentelė

| Situacija | Geriausia užuomina | Kodėl | |---|---:|---| | Kritinis šriftas aptinkamas per CSS | preload | Dabartiniam puslapiui jo reikia, aptikimas vėlyvas | | Hero vaizdas paslėptas už CSS arba kliento atvaizdavimo | preload | Gali pagerinti LCP, jei vaizdas pradedamas krauti vėlai | | Tikėtinas kitas maršrutas po naudotojo ketinimo | prefetch | Padeda būsimai navigacijai neblokuodamas dabartinio puslapio | | Kritinė trečiosios šalies šrifto/API kilmė | preconnect | Pašalina ryšio paruošimą iš kritinio kelio | | Galima, bet neaiški trečiosios šalies kilmė | dns-prefetch arba nieko | Mažesnė kaina, mažesnis pasitikėjimas | | Vaizdas žemiau pirmo ekrano | nieko | Leiskite lazy loading ir naršyklės prioritetams veikti |

Rami taisyklė

Resource hints geriausiai veikia tada, kai yra nuobodžios ir konkrečios. Vienas šriftas. Vienas LCP vaizdas. Viena svarbi trečiosios šalies kilmė. Vienas tikėtinas kitas maršrutas po ketinimo.

Jos veikia prastai, kai naudojamos kaip optimizmas: gal naudotojui to prireiks, gal naršyklė turėtų tai atsisiųsti, gal daugiau užuominų reiškia daugiau greičio.

Naršyklės jau optimizuoja agresyviai. Jūsų darbas nėra mikrovaldyti kiekvieną užklausą. Jūsų darbas — pataisyti kelis atvejus, kai naršyklei tinkamu momentu trūksta informacijos.

Dažnai užduodami klausimai

Ar turėčiau naudoti preload visiems savo šriftams?
Ne. Naudokite preload tik tiems šriftų failams, kurių reikia matomam tekstui puslapio pradžioje. Kiekvieno svorio ir stiliaus preload paprastai švaisto pralaidumą ir gali uždelsti svarbesnius išteklius.
Ar saugu naudoti prefetch kiekvienai vidinei nuorodai?
Paprastai ne. Tai gali sukurti nereikalingą foninį srautą ir švaistyti naudotojo duomenis. Geriau rinkitės ketinimu pagrįstą prefetch, pavyzdžiui, po užvedimo, fokusavimo, meniu atidarymo arba nuspėjamo kito žingsnio.
Kuo skiriasi preconnect ir dns-prefetch?
Preconnect atlieka DNS, TCP ir TLS paruošimą kilmei. DNS-prefetch tik išsprendžia domeno vardą. Preconnect yra stipresnis, bet brangesnis, todėl jį reikėtų naudoti su didesniu pasitikėjimu.
Ar resource hints gali pagerinti Core Web Vitals?
Taip, ypač LCP, kai jos ištaiso vėlyvą aptikimą arba ryšio paruošimą kritiniam ištekliui. Jos nepadės, jei tikroji problema yra per dideli ištekliai, lėtas serverio atsakas, atvaizdavimą blokuojantis kodas arba prasta talpykla.
Ar resource hints reikėtų pridėti HTML, ar HTTP antraštėse?
Veikti gali abu būdai. HTML lengviau suprasti puslapiui specifinėms užuominoms. HTTP Link antraštės gali būti naudingos, kai serveris žino kritinius išteklius dar prieš analizuojant HTML, bet jas reikia kruopščiai testuoti, kad būtų išvengta dublikatų ar pasenusių užuominų.

Šaltiniai ir tolesnis skaitymas

  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
Apie autorių
The Wux Webtools Team

Paskutinį kartą atnaujinta:

Tęsti skaitymą