Web Performance

Preload, prefetch at preconnect: kailan talaga nakakatulong ang bawat isa

Kapaki-pakinabang ang resource hints kapag tumutugma ang mga ito sa tunay na bottleneck ng browser. Kapag ginamit nang walang pag-iisip, nagdaragdag ang mga ito ng ingay sa priority at minsan ay nagpapabagal pa ng mga page.

The Wux Webtools Team The Wux Webtools Team 11 min basahin Tulong ng AI, sinuri ng tao
A simplified browser loading waterfall showing early resource hints for a web page.
Talaan ng nilalaman
  1. Hindi mahika ang resource hints
  2. Ano na ang mahusay na ginagawa ng browser
  3. Preload: para sa current-page resources na huling natutuklasan
  4. Preload at LCP images
  5. Prefetch: para sa susunod na page, hindi sa kasalukuyan
  6. Preconnect: para sa mahal na koneksyon sa mahahalagang origin
  7. DNS-prefetch: ang mas magaan na pinsan
  8. Paano magpasya: isang praktikal na workflow
  9. 1. Tukuyin ang bottleneck
  10. 2. Magdagdag ng isang hint sa bawat pagkakataon
  11. 3. Suriin ang side effects sa priority
  12. 4. I-verify ang headers at caching
  13. Karaniwang pagkakamali
  14. Sobrang dami ng pini-preload
  15. Paggamit ng prefetch para sa kinakailangang resources
  16. Pag-preconnect sa bawat third party
  17. Paglimot sa mobile conditions
  18. Isang simpleng decision table
  19. Ang kalmadong tuntunin

Hindi mahika ang resource hints

Ang preload, prefetch, at preconnect ay madalas tratuhin bilang checklist sa performance. Magdagdag ng ilang tag sa <head>, patakbuhin muli ang Lighthouse, at gumaan ang pakiramdam. Hindi ganoon ang paggana ng mga ito.

Ang mga hint na ito ay mga tagubilin sa loading pipeline ng browser. Makakatulong ang mga ito kapag may alam kang hindi kayang matuklasan ng browser nang sapat na maaga. Makakasama ang mga ito kapag nanghuhula ka, labis ang pagbibigay-priority sa hindi kritikal na gawain, o pinapainit ang mga koneksyong hindi kailanman kailangan ng mga user.

Ang maikling bersyon:

  • Gamitin ang preload para sa mga resource na kailangan ng kasalukuyang page, ngunit masyadong huli natutuklasan.
  • Gamitin ang prefetch para sa malamang na future navigation resources, hindi para sa mahahalagang kailangan ng kasalukuyang page.
  • Gamitin ang preconnect para sa mahahalagang third-party origins kung saan tunay na delay ang connection setup.

Ang praktikal na tanong ay hindi “aling hint ang pinakamabilis?” Ito ay “ano ang hinihintay ng browser, at kaya bang alisin ng hint na ito ang paghihintay na iyon?”

Ano na ang mahusay na ginagawa ng browser

Ang mga modernong browser ay hindi pasibong tagapag-download ng file. Nagpa-parse sila ng HTML, nag-scan nang pauna para sa mga resource, nagtatalaga ng mga priority, muling gumagamit ng mga koneksyon, ipinagpapaliban ang gawaing hindi nakikita, at umaangkop sa kondisyon ng network.

Ibig sabihin, dapat piliin nang maingat ang resource hints. Kung ang isang stylesheet, script, image, o font ay natutuklasan na nang maaga at nabibigyan ng tamang priority, maaaring walang maidagdag ang hint. Mas masama pa, maaari itong makipag-agawan sa mga resource na mas mahalaga.

Bago magdagdag ng hints, tingnan ang waterfall trace sa DevTools o isang lab report. Kung gumagamit ka ng Lighthouse, magsimula sa diagnostics sa halip na sa score; mayroon kaming hiwalay na gabay sa pagbabasa ng Lighthouse report nang hindi nagpapanic — ngunit tandaan na case-sensitive ang tamang URL, kaya gamitin ang naka-link na artikulo mula sa site navigation kung kailangan.

