Bakit dapat mas kaunti ang requests ng iyong site, hindi lang mas maliliit ang mga ito

Ang komportableng mito ng “paliitin lang ang bawat file”

Sa loob ng maraming taon, simple ang tunog ng payo sa web performance: i-compress ang lahat, i-minify ang lahat, paliitin ang bawat asset.

Tama pa rin ang payong iyon sa pangkalahatan. Karaniwang mas mabuti ang 40 KB na script kaysa 400 KB na script. Mas mabuti ang optimized na image kaysa raw export. Mahalaga pa rin ang Brotli, AVIF, CSS minification, tree shaking, at font subsetting.

Pero sa maraming production site, hindi na isang sobrang laking file ang mas malaking problema. Ito ay ang dami ng bagay na kailangang hingin ng browser bago maramdaman na magagamit na ang page.

Maaaring disiplinado ang hitsura ng isang page pagdating sa laki ng file at mabagal pa rin ito dahil nagpapadala ito ng 120 requests: CSS fragments, JavaScript chunks, third-party tags, font files, tracking pixels, icon sprites, JSON endpoints, preloads, analytics beacons, at cache revalidations. Maaaring “maliit” ang bawat isa. Sama-sama, lumilikha ang mga ito ng mahaba at marupok na waterfall.

Ito ang praktikal na tuntunin: kapag makatuwiran na ang pagka-compress ng mga indibidwal na asset, mas madalas na pinapabuti ng pagbabawas ng bilang ng requests ang user experience kaysa pag-ahit ng ilang kilobyte mula sa bawat file.

Ang requests ay hindi lang bytes

Ang network request ay hindi lamang paglilipat ng data. Isa itong sunod-sunod na trabaho.

Kailangang matuklasan ng browser ang resource, magpasya kung kailan ito kukunin, i-schedule ito laban sa ibang resources, magpadala ng headers, maghintay sa server, tumanggap ng headers, i-parse ang response, madalas ay i-decompress ito, at pagkatapos ay gumawa ng kapaki-pakinabang na bagay dito.

Maaaring mahal ang “kapaki-pakinabang na bagay” na iyon. Kailangang i-parse, i-compile, at i-execute ang isang JavaScript file. Maaaring humarang sa rendering ang isang CSS file. Maaaring magpaantala sa nababasang text o magdulot ng layout shifts ang isang font file. Maaaring makaapekto ang isang image sa Largest Contentful Paint element. Maaaring magdala ang isang third-party script ng sarili nitong dependency chain.

Ito ang dahilan kung bakit mahalaga pa rin ang bilang ng request kahit maliit ang mga file. Maaaring mas masama ang 3 KB na script kaysa 30 KB na image kung hinaharang nito ang rendering, huli itong dumating, at nag-e-execute ito sa main thread sa maling sandali.

Kung nagbabasa ka ng Lighthouse report at pakiramdam mo ay pinarurusahan ka ng dose-dosenang magkakahiwalay na babala, magsimula sa pagtingin sa request waterfall sa halip na sa indibidwal na scores. May praktikal kaming walkthrough sa kung paano magbasa ng Lighthouse report nang hindi nagpapanic, pero ang maikling bersyon ay: hanapin kung ano ang humaharang sa unang render at kung ano ang nagpapaantala sa pangunahing content.

“Pero inayos na ito ng HTTP/2,” kadalasan ay hindi

Binago ng HTTP/2 at HTTP/3 ang ekonomiya ng requests. Ipinakilala nila ang multiplexing, header compression, at mas magandang connection behavior. Sa madaling salita, naging mas mahusay ang browsers sa pagpapadala ng maraming request sa mas kaunting connections.

Tunay na pagpapabuti iyon. Pinatay din nito ang ilang lumang nakagawian, tulad ng sobrang CSS sprites at higanteng concatenated bundles na ginawa lamang para maiwasan ang connection limits.

Pero hindi ginawang libre ng HTTP/2 ang requests.

Nakakatulong ang multiplexing kapag maraming resource ang nagbabahagi ng connection, pero kailangan pa ring i-prioritize ng browser ang mga ito. Kailangan pa ring tumugon ng servers. Kailangan pa ring iproseso ng client ang bawat response. Umiiral pa rin ang congestion, packet loss, TLS negotiation, DNS lookup, cache misses, at main-thread pressure.

Pinapabuti ng HTTP/3 ang ilang transport behavior, lalo na sa connection migration at head-of-line blocking sa transport layer. Hindi nito inaalis ang gastos ng pagtuklas, pag-schedule, pag-download, pag-parse, at pag-execute ng resources.

Kaya ang modernong layunin ay hindi “i-bundle ang lahat sa isang napakalaking file.” Ito ay “magpadala ng mas kaunting critical requests, at gawing sinadya ang natitirang requests.”

Sa waterfall nakatira ang katotohanan

Bihirang magpakilala ang performance problems sa isang metric lamang. Lumilitaw ang mga ito bilang hugis.

Magbukas ng browser network panel at tingnan ang unang ilang segundo. Itanong:

