Kodėl jūsų svetainė turėtų siųsti mažiau užklausų, o ne tik mažesnes

Patogus mitas: „tiesiog sumažinkime kiekvieną failą“

Daugelį metų žiniatinklio našumo patarimai skambėjo paprastai: viską glaudinti, viską minifikuoti, kiekvieną išteklių padaryti mažesnį.

Šis patarimas vis dar iš esmės teisingas. 40 KB scenarijus paprastai yra geriau nei 400 KB scenarijus. Optimizuotas paveikslėlis yra geriau nei neapdorotas eksportas. Brotli, AVIF, CSS minifikavimas, tree shaking ir šriftų poaibiai — visa tai svarbu.

Tačiau daugelyje produkcinių svetainių didesnė problema nebėra vienas per didelis failas. Problema yra dalykų, kurių naršyklė turi paprašyti prieš puslapiui tampant tinkamam naudoti, skaičius.

Puslapis gali atrodyti tvarkingas pagal failų dydžius ir vis tiek būti lėtas, nes siunčia 120 užklausų: CSS fragmentus, JavaScript dalis, trečiųjų šalių žymas, šriftų failus, sekimo pikselius, piktogramų sprite’us, JSON galinius taškus, preloads, analitikos beacon’us ir podėlio pakartotinius patvirtinimus. Kiekvienas jų gali būti „mažas“. Kartu jie sukuria ilgą, trapų waterfall.

Praktinė taisyklė tokia: kai atskiri ištekliai jau yra pagrįstai suglaudinti, užklausų skaičiaus mažinimas dažnai pagerina naudotojo patirtį labiau nei kelių kilobaitų nuskutimas nuo kiekvieno failo.

Užklausos nėra vien baitai

Tinklo užklausa nėra tik duomenų perdavimas. Tai darbų seka.

Naršyklė turi aptikti išteklių, nuspręsti, kada jį gauti, suplanuoti jį kitų išteklių atžvilgiu, išsiųsti antraštes, palaukti serverio, gauti antraštes, išanalizuoti atsakymą, dažnai jį išskleisti ir tada su juo atlikti ką nors naudingo.

Tas „ką nors naudingo“ gali būti brangu. JavaScript failą reikia išanalizuoti, sukompiliuoti ir įvykdyti. CSS failas gali blokuoti atvaizdavimą. Šrifto failas gali uždelsti skaitomą tekstą arba sukelti išdėstymo poslinkius. Paveikslėlis gali paveikti Largest Contentful Paint elementą. Trečiosios šalies scenarijus gali atsinešti savo priklausomybių grandinę.

Todėl užklausų skaičius vis dar svarbus net tada, kai failai maži. 3 KB scenarijus gali būti blogiau nei 30 KB paveikslėlis, jei jis blokuoja atvaizdavimą, atkeliauja vėlai ir netinkamu momentu vykdomas pagrindinėje gijoje.

Jei skaitote Lighthouse ataskaitą ir jaučiatės baudžiami dešimtimis atskirų įspėjimų, pirmiausia žiūrėkite į užklausų waterfall, o ne į atskirus balus. Turime praktinį paaiškinimą straipsnyje, kaip skaityti Lighthouse ataskaitą nepanikuojant, bet trumpai: raskite, kas blokuoja pirmąjį atvaizdavimą ir kas vėlina pagrindinį turinį.

„Bet HTTP/2 tai išsprendė“ — dažniausiai ne

HTTP/2 ir HTTP/3 pakeitė užklausų ekonomiką. Jie įvedė multipleksavimą, antraščių glaudinimą ir geresnį ryšių elgesį. Paprastai tariant, naršyklės tapo daug geresnės siųsdamos kelias užklausas per mažiau ryšių.

Tai buvo tikras pagerėjimas. Jis taip pat panaikino kai kuriuos senus įpročius, pavyzdžiui, kraštutinius CSS sprite’us ir milžiniškus sujungtus paketus, kurių vienintelis tikslas buvo apeiti ryšių limitus.

Tačiau HTTP/2 nepadarė užklausų nemokamų.