Karaniwang nakikita ang tunay na ebidensya sa tatlong lugar:

  1. Huling nagsisimula ang isang kritikal na resource dahil huli itong natutuklasan ng browser.
  2. Ang koneksyon sa isang mahalagang origin ay tumatagal nang kapansin-pansin bago ang unang request.
  3. Ang isang next-page resource ay lubhang predictable at murang kunin sa idle time.

Kung wala sa mga iyon ang totoo, malamang dekorasyon lang ang hint.

Preload: para sa current-page resources na huling natutuklasan

Sinasabi ng preload sa browser: “Kunin ang resource na ito ngayon dahil kakailanganin ito ng kasalukuyang page.”

Isang karaniwang halimbawa ang web font na nire-reference sa loob ng CSS. Kailangang i-download ng browser ang HTML, matuklasan ang CSS, i-download ang CSS, i-parse ito, matuklasan ang font, at saka i-request ang font. Kung mahalaga ang font na iyon para sa above-the-fold text, maaaring sapat na huli ang discovery upang magdulot ng layout shifts o naantalang text rendering.

Maaaring ilipat ng preload ang request na iyon nang mas maaga:

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

Mahalaga ang attribute na as. Sinasabi nito sa browser kung anong uri ng resource ito, na nakakaapekto sa priority, caching, content security policy, at request headers. Karaniwan ding kailangan ng fonts ang crossorigin, kahit inihahain mula sa parehong site, dahil gumagamit ang font fetching ng CORS mode.

Magagandang kandidato para sa preload ang:

  • Pangunahing web font na ginagamit para sa nakikitang text.
  • Hero image na Largest Contentful Paint element at hindi natutuklasan nang maaga.
  • Critical CSS file na na-load nang hindi direkta.
  • Module o script na kailangan nang napakaaga, ngunit nakatago sa likod ng isa pang script.

Hindi magagandang kandidato para sa preload ang:

  • Bawat font weight sa design system.
  • Mga image below the fold.
  • Mga script na hindi kailangan para sa initial rendering.
  • Mga resource na natutuklasan na ng browser sa unang HTML chunk.

Makapangyarihan ang preload dahil naaapektuhan nito ang priority ng kasalukuyang page. Iyon din ang dahilan kung bakit madali itong magamit nang mali. Kung nag-preload ka ng limang malalaking asset, hindi mo na tinutulungan ang browser. Nakikipagtalo ka na rito.

Ang fonts ang klasikong kaso. Makakatulong ang pag-preload ng isang pangunahing font file. Karaniwang nagpapalala ang pag-preload ng anim na weights at italics. Kung fonts ang bottleneck mo, ayusin muna ang font set; mas detalyadong tinatalakay ng aming gabay kung bakit web fonts are still the easiest performance win on most sites ang paglilinis na iyon.

Preload at LCP images

Maaaring maging kapaki-pakinabang ang pag-preload ng LCP image kapag hindi nakikita ang image sa initial HTML. Kabilang sa mga karaniwang sanhi ang CSS background images, client-rendered components, o responsive image logic na lumilitaw nang huli.

Ngunit kung ang hero image mo ay nasa HTML na bilang <img> na may maayos na srcset, sizes, dimensions, at walang lazy loading, malamang mabilis itong mahahanap ng browser. Sa kasong iyon, maaaring mas angkop ang pagdaragdag ng fetchpriority='high' kaysa preload, depende sa page.

Isang magandang test: kung huling nagsisimula ang image request sa waterfall at nagiging LCP element ito, isaalang-alang ang preload. Kung maaga itong nagsisimula ngunit mabagal mag-download, ang problema ay laki, format, CDN behavior, o server latency — hindi discovery. Para sa mga desisyon sa image format, tingnan ang when AVIF beats WebP and when it does not.