• Ilang request ang nagsisimula bago lumitaw ang pangunahing content?
• Aling requests ang humaharang sa rendering?
• Huli bang natutuklasan ang mahahalagang resources?
• Nakikipag-agawan ba ang third-party scripts sa first-party CSS, fonts, o images?
• Marami bang file ang nagbabalik ng 304 responses sa halip na direktang ihain mula sa cache?
• Nahahati ba ang icons, fonts, o UI fragments sa mas maraming file kaysa kailangan ng page?

Karaniwang may boring na early waterfall ang mabilis na page. Maagang dumarating ang maliit na bilang ng critical resources. Naghihintay ang non-critical resources. Naantala, nalilimitahan, o inaalis ang third-party scripts. Hindi pinipilit ang browser na pagsabay-sabayin ang dalawampung priority bago nito maipinta ang page.

Madalas may kinakabahang waterfall ang mabagal na page: maraming maliliit na file, maraming origins, at maraming huling natutuklasan.

Mahalaga pa rin ang mas maliliit na file — pero hindi pantay-pantay

Hindi ito argumento laban sa compression o optimization. Isa itong argumento laban sa pag-optimize ng bytes habang binabalewala ang koordinasyon.

Pinakamahalaga ang mas maliliit na file kapag malaki ang resource, render-blocking, o bahagi ng main content path. Halimbawa:

• Dapat tama ang sukat at encoding ng hero image.
• Dapat lean ang render-blocking CSS.
• Dapat minimal ang JavaScript na kailangan para sa unang interaction.
• Dapat naka-subset, naka-compress, at limitado ang fonts sa weights na talagang ginagamit.

Karaniwang halimbawa ang fonts. Madalas pagtuunan ng teams kung 24 KB o 31 KB ang isang font file, habang nagpapadala ng anim na weights, dalawang styles, at maraming families. Hindi ang pag-ahit ng 7 KB mula sa isang file ang mas mabuting ayos. Ito ay ang pagpapadala ng mas kaunting font files. Kung bahagi ng iyong performance work ang typography, web fonts are still one of the easiest wins on most sites ay kapaki-pakinabang na panimula.

Ganoon din ang pattern sa images. Makakatipid ang AVIF o WebP ng makabuluhang bytes, pero masamang plano pa rin ang pagpapadala ng sampung decorative images above the fold. Pumili ng mas magandang formats, oo, pero tanungin din kung kailangan bang i-request ang bawat image. Para sa format decisions, ang aming gabay sa when AVIF beats WebP and when it does not ay kapaki-pakinabang na kasama sa gawaing ito sa request count.

Ang nakatagong gastos ng maraming maliliit na file

May tendensiyang lumikha ng mga problemang hindi lumilitaw kung titingnan mo lang ang kabuuang transferred bytes ang maraming maliliit na request.

1. Huling pagtuklas

Hindi maaaring i-request ng browsers ang hindi pa nila natutuklasan. Maaaring tumukoy ang isang CSS file sa isang font. Maaaring mag-import ang isang script ng isa pang script. Maaaring humingi ang isang component ng JSON pagkatapos ng hydration. Lumilikha ang bawat dependency ng isa pang hakbang sa chain.

Habang mas malalim ang chain, mas huli nagsisimula ang mahalagang trabaho.

2. Header overhead

May kasamang headers ang bawat request at response. Nakakatulong ang header compression, lalo na sa HTTP/2 at HTTP/3, pero hindi nito inaalis ang overhead. Mas mapapalala ito ng cookies. Kung nagpapadala ang iyong site ng malalaking cookies sa bawat request, nagiging hindi na gaanong maliit ang tiny assets sa praktika.

Isa itong dahilan kung bakit madalas dapat nakatira ang static assets sa cookie-free paths o domains, at kung bakit nararapat bigyang-pansin ang cache headers. Kung kakaiba ang kilos ng headers sa production, kadalasang mas mabilis ang debugging redirects and HTTP headers kaysa manghula.

3. Main-thread interruption

Maaaring lumikha ang maraming JavaScript chunks ng paulit-ulit na parse at execution work. Kahit maliit ang bawat chunk, maaaring patuloy na humihinto ang browser para mag-evaluate ng code. Maaari nitong saktan ang Interaction to Next Paint at gawing alog ang pakiramdam ng page.

Hindi mahalaga sa user na maliit ang bawat file. Mahalaga sa kanila na inabot ng 600 milliseconds ang pag-tap sa menu.

4. Cache complexity

Maaaring mapabuti ng paghahati ng assets ang caching kapag maingat itong ginawa. Maaaring magandang hati ang stable na vendor bundle at nagbabagong app bundle.

Pero maaaring bumaliktad ang sobrang chunking. Mas maraming file ay nangangahulugang mas maraming cache lookups, mas maraming pagkakataon para sa revalidation, mas maraming koordinasyon ng version, at mas maraming paraan para aksidenteng ma-invalidate ang resources na hindi naman kailangang magbago.

Bumabalik ang bundling, pero may paghatol

Gustong-gusto ng unang panahon ng web performance ang bundling dahil mahigpit ang connection limits ng browsers. Pagkatapos dumating ang HTTP/2 at maraming team ang malakas na lumihis patungo sa agresibong code splitting. May ilang kapaki-pakinabang doon. May ilan ding naging pamahiin.

