Zašto bi vaša web-lokacija trebala slati manje zahtjeva, a ne samo manje datoteke

Ugodan mit o tome da treba “samo smanjiti svaku datoteku”

Godinama je savjet za web-performanse zvučao jednostavno: komprimirajte sve, minificirajte sve, smanjite svaki resurs.

Taj je savjet i dalje uglavnom točan. Skripta od 40 KB obično je bolja od skripte od 400 KB. Optimizirana slika bolja je od sirovog izvoza. Brotli, AVIF, minifikacija CSS-a, tree shaking i podskupovi fontova — sve je to važno.

No na mnogim produkcijskim web-lokacijama veći problem više nije jedna prevelika datoteka. Problem je broj stvari koje preglednik mora zatražiti prije nego što se stranica počne doimati upotrebljivom.

Stranica može izgledati disciplinirano po veličinama datoteka, a svejedno biti spora jer šalje 120 zahtjeva: CSS fragmente, JavaScript chunkove, oznake trećih strana, datoteke fontova, piksele za praćenje, spriteove ikona, JSON endpointove, preloadove, analitičke beacone i revalidacije predmemorije. Svaki od njih može biti “malen”. Zajedno stvaraju dug, krhak waterfall.

Praktično je pravilo ovo: nakon što su pojedinačni resursi razumno komprimirani, smanjenje broja zahtjeva često poboljšava korisničko iskustvo više nego skidanje nekoliko kilobajta sa svake datoteke.

Zahtjevi nisu samo bajtovi

Mrežni zahtjev nije samo prijenos podataka. To je niz radnji.

Preglednik mora otkriti resurs, odlučiti kada će ga dohvatiti, rasporediti ga u odnosu na druge resurse, poslati zaglavlja, pričekati poslužitelj, primiti zaglavlja, parsirati odgovor, često ga dekomprimirati, a zatim s njim učiniti nešto korisno.

To “nešto korisno” može biti skupo. JavaScript datoteka mora se parsirati, kompajlirati i izvršiti. CSS datoteka može blokirati prikazivanje. Datoteka fonta može odgoditi čitljiv tekst ili uzrokovati pomake rasporeda. Slika može utjecati na element Largest Contentful Paint. Skripta treće strane može donijeti vlastiti lanac ovisnosti.

Zato je broj zahtjeva i dalje važan čak i kada su datoteke male. Skripta od 3 KB može biti gora od slike od 30 KB ako blokira prikazivanje, stigne kasno i izvršava se na glavnoj niti u pogrešnom trenutku.

Ako čitate Lighthouse izvješće i osjećate se kažnjeno desecima odvojenih upozorenja, počnite gledati waterfall zahtjeva umjesto pojedinačnih ocjena. Imamo praktičan vodič u tekstu kako čitati Lighthouse izvješće bez panike, ali kratka verzija glasi: pronađite što blokira prvi prikaz i što odgađa glavni sadržaj.

“Ali HTTP/2 je to riješio” — uglavnom nije

HTTP/2 i HTTP/3 promijenili su ekonomiku zahtjeva. Uveli su multipleksiranje, kompresiju zaglavlja i bolje ponašanje veza. Jednostavno rečeno, preglednici su postali mnogo bolji u slanju više zahtjeva preko manje veza.

To je bilo stvarno poboljšanje. Ujedno je ukinulo neke stare navike, poput ekstremnih CSS spriteova i golemih spojenih bundleova napravljenih samo radi izbjegavanja ograničenja veza.

Ali HTTP/2 nije učinio zahtjeve besplatnima.

Multipleksiranje pomaže kada mnogo resursa dijeli vezu, ali preglednik im i dalje mora odrediti prioritete. Poslužitelji i dalje moraju odgovoriti. Klijent i dalje mora obraditi svaki odgovor. Zagušenje, gubitak paketa, TLS pregovaranje, DNS lookup, promašaji predmemorije i pritisak na glavnu nit i dalje postoje.

HTTP/3 poboljšava neka ponašanja prijenosa, osobito oko migracije veza i head-of-line blocking problema na transportnom sloju. Ne uklanja trošak otkrivanja, raspoređivanja, preuzimanja, parsiranja i izvršavanja resursa.

Zato moderni cilj nije “spakirati sve u jednu golemu datoteku”. Cilj je “poslati manje kritičnih zahtjeva i učiniti preostale zahtjeve namjernima”.

Waterfall je mjesto gdje živi istina

Problemi s performansama rijetko se objave jednom metrikom. Pojavljuju se kao oblik.

Otvorite mrežni panel u pregledniku i pogledajte prvih nekoliko sekundi. Pitajte:

• Koliko zahtjeva počinje prije nego što se pojavi glavni sadržaj?
• Koji zahtjevi blokiraju prikazivanje?
• Otkrivaju li se važni resursi kasno?
• Natječu li se skripte trećih strana s vlastitim CSS-om, fontovima ili slikama?
• Vraćaju li mnoge datoteke odgovore 304 umjesto da se posluže izravno iz predmemorije?
• Jesu li ikone, fontovi ili UI fragmenti razdvojeni u više datoteka nego što stranici treba?

Brza stranica obično ima dosadan rani waterfall. Mali broj kritičnih resursa stiže rano. Nekritični resursi čekaju. Skripte trećih strana odgođene su, ograničene ili uklonjene. Preglednik nije prisiljen žonglirati s dvadeset prioriteta prije nego što može nacrtati stranicu.

Spora stranica često ima nervozan waterfall: mnogo malih datoteka, mnogo izvora i mnogo kasnih otkrića.

Manje datoteke i dalje su važne — samo ne jednako

Ovo nije argument protiv kompresije ili optimizacije. Ovo je argument protiv optimiziranja bajtova uz zanemarivanje koordinacije.

Manje datoteke najviše znače kada je resurs velik, blokira prikazivanje ili je dio puta do glavnog sadržaja. Na primjer:

• Hero slika treba biti pravilno dimenzionirana i kodirana.
• CSS koji blokira prikazivanje treba biti vitak.
• JavaScript potreban za prvu interakciju treba biti minimalan.
• Fontovi trebaju biti svedeni na podskupove, komprimirani i ograničeni na debljine koje se stvarno koriste.

Fontovi su čest primjer. Timovi se često opsesivno bave time ima li datoteka fonta 24 KB ili 31 KB, dok isporučuju šest debljina, dva stila i više obitelji. Bolje rješenje nije skinuti 7 KB s jedne datoteke. Bolje je poslati manje datoteka fontova. Ako je tipografija dio vašeg rada na performansama, web fontovi su i dalje jedna od najlakših pobjeda na većini web-lokacija.

Slike slijede isti obrazac. AVIF ili WebP mogu uštedjeti značajne bajtove, ali slanje deset dekorativnih slika iznad pregiba i dalje je loš plan. Birajte bolje formate, da, ali također se zapitajte treba li se svaka slika uopće zatražiti. Za odluke o formatima, naš vodič o tome kada AVIF pobjeđuje WebP, a kada ne koristan je pratitelj ovom radu na broju zahtjeva.

Skriveni troškovi mnogih malih datoteka

Mnogi mali zahtjevi obično stvaraju probleme koji se ne vide ako gledate samo ukupno prenesene bajtove.

1. Kasno otkrivanje

Preglednici ne mogu zatražiti ono što nisu otkrili. CSS datoteka može referencirati font. Skripta može uvesti drugu skriptu. Komponenta može zatražiti JSON nakon hidracije. Svaka ovisnost stvara još jedan korak u lancu.

Što je lanac dublji, to važan rad počinje kasnije.

2. Trošak zaglavlja

Svaki zahtjev i odgovor uključuje zaglavlja. Kompresija zaglavlja pomaže, osobito preko HTTP/2 i HTTP/3, ali ne uklanja trošak. Kolačići to mogu znatno pogoršati. Ako vaša web-lokacija šalje velike kolačiće uz svaki zahtjev, sitni resursi u praksi postaju manje sitni.

To je jedan od razloga zašto bi statični resursi često trebali živjeti na putanjama ili domenama bez kolačića, i zašto zaglavlja predmemorije zaslužuju pažnju. Ako se zaglavlja u produkciji ponašaju neobično, debugiranje preusmjeravanja i HTTP zaglavlja obično je brže od pogađanja.

3. Prekidanje glavne niti

Mnogi JavaScript chunkovi mogu stvoriti ponavljani rad parsiranja i izvršavanja. Čak i ako je svaki chunk malen, preglednik se može stalno zaustavljati kako bi evaluirao kod. To može naštetiti metrici Interaction to Next Paint i učiniti da se stranica doima trzavo.

Korisnika ne zanima što je svaka datoteka bila mala. Zanima ga zašto je dodir na izbornik trajao 600 milisekundi.

4. Složenost predmemorije

Razdvajanje resursa može poboljšati predmemoriranje kada se radi pažljivo. Stabilan vendor bundle i promjenjivi app bundle mogu biti dobra podjela.

Ali pretjerano chunkanje može se obiti o glavu. Više datoteka znači više provjera predmemorije, više prilika za revalidaciju, više koordinacije verzija i više načina da se slučajno invalidiraju resursi koji se nisu trebali promijeniti.

Bundling se vratio, ali uz prosudbu

Prvo doba web-performansi voljelo je bundling jer su preglednici imali stroga ograničenja veza. Zatim je stigao HTTP/2 i mnogi su timovi snažno krenuli prema agresivnom dijeljenju koda. Nešto od toga bilo je korisno. Nešto je postalo praznovjerje.

Razumna sredina je bundling svjestan ruta.