Multipleksavimas padeda, kai daug išteklių dalijasi vienu ryšiu, bet naršyklė vis tiek turi jiems nustatyti prioritetus. Serveriai vis tiek turi atsakyti. Klientas vis tiek turi apdoroti kiekvieną atsakymą. Spūstys, paketų praradimas, TLS derinimas, DNS paieška, podėlio nepataikymai ir pagrindinės gijos apkrova niekur nedingo.

HTTP/3 pagerina kai kuriuos transporto sluoksnio aspektus, ypač ryšio migraciją ir head-of-line blokavimą transporto lygmenyje. Jis nepašalina išteklių aptikimo, planavimo, atsisiuntimo, analizavimo ir vykdymo kainos.

Todėl šiuolaikinis tikslas nėra „sudėti viską į vieną milžinišką failą“. Tikslas yra „siųsti mažiau kritinių užklausų, o likusias padaryti tikslingas“.

Tiesa matosi waterfall diagramoje

Našumo problemos retai apie save praneša vienu rodikliu. Jos pasirodo kaip forma.

Atidarykite naršyklės tinklo skydelį ir pažiūrėkite į pirmąsias kelias sekundes. Paklauskite:

• Kiek užklausų prasideda prieš pasirodant pagrindiniam turiniui?
• Kurios užklausos blokuoja atvaizdavimą?
• Ar svarbūs ištekliai aptinkami vėlai?
• Ar trečiųjų šalių scenarijai konkuruoja su jūsų CSS, šriftais ar paveikslėliais?
• Ar daug failų grąžina 304 atsakymus, užuot buvę pateikiami tiesiai iš podėlio?
• Ar piktogramos, šriftai ar UI fragmentai suskaidyti į daugiau failų, nei puslapiui reikia?

Greito puslapio ankstyvas waterfall paprastai būna nuobodus. Nedidelis kritinių išteklių skaičius atkeliauja anksti. Nekritiniai ištekliai palaukia. Trečiųjų šalių scenarijai atidedami, apribojami arba pašalinami. Naršyklė neverčiama žongliruoti dvidešimčia prioritetų prieš galėdama nupiešti puslapį.

Lėto puslapio waterfall dažnai būna neramus: daug mažų failų, daug kilmių ir daug vėlyvų aptikimų.

Mažesni failai vis dar svarbūs — tik ne vienodai

Tai nėra argumentas prieš glaudinimą ar optimizavimą. Tai argumentas prieš baitų optimizavimą ignoruojant koordinavimą.

Mažesni failai svarbiausi tada, kai išteklius yra didelis, blokuoja atvaizdavimą arba yra pagrindinio turinio kelio dalis. Pavyzdžiui:

• Hero paveikslėlis turėtų būti tinkamo dydžio ir tinkamai užkoduotas.
• Atvaizdavimą blokuojantis CSS turėtų būti lengvas.
• JavaScript, reikalingas pirmajai sąveikai, turėtų būti minimalus.
• Šriftai turėtų būti suskirstyti į poaibius, suglaudinti ir apriboti tik faktiškai naudojamais storiais.

Šriftai — dažnas pavyzdys. Komandos dažnai įstringa svarstydamos, ar šrifto failas yra 24 KB, ar 31 KB, tuo pat metu siųsdamos šešis storius, du stilius ir kelias šeimas. Geresnis sprendimas nėra nuskusti 7 KB nuo vieno failo. Geresnis sprendimas — siųsti mažiau šriftų failų. Jei tipografija yra jūsų našumo darbo dalis, žiniatinklio šriftai vis dar yra vienas lengviausių laimėjimų daugumoje svetainių.

Paveikslėliai veikia pagal tą patį modelį. AVIF arba WebP gali sutaupyti reikšmingai baitų, bet dešimties dekoratyvinių paveikslėlių siuntimas virš matomos ribos vis tiek yra blogas planas. Taip, rinkitės geresnius formatus, bet taip pat klauskite, ar kiekvieną paveikslėlį apskritai reikia užklausti. Formatų sprendimams mūsų gidas kada AVIF pranoksta WebP ir kada nepranoksta yra naudingas šio užklausų skaičiaus darbo palydovas.

Paslėptos daugelio mažų failų sąnaudos

Daug mažų užklausų linkusios sukurti problemų, kurios nepasirodo, jei žiūrite tik į bendrą perduotų baitų kiekį.