Ang matinong gitna ay route-aware bundling.

Para sa tipikal na marketing site o content site:

• I-inline o i-load lamang ang CSS na kailangan para sa initial rendering.
• Panatilihing maliit ang global JavaScript.
• Iwasang hatiin ang maliliit na module sa magkakahiwalay na network requests.
• Iantala ang interactive features na hindi agad kailangan.
• Alisin ang third-party scripts na hindi napapatunayan ang kanilang gastos.

Para sa isang application:

• Hatiin ayon sa route o malaking feature, hindi ayon sa bawat component.
• Panatilihing stable at cacheable ang shared dependencies.
• I-preload lamang ang resources na tiyak na kakailanganin sa lalong madaling panahon.
• Iwasang i-load ang admin, dashboard, editor, o experiment code sa public pages.
• Sukatin ang interaction cost, hindi lang bundle size.

Hindi awtomatikong mabuti ang bundling. Hindi awtomatikong mabuti ang code splitting. Ang kapaki-pakinabang na tanong ay: nakakatulong ba ang hating ito sa browser na maihatid ang susunod na makabuluhang user experience nang mas maaga?

Dapat mas paghinalaan ang third-party requests

Nasa ilalim man lang ng iyong kontrol ang first-party requests. Madalas mas mabagal, hindi gaanong predictable, at mas mahal kaysa sa tingin ang third-party requests.

Maaaring mag-trigger ang isang tag manager ng analytics, ads, heatmaps, chat widgets, A/B testing, consent tools, at personalization scripts. Maaaring magdala ng mas maraming requests ang bawat vendor. May ilan na tatakbo nang maaga. May ilan na haharang sa main thread. May ilan na magbabago nang hindi dumadaan sa iyong release process.

Ang pinakamagandang third-party optimization ay deletion. Ang pangalawang pinakamaganda ay delay.

Bago magdagdag ng third-party script, itanong:

• Kailangan ba nitong mag-load bago makita ng user ang page?
• Kailangan ba nitong mag-load sa bawat page?
• Maaari ba itong mag-load pagkatapos ng consent, interaction, o idle time?
• Sino ang may-ari nito sa loob ng organisasyon?
• Anong metric ang nagpapatunay na sulit ito sa performance cost?

Dito nagiging governance ang performance. Kailangang may taong pinapayagang magsabi ng hindi.

Isang praktikal na checklist para bawasan ang requests

Magsimula sa pages na pinakamahalaga: homepage, pricing page, product page, checkout, signup, o top landing pages. Pagkatapos, isa-isahin ang waterfall.

Alisin

• Burahin ang hindi ginagamit na JavaScript at CSS.
• Alisin ang lumang experiments, inabandunang pixels, at duplicate analytics.
• Tanggalin ang hindi ginagamit na font weights at icon libraries.
• Palitan ang decorative images ng CSS kung angkop.

Pagsamahin nang may pag-iisip

• I-bundle ang maliliit na JavaScript modules na palaging sabay na naglo-load.
• Pagsamahin ang maliliit na CSS files na humaharang sa parehong render path.
• Gumamit ng SVG sprites o inline SVG para sa paulit-ulit na icons kapag binabawasan nito ang requests nang hindi sinasaktan ang maintainability.

Ipagpaliban

• I-lazy-load ang below-the-fold images.
• Iantala ang non-critical scripts hanggang pagkatapos ng first paint o user interaction.
• I-load lamang ang comments, embeds, maps, chat, at video players kapag kailangan.

I-cache nang maayos

• Gumamit ng long-lived caching para sa versioned static assets.
• Iwasan ang hindi kinakailangang revalidation para sa files na bihirang magbago.
• Panatilihing fresh ang HTML, pero hayaang manatiling cached ang hashed assets.

Sukatin muli

Pagkatapos ng bawat pagbabago, tingnan muli ang waterfall. Hindi perfect score ang layunin. Ang layunin ay mas kaunting critical requests, mas maagang kapaki-pakinabang na rendering, at mas kaunting main-thread disruption.

Ano ang itsura ng mabuti

Hindi kinakailangang may pinakakaunting request ang isang malusog na page. Mayroon itong maliit at sinadyang critical path.

Nakukuha ng browser ang HTML, essential CSS, ang main content image kung mayroon, marahil isang maliit na script na kailangan para sa navigation o above-the-fold interaction, at ang minimum na font set na kailangan para maging nababasa ang text. Naghihintay ng kanilang turno ang lahat ng iba pa.

Iyan ang pagkakaiba ng page na optimized lamang at page na mabilis ang pakiramdam.

Sulit pa ring paliitin ang files. Pero kung makatuwiran na ang pagka-compress ng site, ang susunod na performance win ay kadalasang hindi isa pang 2 KB na matitipid mula sa bundle. Ito ay isang blocking request na nabawas, isang font file na nabawas, isang third-party script na nabawas, isang dependency chain na nabawas.

Pinapasimple ng mas kaunting requests ang trabaho ng browser. Mas madalas mabilis ang simple kaysa gusto nating aminin.