Prečo by váš web mal odosielať menej požiadaviek, nie menšie

Pohodlný mýtus „stačí zmenšiť každý súbor“

Roky zneli rady k webovému výkonu jednoducho: všetko komprimovať, všetko minifikovať, každý asset zmenšiť.

Táto rada je stále vo všeobecnosti správna. Skript s veľkosťou 40 KB je zvyčajne lepší než skript s veľkosťou 400 KB. Optimalizovaný obrázok je lepší než surový export. Brotli, AVIF, minifikácia CSS, tree shaking aj zúženie fontov sú dôležité.

Na mnohých produkčných weboch však už väčším problémom nie je jeden príliš veľký súbor. Je ním počet vecí, o ktoré musí prehliadač požiadať, kým stránka začne pôsobiť použiteľne.

Stránka môže pôsobiť disciplinovane vo veľkostiach súborov a stále byť pomalá, pretože odosiela 120 požiadaviek: fragmenty CSS, JavaScript chunky, značky tretích strán, súbory fontov, sledovacie pixely, icon sprites, JSON endpointy, preloads, analytické beacony a opätovné overovania cache. Každá z nich môže byť „malá“. Spolu vytvárajú dlhý, krehký waterfall.

Praktické pravidlo znie takto: keď sú jednotlivé assety rozumne komprimované, zníženie počtu požiadaviek často zlepší používateľský zážitok viac než odrezanie niekoľkých kilobajtov z každého súboru.

Požiadavky nie sú len bajty

Sieťová požiadavka nie je iba prenos dát. Je to postupnosť práce.

Prehliadač musí zdroj objaviť, rozhodnúť, kedy ho načíta, naplánovať ho voči ostatným zdrojom, odoslať hlavičky, počkať na server, prijať hlavičky, spracovať odpoveď, často ju dekomprimovať a potom s ňou urobiť niečo užitočné.

To „niečo užitočné“ môže byť nákladné. Súbor JavaScriptu treba parsovať, skompilovať a vykonať. Súbor CSS môže blokovať vykresľovanie. Súbor fontu môže oddialiť čitateľný text alebo spôsobiť posuny rozloženia. Obrázok môže ovplyvniť prvok Largest Contentful Paint. Skript tretej strany si môže priniesť vlastný reťazec závislostí.

Preto na počte požiadaviek stále záleží, aj keď sú súbory malé. Skript s veľkosťou 3 KB môže byť horší než obrázok s veľkosťou 30 KB, ak blokuje vykresľovanie, dorazí neskoro a vykonáva sa na hlavnom vlákne v nesprávnej chvíli.

Ak čítate report Lighthouse a máte pocit, že vás trestá desiatkami samostatných upozornení, začnite pohľadom na waterfall požiadaviek, nie na jednotlivé skóre. Praktický postup máme v článku, ako čítať report Lighthouse bez paniky, ale krátka verzia je: nájdite, čo blokuje prvé vykreslenie a čo oneskoruje hlavný obsah.

„Ale HTTP/2 to vyriešil,“ väčšinou nie

HTTP/2 a HTTP/3 zmenili ekonomiku požiadaviek. Priniesli multiplexing, kompresiu hlavičiek a lepšie správanie pripojení. Jednoducho povedané, prehliadače sa výrazne zlepšili v odosielaní viacerých požiadaviek cez menej pripojení.

Bolo to skutočné zlepšenie. Zároveň ukončilo niektoré staré zvyky, napríklad extrémne CSS sprites a obrovské spojené bundly vytvorené iba preto, aby sa obišli limity pripojení.

HTTP/2 však neurobil požiadavky zadarmo.

Multiplexing pomáha, keď veľa zdrojov zdieľa jedno pripojenie, no prehliadač im stále musí určovať priority. Servery musia stále odpovedať. Klient musí stále spracovať každú odpoveď. Preťaženie, strata paketov, TLS vyjednávanie, DNS lookup, cache misses a tlak na hlavné vlákno stále existujú.

HTTP/3 zlepšuje niektoré vlastnosti transportu, najmä pri migrácii pripojenia a head-of-line blocking na transportnej vrstve. Neodstraňuje náklady na objavenie, plánovanie, sťahovanie, parsovanie a vykonávanie zdrojov.

Moderným cieľom teda nie je „zabaliť všetko do jedného obrovského súboru“. Je ním „odosielať menej kritických požiadaviek a zvyšné požiadavky robiť zámerne“.

Pravda žije vo waterfall

Výkonnostné problémy sa zriedka ohlásia jednou metrikou. Ukazujú sa ako tvar.

Otvorte sieťový panel prehliadača a pozrite sa na prvých pár sekúnd. Pýtajte sa:

• Koľko požiadaviek sa spustí pred zobrazením hlavného obsahu?
• Ktoré požiadavky blokujú vykresľovanie?
• Sú dôležité zdroje objavené neskoro?
• Súťažia skripty tretích strán s first-party CSS, fontmi alebo obrázkami?
• Vracia veľa súborov odpovede 304 namiesto toho, aby sa obslúžili priamo z cache?
• Sú ikony, fonty alebo fragmenty UI rozdelené do väčšieho počtu súborov, než stránka potrebuje?