1. Vėlyvas aptikimas

Naršyklės negali užklausti to, ko dar neaptiko. CSS failas gali nurodyti šriftą. Scenarijus gali importuoti kitą scenarijų. Komponentas gali užklausti JSON po hydration. Kiekviena priklausomybė sukuria dar vieną grandinės žingsnį.

Kuo gilesnė grandinė, tuo vėliau prasideda svarbus darbas.

2. Antraščių pridėtinės sąnaudos

Kiekviena užklausa ir atsakymas turi antraštes. Antraščių glaudinimas padeda, ypač per HTTP/2 ir HTTP/3, bet pridėtinių sąnaudų nepanaikina. Slapukai gali tai gerokai pabloginti. Jei jūsų svetainė su kiekviena užklausa siunčia didelius slapukus, mažyčiai ištekliai praktiškai tampa nebe tokie mažyčiai.

Tai viena priežasčių, kodėl statiniai ištekliai dažnai turėtų būti laikomi keliuose ar domenuose be slapukų, ir kodėl podėlio antraštės nusipelno dėmesio. Jei antraštės produkcijoje elgiasi keistai, peradresavimų ir HTTP antraščių derinimas paprastai yra greitesnis nei spėliojimas.

3. Pagrindinės gijos pertraukinėjimas

Daug JavaScript dalių gali sukurti pasikartojantį analizavimo ir vykdymo darbą. Net jei kiekviena dalis maža, naršyklei gali tekti vis sustoti vertinti kodą. Tai gali pakenkti Interaction to Next Paint ir priversti puslapį jaustis trūkčiojantį.

Naudotojui nerūpi, kad kiekvienas failas buvo mažas. Jam rūpi, kad bakstelėjus meniu teko laukti 600 milisekundžių.

4. Podėlio sudėtingumas

Išteklių skaidymas gali pagerinti podėliavimą, kai daromas apgalvotai. Stabilus tiekėjo paketas ir besikeičiantis programos paketas gali būti geras padalijimas.

Tačiau perteklinis skaidymas į dalis gali atsisukti prieš jus. Daugiau failų reiškia daugiau podėlio patikrų, daugiau pakartotinio patvirtinimo galimybių, daugiau versijų koordinavimo ir daugiau būdų netyčia panaikinti išteklių, kurių nereikėjo keisti, galiojimą.

Bundling grįžta, bet su saiku

Pirmoji žiniatinklio našumo era mėgo bundling, nes naršyklės turėjo griežtus ryšių limitus. Tada pasirodė HTTP/2, ir daug komandų smarkiai pasuko agresyvaus kodo skaidymo link. Dalis to buvo naudinga. Dalis virto prietaru.

Protingas vidurys yra maršrutams pritaikytas bundling.

Tipinei rinkodaros ar turinio svetainei:

• Inline arba įkelkite tik CSS, reikalingą pradiniam atvaizdavimui.
• Laikykite globalų JavaScript mažą.
• Venkite skaidyti mažus modulius į atskiras tinklo užklausas.
• Atidėkite interaktyvias funkcijas, kurių nereikia iš karto.
• Pašalinkite trečiųjų šalių scenarijus, kurie nepateisina savo kainos.

Programai:

• Skaidykite pagal maršrutą arba didelę funkciją, o ne pagal kiekvieną komponentą.
• Laikykite bendras priklausomybes stabilias ir tinkamas podėliuoti.
• Preload naudokite tik ištekliams, kurių netrukus tikrai reikės.
• Venkite viešuose puslapiuose krauti administravimo, dashboard, redaktoriaus ar eksperimentų kodą.
• Matuokite sąveikos kainą, o ne tik paketo dydį.

Bundling nėra automatiškai gerai. Kodo skaidymas nėra automatiškai gerai. Naudingas klausimas toks: ar šis padalijimas padeda naršyklei greičiau pristatyti kitą prasmingą naudotojo patirtį?

Trečiųjų šalių užklausas verta vertinti ypač įtariai

Pirmosios šalies užklausos bent jau yra jūsų kontrolėje. Trečiųjų šalių užklausos dažnai yra lėtesnės, mažiau nuspėjamos ir brangesnės, nei atrodo.