Prefetch: para sa susunod na page, hindi sa kasalukuyan

Sinasabi ng prefetch sa browser: “Maaaring kailanganin ang resource na ito sa lalong madaling panahon, ngunit hindi ito kailangan ngayon.”

Mahalaga ang pagkakaibang iyon. Sadyang low priority ang prefetch. Maaaring kunin ito ng browser sa idle time at itago para magamit sa susunod. Maaari rin itong laktawan sa mahihinang koneksyon, data-saving modes, o kapag may memory pressure.

Gamitin ang prefetch kapag sapat ang lakas ng user intent upang maging malamang ang susunod na resource.

Magagandang kandidato para sa prefetch ang:

  • Susunod na hakbang sa multi-page checkout.
  • Search results matapos magsimulang mag-type ang user ng query, kung predictable ang susunod na route.
  • Documentation pages na naka-link mula sa table of contents kapag aktibong nagbabasa ang user ng kalapit na content.
  • Route chunks sa single-page app pagkatapos mag-hover o mag-focus ang user sa navigation item.

Hindi magagandang kandidato para sa prefetch ang:

  • Buong navigation tree mo.
  • Malalaking video o image galleries.
  • Third-party scripts “just in case.”
  • Mga page na bihirang bisitahin ng users bilang susunod.

Sa prefetch, nagbubunga ang pagpipigil. Hindi libre ang resource na kinuha ngunit hindi nagamit. Kumokonsumo ito ng bandwidth, server capacity, enerhiya, at posibleng user data. Sa mobile networks, maaaring maging aktibong hindi maganda para sa user ang speculative fetching.

Para sa maraming site, ang pinakamainam na prefetch strategy ay nakabatay sa intent. Huwag i-prefetch ang pricing page sa sandaling mag-load ang home page. I-prefetch ito kapag binuksan ng user ang pricing menu, nag-hover sa pricing link, o nag-scroll malapit sa call-to-action na malakas ang hula sa navigation.

Tandaan din na nag-iiba-iba ang behavior ng browser. May ilang browser na konserbatibo sa prefetch; may ilang privacy settings na nagpapababa o nagdi-disable ng speculative loading. Tratuhin ang prefetch bilang opportunistic improvement, hindi mekanismo ng correctness.

Preconnect: para sa mahal na koneksyon sa mahahalagang origin

Sinasabi ng preconnect sa browser: “Simulan na ngayon ang pag-set up ng koneksyon sa origin na ito.”

Maaaring kabilang dito ang DNS lookup, TCP connection, at TLS negotiation. Para sa third-party origins, maaaring tumagal ng daan-daang millisecond ang setup na ito, lalo na sa high-latency networks. Kung malapit nang kailanganin ng page ang isang kritikal na request mula sa origin na iyon, mapapabilis ng preconnect ang susunod na request.

Halimbawa:

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

Magagandang kandidato para sa preconnect ang:

  • Font origin na ginagamit para sa render-blocking text.
  • Critical API origin na kailangan sa initial interaction.
  • CDN origin na naghahain ng above-the-fold assets.
  • Payments o identity provider na kailangan kaagad pagkatapos ng user action.

Hindi magagandang kandidato para sa preconnect ang:

  • Analytics at advertising endpoints na hindi user-critical.
  • Origins na ginagamit lamang sa ilang session.
  • Mahahabang listahan ng third parties.
  • Same-origin resources, kung saan mayroon na o malapit nang magbukas ng koneksyon ang browser.

May holding cost ang preconnect. Kumokonsumo ng memory at network resources ang mga bukas na socket. Isasara ng mga browser ang unused connections, ngunit hindi nito ginagawang harmless ang hindi kinakailangang preconnects.

Isang kapaki-pakinabang na tuntunin: mag-preconnect sa pinakamarami nang isa o dalawang high-confidence third-party origins sa isang page. Kung natutukso kang magdagdag pa, malamang mas kailangan ng review ang third-party architecture mo kaysa palawakin ang hints mo.