Rýchla stránka má zvyčajne nudný skorý waterfall. Malý počet kritických zdrojov dorazí skoro. Nekritické zdroje čakajú. Skripty tretích strán sú odložené, obmedzené alebo odstránené. Prehliadač nie je nútený žonglovať s dvadsiatimi prioritami, kým môže stránku vykresliť.

Pomalá stránka má často nervózny waterfall: veľa malých súborov, veľa originov a veľa neskorých objavení.

Menšie súbory sú stále dôležité — len nie rovnako

Toto nie je argument proti kompresii alebo optimalizácii. Je to argument proti optimalizovaniu bajtov pri ignorovaní koordinácie.

Menšie súbory sú najdôležitejšie vtedy, keď je zdroj veľký, blokuje vykresľovanie alebo je súčasťou cesty k hlavnému obsahu. Napríklad:

• Hero obrázok by mal mať správnu veľkosť a kódovanie.
• CSS blokujúce vykresľovanie by malo byť štíhle.
• JavaScript potrebný na prvú interakciu by mal byť minimálny.
• Fonty by mali byť zúžené, komprimované a obmedzené na rezy, ktoré sa skutočne používajú.

Fonty sú bežným príkladom. Tímy často riešia, či má súbor fontu 24 KB alebo 31 KB, zatiaľ čo odosielajú šesť rezov, dva štýly a viacero rodín. Lepšia oprava nie je odseknúť 7 KB z jedného súboru. Je ňou odosielať menej súborov fontov. Ak je typografia súčasťou vašej práce na výkone, web fonts are still one of the easiest wins on most sites je stále jedným z najľahších ziskov na väčšine webov.

Obrázky majú rovnaký vzorec. AVIF alebo WebP dokážu ušetriť významné množstvo bajtov, ale odoslať desať dekoratívnych obrázkov vo viditeľnej časti stránky je stále zlý plán. Áno, vyberajte lepšie formáty, ale zároveň sa pýtajte, či sa každý obrázok vôbec musí načítať. Pri rozhodovaní o formátoch je náš sprievodca when AVIF beats WebP and when it does not užitočným doplnkom k práci na počte požiadaviek.

Skryté náklady mnohých malých súborov

Veľa malých požiadaviek zvykne vytvárať problémy, ktoré neuvidíte, ak sa pozeráte iba na celkový objem prenesených bajtov.

1. Neskoré objavenie

Prehliadače nemôžu požiadať o to, čo ešte neobjavili. Súbor CSS môže odkazovať na font. Skript môže importovať ďalší skript. Komponent môže po hydratácii požiadať o JSON. Každá závislosť vytvára ďalší krok v reťazci.

Čím hlbší je reťazec, tým neskôr sa dôležitá práca začne.

2. Réžia hlavičiek

Každá požiadavka a odpoveď obsahuje hlavičky. Kompresia hlavičiek pomáha, najmä cez HTTP/2 a HTTP/3, ale réžiu neodstraňuje. Cookies to môžu výrazne zhoršiť. Ak váš web odosiela veľké cookies s každou požiadavkou, drobné assety sú v praxi menej drobné.

Aj preto by statické assety mali často žiť na cestách alebo doménach bez cookies a preto si cache headers zaslúžia pozornosť. Ak sa hlavičky v produkcii správajú zvláštne, debugging redirects and HTTP headers býva zvyčajne rýchlejšie než hádanie.

3. Prerušovanie hlavného vlákna

Mnohé JavaScript chunky môžu vytvárať opakovanú prácu s parsovaním a vykonávaním. Aj keď je každý chunk malý, prehliadač sa môže stále zastavovať, aby vyhodnotil kód. To môže poškodiť Interaction to Next Paint a spôsobiť, že stránka pôsobí trhane.

Používateľa nezaujíma, že každý súbor bol malý. Zaujíma ho, že ťuknutie na menu trvalo 600 milisekúnd.

4. Zložitosť cache

Rozdelenie assetov môže pri opatrnom použití zlepšiť caching. Stabilný vendor bundle a meniaci sa app bundle môžu byť dobré rozdelenie.

Nadmerné chunkovanie sa však môže obrátiť proti vám. Viac súborov znamená viac vyhľadávaní v cache, viac príležitostí na revalidáciu, viac koordinácie verzií a viac spôsobov, ako omylom invalidovať zdroje, ktoré sa nemuseli meniť.

Bundling je späť, ale s úsudkom

Prvá éra webového výkonu milovala bundling, pretože prehliadače mali prísne limity pripojení. Potom prišiel HTTP/2 a mnohé tímy sa výrazne priklonili k agresívnemu code splittingu. Niečo z toho bolo užitočné. Niečo sa stalo poverou.

Rozumný stred je route-aware bundling.

Pre typický marketingový web alebo obsahový web:

• Inline alebo načítajte iba CSS potrebné na počiatočné vykreslenie.
• Udržujte globálny JavaScript malý.
• Nerozdeľujte drobné moduly do samostatných sieťových požiadaviek.
• Odložte interaktívne funkcie, ktoré nie sú potrebné okamžite.
• Odstráňte skripty tretích strán, ktoré neobhája svoje náklady.

Pre aplikáciu:

• Rozdeľujte podľa route alebo hlavnej funkcie, nie podľa každého komponentu.
• Udržujte zdieľané závislosti stabilné a cachovateľné.
• Preloadujte iba zdroje, ktoré budú určite čoskoro potrebné.
• Nenačítavajte admin, dashboard, editor ani experimentálny kód na verejných stránkach.
• Merajte náklady na interakciu, nie iba veľkosť bundlu.

Bundling nie je automaticky dobrý. Code splitting nie je automaticky dobrý. Užitočná otázka znie: pomáha toto rozdelenie prehliadaču doručiť ďalší zmysluplný používateľský zážitok skôr?

Požiadavky tretích strán si zaslúžia mimoriadnu nedôveru

First-party požiadavky máte aspoň pod kontrolou. Požiadavky tretích strán sú často pomalšie, menej predvídateľné a nákladnejšie, než vyzerajú.

Jeden tag manager môže spustiť analytiku, reklamy, heatmapy, chat widgety, A/B testing, nástroje na súhlas a personalizačné skripty. Každý dodávateľ môže priniesť ďalšie požiadavky. Niektoré pobežia skoro. Niektoré zablokujú hlavné vlákno. Niektoré sa zmenia bez vášho release procesu.

Najlepšia optimalizácia tretích strán je vymazanie. Druhá najlepšia je odklad.

Pred pridaním skriptu tretej strany sa pýtajte:

• Musí sa to načítať skôr, než používateľ uvidí stránku?
• Musí sa to načítať na každej stránke?
• Môže sa to načítať po súhlase, interakcii alebo počas nečinnosti?
• Kto to interne vlastní?
• Aká metrika dokazuje, že to stojí za výkonnostné náklady?

Tu sa výkon mení na governance. Niekto musí mať povolenie povedať nie.

Praktický checklist na zníženie počtu požiadaviek

Začnite stránkami, na ktorých záleží najviac: homepage, stránka s cenami, produktová stránka, checkout, registrácia alebo najdôležitejšie landing pages. Potom prejdite waterfall.

Odstráňte

• Vymažte nepoužívaný JavaScript a CSS.
• Odstráňte staré experimenty, opustené pixely a duplicitnú analytiku.
• Zahoďte nepoužívané rezy fontov a knižnice ikon.
• Nahraďte dekoratívne obrázky pomocou CSS tam, kde je to vhodné.

Premyslene kombinujte

• Zbundlujte drobné moduly JavaScriptu, ktoré sa vždy načítavajú spolu.
• Zlúčte malé súbory CSS, ktoré blokujú tú istú cestu vykresľovania.
• Použite SVG sprites alebo inline SVG pre opakované ikony, keď to znižuje počet požiadaviek bez zhoršenia udržiavateľnosti.

Odložte

• Lazy-loadujte obrázky mimo viditeľnej časti stránky.
• Odložte nekritické skripty až po prvom vykreslení alebo interakcii používateľa.
• Komentáre, embedy, mapy, chat a video prehrávače načítajte iba vtedy, keď sú potrebné.

Cachujte správne

• Používajte dlhodobé cachovanie pre verzované statické assety.
• Vyhnite sa zbytočnej revalidácii súborov, ktoré sa menia zriedka.
• HTML udržiavajte čerstvé, ale hashed assety nechajte zostať v cache.

Znovu merajte

Po každej zmene znova skontrolujte waterfall. Cieľom nie je dokonalé skóre. Cieľom je menej kritických požiadaviek, skoršie užitočné vykreslenie a menšie narúšanie hlavného vlákna.

Ako vyzerá dobrý stav

Zdravá stránka nemusí mať nevyhnutne najmenší možný počet požiadaviek. Má malú, zámernú kritickú cestu.

Prehliadač dostane HTML, nevyhnutné CSS, obrázok hlavného obsahu, ak existuje, možno malý skript potrebný na navigáciu alebo interakciu vo viditeľnej časti stránky a minimálnu sadu fontov potrebnú na čitateľný text. Všetko ostatné počká, kým príde na rad.

To je rozdiel medzi stránkou, ktorá je iba optimalizovaná, a stránkou, ktorá pôsobí rýchlo.

Zmenšovanie súborov má stále zmysel. Ak je však web už rozumne komprimovaný, ďalším výkonnostným ziskom zvyčajne nie sú ďalšie 2 KB ušetrené z bundlu. Je ním o jednu blokujúcu požiadavku menej, o jeden súbor fontu menej, o jeden skript tretej strany menej, o jeden reťazec závislostí menej.

Menej požiadaviek zjednodušuje prácu prehliadača. Jednoduchosť je rýchla častejšie, než si radi pripúšťame.