Viena tag manager žyma gali paleisti analitiką, reklamas, heatmaps, pokalbių valdiklius, A/B testavimą, sutikimo įrankius ir personalizavimo scenarijus. Kiekvienas tiekėjas gali atsinešti daugiau užklausų. Kai kurios veiks anksti. Kai kurios blokuos pagrindinę giją. Kai kurios pasikeis be jūsų leidimo proceso.

Geriausia trečiųjų šalių optimizacija yra pašalinimas. Antra geriausia — atidėjimas.

Prieš pridėdami trečiosios šalies scenarijų, paklauskite:

• Ar tai turi būti įkelta prieš naudotojui pamatant puslapį?
• Ar tai turi būti įkelta kiekviename puslapyje?
• Ar tai gali būti įkelta po sutikimo, sąveikos arba idle time?
• Kas už tai atsakingas organizacijos viduje?
• Koks rodiklis įrodo, kad tai verta našumo kainos?

Čia našumas tampa valdymo klausimu. Kažkam turi būti leista pasakyti „ne“.

Praktinis užklausų mažinimo kontrolinis sąrašas

Pradėkite nuo svarbiausių puslapių: pagrindinio puslapio, kainodaros puslapio, produkto puslapio, atsiskaitymo, registracijos arba svarbiausių nukreipimo puslapių. Tada pereikite per waterfall.

Pašalinkite

• Ištrinkite nenaudojamą JavaScript ir CSS.
• Pašalinkite senus eksperimentus, apleistus pikselius ir dubliuotą analitiką.
• Atsisakykite nenaudojamų šriftų storių ir piktogramų bibliotekų.
• Dekoratyvinius paveikslėlius, kur tinka, pakeiskite CSS.

Apgalvotai sujunkite

• Sujunkite mažus JavaScript modulius, kurie visada įkeliami kartu.
• Sujunkite mažus CSS failus, kurie blokuoja tą patį atvaizdavimo kelią.
• Naudokite SVG sprite’us arba inline SVG pasikartojančioms piktogramoms, kai tai sumažina užklausas nepakenkiant palaikomumui.

Atidėkite

• Lazy-load naudokite paveikslėliams žemiau matomos ribos.
• Nekritinius scenarijus atidėkite iki pirmojo piešimo arba naudotojo sąveikos.
• Komentarus, embeds, žemėlapius, pokalbius ir vaizdo grotuvus įkelkite tik tada, kai jų reikia.

Tinkamai podėliuokite

• Versijuotiems statiniams ištekliams naudokite ilgalaikį podėliavimą.
• Venkite nereikalingo pakartotinio patvirtinimo failams, kurie retai keičiasi.
• HTML laikykite šviežią, bet leiskite hash turintiems ištekliams likti podėlyje.

Išmatuokite iš naujo

Po kiekvieno pakeitimo vėl patikrinkite waterfall. Tikslas nėra tobulas balas. Tikslas yra mažiau kritinių užklausų, ankstesnis naudingas atvaizdavimas ir mažiau pagrindinės gijos trikdymo.

Kaip atrodo geras rezultatas

Sveikas puslapis nebūtinai turi mažiausią įmanomą užklausų skaičių. Jis turi mažą, apgalvotą kritinį kelią.

Naršyklė gauna HTML, esminį CSS, pagrindinio turinio paveikslėlį, jei toks yra, galbūt mažą scenarijų, reikalingą navigacijai arba sąveikai virš matomos ribos, ir minimalų šriftų rinkinį, reikalingą tekstui padaryti skaitomam. Visa kita laukia savo eilės.

Tai skirtumas tarp puslapio, kuris tiesiog optimizuotas, ir puslapio, kuris jaučiasi greitas.

Mažinti failus vis dar verta. Tačiau jei svetainė jau pagrįstai suglaudinta, kitas našumo laimėjimas paprastai nėra dar 2 KB, sutaupyti iš paketo. Tai viena blokuojanti užklausa mažiau, vienas šrifto failas mažiau, vienas trečiosios šalies scenarijus mažiau, viena priklausomybių grandinė mažiau.

Mažiau užklausų supaprastina naršyklės darbą. Paprastumas dažniau yra greitas, nei norėtume pripažinti.