DNS-prefetch: ang mas magaan na pinsan

Maaari mo ring makita ang dns-prefetch:

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

Nire-resolve lang nito ang domain name. Hindi ito nagbubukas ng TCP o TLS connection. Mas mura ito kaysa preconnect, ngunit mas kaunti rin ang naitutulong.

Maaaring makatwiran ang DNS-prefetch para sa lower-confidence third-party origins kung saan masyadong agresibo ang full preconnect. Sa praktika, kung kritikal ang origin at tiyak na gagamitin sa lalong madaling panahon, piliin ang preconnect. Kung posible lang, gamitin ang DNS-prefetch o huwag gumawa ng anuman.

Paano magpasya: isang praktikal na workflow

Magsimula sa measurement, hindi sa tags.

1. Tukuyin ang bottleneck

Magbukas ng performance trace at hanapin ang late discovery. Nagsimula ba ang font, hero image, o script request pagkatapos lamang ma-download at ma-parse ang isa pang file? Kandidato iyon para sa preload.

Kung nagsisimula lang ang isang request matapos ang mahabang DNS/TCP/TLS setup sa third-party origin, kandidato iyon para sa preconnect.

Kung maayos ang kasalukuyang page ngunit predictably mabagal ang susunod na navigation, maaaring makatulong ang prefetch.

2. Magdagdag ng isang hint sa bawat pagkakataon

Nag-iinteract ang resource hints. Magdagdag ng isa, i-test ito, at panatilihin lamang kung bumubuti ang waterfall at hindi lumalala ang user-facing metrics.

Para sa preload, bantayan kung talagang nagagamit agad ang hinted resource. Maaaring magbigay ng babala ang Chrome kapag hindi nagamit ang isang preloaded resource ilang sandali matapos ang load. Seryosohin ang babalang iyon.

3. Suriin ang side effects sa priority

Maaaring hilahin ng preload ang bandwidth palayo sa CSS, JavaScript, o images na mas mahalaga. Maaaring okupahin ng preconnect ang isang connection slot. Maaaring magdagdag ng background traffic ang prefetch.

Ang tamang resulta ay hindi “mas maagang nagsisimula ang hinted file.” Ang tamang resulta ay “makabuluhang gumaganda ang page para sa users.” Tingnan ang LCP, INP, CLS, at real-user monitoring kung maaari.

4. I-verify ang headers at caching

Maaaring ipadala ang hints sa HTML o HTTP Link headers. Kapaki-pakinabang ang headers kapag alam ng server nang maaga kung ano ang kakailanganin ng page, ngunit mas mahirap itong inspeksyunin nang kaswal. Kung nagde-debug ka kung talagang naroon ang isang hint sa production, mahalaga ang raw headers; ito mismo ang uri ng sitwasyong tinatalakay sa aming gabay sa pag-debug ng redirects at HTTP headers.

Mahalaga rin ang caching. Ang pag-preload ng resource na may hindi tugmang credentials, maling as, o ibang URL parameters ay maaaring magdulot ng duplicate downloads. Isa iyon sa pinakakaraniwang paraan kung paanong ang preload na mabuti ang intensyon ay nagiging performance bug.

Karaniwang pagkakamali

Sobrang dami ng pini-preload

Kung lahat ay kritikal, walang kritikal. Limitahan ang preload sa mga resource na kailangan para sa initial rendering o agarang interactivity. Dapat ay karaniwang may zero hanggang tatlong preload ang isang page, hindi dalawampu.

Paggamit ng prefetch para sa kinakailangang resources

Low priority at optional ang prefetch. Huwag itong gamitin para sa assets na kailangan ng kasalukuyang page. Kung kailangan ito ng page ngayon, isaalang-alang ang preload o normal na HTML discovery.

Pag-preconnect sa bawat third party