Za tipičnu marketinšku ili sadržajnu web-lokaciju:

• Inlineajte ili učitajte samo CSS potreban za početno prikazivanje.
• Globalni JavaScript držite malim.
• Izbjegavajte razdvajanje sitnih modula u zasebne mrežne zahtjeve.
• Odgodite interaktivne značajke koje nisu odmah potrebne.
• Uklonite skripte trećih strana koje ne opravdavaju svoj trošak.

Za aplikaciju:

• Dijelite po ruti ili velikoj značajki, ne po svakoj komponenti.
• Zajedničke ovisnosti držite stabilnima i pogodnima za predmemoriranje.
• Preloadajte samo resurse koji će sigurno uskoro trebati.
• Izbjegavajte učitavanje koda za admin, dashboard, editor ili eksperimente na javnim stranicama.
• Mjerite trošak interakcije, a ne samo veličinu bundlea.

Bundling nije automatski dobar. Dijeljenje koda nije automatski dobro. Korisno pitanje glasi: pomaže li ova podjela pregledniku da ranije isporuči sljedeće smisleno korisničko iskustvo?

Zahtjevi trećih strana zaslužuju dodatnu sumnju

Zahtjevi prve strane barem su pod vašom kontrolom. Zahtjevi trećih strana često su sporiji, manje predvidljivi i skuplji nego što izgledaju.

Jedan tag manager može pokrenuti analitiku, oglase, heatmapove, chat widgete, A/B testiranje, alate za privolu i skripte za personalizaciju. Svaki dobavljač može donijeti još zahtjeva. Neki će se pokretati rano. Neki će blokirati glavnu nit. Neki će se mijenjati bez vašeg procesa izdanja.

Najbolja optimizacija trećih strana jest brisanje. Druga najbolja jest odgoda.

Prije dodavanja skripte treće strane, pitajte:

• Mora li se ovo učitati prije nego što korisnik vidi stranicu?
• Mora li se učitati na svakoj stranici?
• Može li se učitati nakon privole, interakcije ili u praznom hodu?
• Tko je interno vlasnik toga?
• Koja metrika dokazuje da je vrijedno troška performansi?

Ovdje performanse postaju upravljanje. Netko mora imati dopuštenje reći ne.

Praktičan kontrolni popis za smanjenje zahtjeva

Počnite sa stranicama koje su najvažnije: početna stranica, stranica s cijenama, stranica proizvoda, checkout, registracija ili glavne odredišne stranice. Zatim prođite kroz waterfall.

Uklonite

• Izbrišite nekorišteni JavaScript i CSS.
• Uklonite stare eksperimente, napuštene piksele i dupliciranu analitiku.
• Izbacite nekorištene debljine fontova i biblioteke ikona.
• Zamijenite dekorativne slike CSS-om gdje je prikladno.

Promišljeno kombinirajte

• Bundleajte sitne JavaScript module koji se uvijek učitavaju zajedno.
• Spojite male CSS datoteke koje blokiraju isti put prikazivanja.
• Koristite SVG spriteove ili inline SVG za ponavljane ikone kada to smanjuje zahtjeve bez narušavanja održivosti.

Odgodite

• Lazy-loadajte slike ispod pregiba.
• Odgodite nekritične skripte do nakon prvog prikaza ili korisničke interakcije.
• Učitavajte komentare, embede, karte, chat i video playere samo kada su potrebni.

Ispravno predmemorirajte

• Koristite dugotrajno predmemoriranje za verzionirane statične resurse.
• Izbjegavajte nepotrebnu revalidaciju za datoteke koje se rijetko mijenjaju.
• HTML održavajte svježim, ali hashiranim resursima dopustite da ostanu u predmemoriji.

Ponovno izmjerite

Nakon svake promjene ponovno provjerite waterfall. Cilj nije savršena ocjena. Cilj je manje kritičnih zahtjeva, ranije korisno prikazivanje i manje ometanja glavne niti.

Kako izgleda dobro

Zdrava stranica ne mora nužno imati najmanji mogući broj zahtjeva. Ona ima mali, namjeran kritični put.

Preglednik dobiva HTML, ključni CSS, glavnu sliku sadržaja ako postoji, možda malu skriptu potrebnu za navigaciju ili interakciju iznad pregiba, i minimalni skup fontova potreban da tekst bude čitljiv. Sve ostalo čeka svoj red.

To je razlika između stranice koja je samo optimizirana i stranice koja se doima brzom.

Smanjivanje datoteka i dalje se isplati. Ali ako je web-lokacija već razumno komprimirana, sljedeća pobjeda u performansama obično nije još 2 KB uštede iz bundlea. To je jedan blokirajući zahtjev manje, jedna datoteka fonta manje, jedna skripta treće strane manje, jedan lanac ovisnosti manje.

Manje zahtjeva pojednostavljuje posao preglednika. Jednostavno je češće brzo nego što volimo priznati.