Ang pages na mabigat sa third-party ay madalas may sampu o higit pang external origins. Nagdudulot ng ingay ang pag-preconnect sa lahat ng iyon. Piliin ang isa o dalawa na parehong kritikal at predictably ginagamit.

Paglimot sa mobile conditions

Pinakamahalaga ang resource hints sa mas mabagal na koneksyon, ngunit doon din sila pinakamapanganib. Ang nasayang na prefetch sa mabilis na desktop connection ay rounding error. Sa constrained mobile plan, masamang trade iyon.

Isang simpleng decision table

| Situation | Best hint | Why | |---|---:|---| | Critical font na natuklasan sa pamamagitan ng CSS | preload | Kailangan ito ng kasalukuyang page, huli ang discovery | | Hero image na nakatago sa likod ng CSS o client rendering | preload | Maaaring mapabuti ang LCP kung huling nagsisimula ang image | | Malamang na susunod na route pagkatapos ng user intent | prefetch | Tumutulong sa future navigation nang hindi bina-block ang kasalukuyang page | | Critical third-party font/API origin | preconnect | Inaalis ang connection setup mula sa critical path | | Posible ngunit hindi tiyak na third-party origin | dns-prefetch o wala | Mas mababang cost, mas mababang confidence | | Below-the-fold image | wala | Hayaan ang lazy loading at browser priority na gumana |

Ang kalmadong tuntunin

Pinakamahusay gumana ang resource hints kapag boring at tiyak ang mga ito. Isang font. Isang LCP image. Isang mahalagang third-party origin. Isang malamang na susunod na route pagkatapos ng intent.

Mahina ang paggana ng mga ito kapag ginamit bilang optimism: baka kailanganin ito ng user, baka dapat kunin iyon ng browser, baka mas maraming hints ay mas mabilis.

Agresibo na ang pag-optimize ng mga browser. Hindi mo trabaho ang i-micromanage ang bawat request. Trabaho mong itama ang ilang kasong kulang ang impormasyon ng browser sa tamang sandali.

Mga madalas itanong

Dapat ko bang i-preload ang lahat ng fonts ko?
Hindi. I-preload lamang ang font files na kailangan para sa nakikitang text nang maaga sa page. Karaniwang nagsasayang ng bandwidth ang pag-preload ng bawat weight at style at maaari nitong maantala ang mas mahahalagang resource.
Ligtas bang gamitin ang prefetch para sa bawat internal link?
Karaniwan, hindi. Maaari itong lumikha ng hindi kinakailangang background traffic at magsayang ng user data. Mas piliin ang intent-based prefetching, tulad ng pagkatapos ng hover, focus, pagbukas ng menu, o predictable na susunod na hakbang.
Ano ang pagkakaiba ng preconnect at dns-prefetch?
Isinasagawa ng preconnect ang DNS, TCP, at TLS setup para sa isang origin. Domain name lang ang nire-resolve ng DNS-prefetch. Mas malakas ang preconnect ngunit mas mahal, kaya dapat itong gamitin nang may mas mataas na confidence.
Maaari bang mapabuti ng resource hints ang Core Web Vitals?
Oo, lalo na ang LCP, kapag inaayos ng mga ito ang late discovery o connection setup para sa isang kritikal na resource. Hindi sila makakatulong kung ang tunay na isyu ay sobrang laki ng assets, mabagal na server response, render-blocking code, o mahinang caching.
Dapat bang idagdag ang resource hints sa HTML o HTTP headers?
Pareho itong maaaring gumana. Mas madaling unawain ang HTML para sa page-specific hints. Maaaring maging kapaki-pakinabang ang HTTP Link headers kapag alam ng server ang critical resources bago ma-parse ang HTML, ngunit kailangan ng maingat na testing upang maiwasan ang duplicates o stale hints.

Mga mapagkukunan at karagdagang pagbabasa

  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
Tungkol sa may-akda
The Wux Webtools Team

Huling na-update:

Patuloy na magbasa