Ni hitrejšega načina za upočasnitev spletnega mesta (namenjeno besedni igri), kot če na njem uporabite kup kode JavaScript. Ko uporabljate JavaScript, ga morate plačati z uspešnostjo projektov najmanj štirikrat. Tukaj je opisano, kako koda JavaScript spletnega mesta nalaga sisteme uporabnikov:
- Prenos datoteke prek omrežja.
- Razčlenjevanje in prevajanje nepakirane izvorne kode po prenosu.
- Izvajanje kode JavaScript.
- Poraba pomnilnika.
Ta kombinacija se izkaže .
In v svoje projekte vključujemo vedno več kode JS. Ko se organizacije usmerjajo k spletnim mestom, ki jih poganjajo ogrodja in knjižnice, kot so React, Vue in drugi, je osnovna funkcionalnost spletnih mest zelo odvisna od JavaScripta.
Videl sem veliko zelo težkih spletnih mest, ki uporabljajo okvire JavaScript. Toda moje videnje tega vprašanja je zelo pristransko. Dejstvo je, da se podjetja, s katerimi sodelujem name obračajo ravno zato, ker se soočajo s kompleksnimi problemi na področju delovanja strani. Posledično me je začelo zanimati, kako pogosta je ta težava in kakšne "kazni" plačamo, ko izberemo eno ali drugo ogrodje za osnovo določene strani.
Projekt mi je pomagal ugotoviti to. .
Podatki
Projekt HTTP Archive spremlja skupno 4308655 povezav do običajnih namiznih spletnih mest in 5484239 povezav do mobilnih spletnih mest. Med številnimi meritvami, povezanimi s temi povezavami, je seznam tehnologij, ki jih najdete na zadevnih spletnih mestih. To pomeni, da lahko vzorčimo na tisoče spletnih mest, ki uporabljajo različna ogrodja in knjižnice, ter izvemo, koliko kode pošljejo odjemalcem in koliko obremenitve ta koda ustvari za sisteme uporabnikov.
Zbral sem podatke marca 2020, ki so bili najnovejši podatki, do katerih sem imel dostop.
Odločil sem se primerjati združene podatke arhiva HTTP na vseh spletnih mestih s podatki s spletnih mest, najdenih z uporabo React, Vue in Angular, čeprav sem razmišljal tudi o uporabi drugega izvornega gradiva.
Da bi bilo bolj zanimivo, sem izvornemu naboru podatkov dodal tudi spletna mesta, ki uporabljajo jQuery. Ta knjižnica je še vedno zelo priljubljena. Prav tako uvaja drugačen pristop k spletnemu razvoju kot model Single Page Application (SPA), ki ga ponujajo React, Vue in Angular.
Povezave v arhivu HTTP, ki predstavljajo spletna mesta, za katera je bilo ugotovljeno, da uporabljajo zanimive tehnologije
Ogrodje ali knjižnica
Povezave do mobilnih spletnih mest
Povezave do običajnih spletnih mest
jQuery
4615474
3714643
Reagirajo
489827
241023
Vue
85649
43691
Kotna
19423
18088
Upanja in sanje
Preden preidemo na analizo podatkov, želim govoriti o tem, na kaj bi rad upal.
Prepričan sem, da bi v idealnem svetu okviri morali presegati potrebe razvijalcev in nuditi določene koristi povprečnemu uporabniku, ki dela z našimi spletnimi mesti. Zmogljivost je le ena od teh prednosti. Tukaj nastopita dostopnost in varnost. A to je le najpomembnejše.
Torej, v idealnem svetu bi moralo nekakšno ogrodje olajšati ustvarjanje visoko zmogljivega mesta. To je treba storiti bodisi zaradi dejstva, da okvir daje razvijalcu dostojno osnovo za gradnjo projekta, bodisi zaradi dejstva, da nalaga omejitve pri razvoju, postavlja zahteve zanj, ki otežujejo razvoj nečesa, kar se spremeni biti počasen.
Najboljši okviri bi morali narediti oboje: dati dobro osnovo in naložiti omejitve pri delu, kar vam omogoča, da dosežete spodoben rezultat.
Analiza srednjih vrednosti podatkov nam ne bo dala informacij, ki jih potrebujemo. In pravzaprav ta pristop izpusti našo pozornost . Namesto tega sem iz podatkov, ki sem jih imel, izpeljal odstotke. To so 10, 25, 50 (mediana), 75, 90 percentilov.
Še posebej me zanimata 10. in 90. percentil. 10. percentil predstavlja najboljšo zmogljivost (ali vsaj bolj ali manj blizu najboljše) za določen okvir. Z drugimi besedami, to pomeni, da le 10 % spletnih mest, ki uporabljajo določeno ogrodje, doseže to ali višjo raven. Po drugi strani pa je 90. percentil druga plat medalje – pokaže nam, kako slabe lahko postanejo stvari. 90. percentil so spletna mesta, ki zaostajajo – tistih spodnjih 10 % spletnih mest, ki imajo največ kode JS ali najdaljši čas za obdelavo svoje kode v glavni niti.
Količine kode JavaScript
Za začetek je smiselno analizirati velikost kode JavaScript, ki jo različna spletna mesta prenašajo po omrežju.
Količina kode JavaScript (Kb), prenesene v mobilne naprave
Percentili
10
25
50
75
90
Vsa spletna mesta
93.4
196.6
413.5
746.8
1201.6
spletna mesta jQuery
110.3
219.8
430.4
748.6
1162.3
Spletna mesta Vue
244.7
409.3
692.1
1065.5
1570.7
Kotna spletna mesta
445.1
675.6
1066.4
1761.5
2893.2
React Sites
345.8
441.6
690.3
1238.5
1893.6
Količina kode JavaScript, poslane mobilnim napravam
Količina kode JavaScript (Kb), prenesena v namizne naprave
Percentili
10
25
50
75
90
Vsa spletna mesta
105.5
226.6
450.4
808.8
1267.3
spletna mesta jQuery
121.7
242.2
458.3
803.4
1235.3
Spletna mesta Vue
248.0
420.1
718.0
1122.5
1643.1
Kotna spletna mesta
468.8
716.9
1144.2
1930.0
3283.1
React Sites
308.6
469.0
841.9
1472.2
2197.8
Količina kode JavaScript, poslana namiznim napravam
Če govorimo le o velikosti kode JS, ki jo spletna mesta pošiljajo napravam, potem je vse videti tako, kot bi morda pričakovali. Namreč, če je uporabljeno eno od ogrodij, to pomeni, da se bo tudi v idealni situaciji povečal obseg JavaScript kode spletnega mesta. To ni presenetljivo - ne morete narediti ogrodja JavaScript kot osnovo spletnega mesta in pričakovati, da bo obseg kode JS projekta zelo majhen.
Kar je izjemno pri teh podatkih, je, da se nekatera ogrodja in knjižnice lahko štejejo za boljše izhodišče za projekt kot drugi. Spletna mesta z jQuery izgledajo najbolje. Na namiznih različicah spletnih mest vsebujejo 15 % več JavaScripta kot vsa spletna mesta, na mobilnih pa 18 % več. (Res je, da je tukaj nekaj poškodovanih podatkov. Dejstvo je, da je jQuery prisoten na številnih spletnih mestih, zato je povsem naravno, da so takšna spletna mesta tesneje povezana s skupnim številom spletnih mest kot druga. Vendar to ne vpliva na surovo podatki se izpišejo za vsako ogrodje.)
Čeprav je 15–18-odstotno povečanje obsega kode pomembna številka, lahko v primerjavi z drugimi ogrodji in knjižnicami sklepamo, da je »davek«, ki ga zaračunava jQuery, zelo nizek. Spletna mesta Angular v 10. percentilu pošljejo 344 % več podatkov na namizne računalnike kot vsa spletna mesta in 377 % več na mobilne naprave. Spletna mesta React so naslednja najtežja, saj pošljejo 193 % več kode na namizje kot vsa spletna mesta in 270 % več na mobilne naprave.
Prej sem omenil, da čeprav uporaba ogrodja pomeni, da bo v projekt vključena določena količina kode, na samem začetku dela na njem upam, da bo ogrodje lahko nekako omejilo razvijalca. Zlasti govorimo o omejitvi največje količine kode.
Zanimivo je, da strani jQuery sledijo tej zamisli. Medtem ko so na 10. percentilu nekoliko težji od vseh spletnih mest (za 15–18 %), so na 90. percentilu nekoliko lažji s približno 3 % na namizju in mobilni napravi. To ne pomeni, da je to zelo pomembna prednost, lahko pa rečemo, da vsaj spletna mesta jQuery nimajo velikih kod JavaScript, niti v svojih največjih različicah.
Vendar tega ne moremo reči za druge okvire.
Tako kot pri 10. percentilu se tudi pri 90. percentilu mesta na Angularju in Reactu razlikujejo od drugih mest, vendar se žal razlikujejo na slabše.
Spletna mesta Angular na 90. percentilu pošljejo 141 % več podatkov v mobilne naprave kot vsa spletna mesta in 159 % več v namizne računalnike. Spletna mesta React pošljejo 73 % več na namizje kot vsa spletna mesta in 58 % več na mobilne naprave. Velikost kode mest React na 90. percentilu je 2197.8 KB. To pomeni, da takšna spletna mesta pošljejo 322.9 KB več podatkov v mobilne naprave kot njihovi najbližji konkurenti, ki temeljijo na Vue. Vrzel med namiznimi spletnimi mesti, ki temeljijo na Angular in React, ter drugimi spletnimi mesti je še večja. Spletna mesta React za namizne računalnike na primer pošljejo napravam 554.7 KB več kode JS kot enakovredna spletna mesta Vue.
Čas, potreben za obdelavo kode JavaScript v glavni niti
Zgornji podatki jasno kažejo, da spletna mesta, ki uporabljajo preučevana ogrodja in knjižnice, vsebujejo velike količine kode JavaScript. Seveda pa je to le en del naše enačbe.
Ko je koda JavaScript prispela v brskalnik, jo je treba spraviti v uporabno stanje. Še posebej veliko težav povzročajo dejanja, ki jih je treba izvesti s kodo v glavni niti brskalnika. Glavna nit je odgovorna za obdelavo uporabniških dejanj, za izračun slogov, za gradnjo in prikaz postavitve strani. Če glavno nit preobremenite z opravili JavaScript, ne bo imela možnosti pravočasno dokončati preostalih opravil. To vodi do zamud in "zavor" pri delu strani.
Baza podatkov HTTP Archive vsebuje informacije o tem, kako dolgo traja obdelava kode JavaScript v glavni niti motorja V8. To pomeni, da lahko zbiramo te podatke in ugotovimo, koliko časa potrebuje glavna nit za obdelavo JavaScripta različnih spletnih mest.
Procesorski čas (v milisekundah), povezan z obdelavo skripta v mobilnih napravah
Percentili
10
25
50
75
90
Vsa spletna mesta
356.4
959.7
2372.1
5367.3
10485.8
spletna mesta jQuery
575.3
1147.4
2555.9
5511.0
10349.4
Spletna mesta Vue
1130.0
2087.9
4100.4
7676.1
12849.4
Kotna spletna mesta
1471.3
2380.1
4118.6
7450.8
13296.4
React Sites
2700.1
5090.3
9287.6
14509.6
20813.3
Čas procesorja, povezan z obdelavo skriptov na mobilnih napravah
Čas procesorja (v milisekundah), povezan z obdelavo skripta v namiznih napravah
Percentili
10
25
50
75
90
Vsa spletna mesta
146.0
351.8
831.0
1739.8
3236.8
spletna mesta jQuery
199.6
399.2
877.5
1779.9
3215.5
Spletna mesta Vue
350.4
650.8
1280.7
2388.5
4010.8
Kotna spletna mesta
482.2
777.9
1365.5
2400.6
4171.8
React Sites
508.0
1045.6
2121.1
4235.1
7444.3
Čas procesorja, povezan z obdelavo skriptov na namiznih napravah
Tukaj lahko vidite nekaj zelo znanega.
Za začetek, spletna mesta z jQuery porabijo bistveno manj za obdelavo JavaScript v glavni niti kot druga spletna mesta. Pri 10. percentilu, v primerjavi z vsemi spletnimi mesti, spletna mesta jQuery na mobilnih napravah porabijo 61 % več časa za obdelavo kode JS v glavni niti. V primeru namiznih spletnih mest jQuery se čas obdelave poveča za 37 %. Pri 90. percentilu so mesta jQuery zelo blizu skupnim rezultatom. Natančneje, spletna mesta jQuery v mobilnih napravah porabijo 1.3 % manj časa za glavno nit kot vsa spletna mesta in 0.7 % manj časa v namiznih napravah.
Na drugi strani naše ocene so okviri, za katere je značilna največja obremenitev glavne niti. To je spet Angular in React. Edina razlika med obema je v tem, da medtem ko spletna mesta Angular pošiljajo brskalnikom več kode kot spletna mesta React, spletna mesta Angular potrebujejo manj časa procesorja za obdelavo kode. Precej manj.
Na 10. percentilu namizna spletna mesta Angular porabijo 230 % več časa za obdelavo kode JS glavne niti kot vsa spletna mesta. Za mobilna spletna mesta je ta številka 313 %. Najslabše se obnesejo mesta React. Na namizju porabijo 248 % več časa za obdelavo kode kot vsa spletna mesta in 658 % več na mobilnih napravah. 658% ni tipkarska napaka. Pri 10. percentilu mesta React porabijo 2.7 sekunde časa glavne niti za obdelavo svoje kode.
90. percentil v primerjavi s temi ogromnimi številkami izgleda vsaj malo bolje. V primerjavi z vsemi spletnimi mesti projekti Angular porabijo 29 % več časa na namiznih napravah v glavni niti in 27 % več časa na mobilnih napravah. V primeru spletnih mest React so iste številke videti kot 130 % oziroma 98 %.
Odstotna odstopanja za 90. percentil izgledajo bolje kot podobne vrednosti za 10. percentil. Toda tukaj je vredno zapomniti, da se številke, ki označujejo čas, zdijo precej strašljive. Recimo 20.8 sekunde na glavni mobilni niti za spletno mesto, izdelano z Reactom. (Mislim, da je zgodba o tem, kaj se dejansko zgodi v tem času, vredna ločenega članka).
Tu obstaja en potencialni zaplet (hvala ker ste me opozorili na to značilnost in ker ste natančno preučili podatke s tega vidika). Dejstvo je, da veliko spletnih mest uporablja več sprednjih orodij. Zlasti sem videl veliko spletnih mest, ki uporabljajo jQuery poleg React ali Vue, saj se ta mesta selijo iz jQuery v druga ogrodja ali knjižnice. Posledično sem znova udaril v bazo podatkov, tokrat pa sem izbral samo tiste povezave, ki ustrezajo spletnim mestom, ki uporabljajo samo React, jQuery, Angular ali Vue, ne pa katere koli kombinacije le-teh. Evo, kaj imam.
Procesorski čas (v milisekundah), povezan z obdelavo skriptov na mobilnih napravah v situaciji, ko spletna mesta uporabljajo samo eno ogrodje ali samo eno knjižnico
Percentili
10
25
50
75
90
Spletna mesta, ki uporabljajo samo jQuery
542.9
1062.2
2297.4
4769.7
8718.2
Spletna mesta, ki uporabljajo samo Vue
944.0
1716.3
3194.7
5959.6
9843.8
Spletna mesta, ki uporabljajo samo Angular
1328.9
2151.9
3695.3
6629.3
11607.7
Spletna mesta, ki uporabljajo samo React
2443.2
4620.5
10061.4
17074.3
24956.3
Čas procesorja, povezan z obdelavo skriptov na mobilnih napravah v situaciji, ko spletna mesta uporabljajo samo eno ogrodje ali samo eno knjižnico
Prvič, nekaj, kar ni presenetljivo: ko spletno mesto uporablja samo eno ogrodje ali eno knjižnico, se učinkovitost takšnega mesta pogosteje izboljša kot ne. Vsak instrument deluje bolje pri 10. in 25. percentilu. Je smiselno. Spletno mesto, ki je narejeno z enim ogrodjem, bi moralo delovati bolje kot spletno mesto, ki je narejeno z dvema ali več ogrodji ali knjižnicami.
Pravzaprav je delovanje vsakega proučevanega sprednjega orodja videti bolje v vseh primerih, razen ene radovedne izjeme. Presenetilo me je, da pri 50. percentilu in več spletna mesta, ki uporabljajo React, delujejo slabše, če je React edina knjižnica, ki jo uporabljajo. Mimogrede, to je bil razlog, da te podatke predstavljam tukaj.
To je malo nenavadno, a vseeno bom poskušal poiskati razlago za to nenavadnost.
Če projekt uporablja tako React kot jQuery, potem je ta projekt verjetno nekje na polovici prehoda iz jQuery v React. Morda ima kodno zbirko, kjer so te knjižnice mešane. Ker smo že videli, da spletna mesta jQuery porabijo manj časa za glavno nit kot spletna mesta React, nam to lahko pove, da implementacija nekaterih funkcij v jQuery pomaga spletnemu mestu nekoliko bolje delovati.
Ko pa projekt prehaja iz jQuery v React in se bolj zanaša na React, se stvari spreminjajo. Če je stran res kvalitetna in razvijalci strani skrbno uporabljajo React, potem bo s takšno stranjo vse v redu. Toda za povprečno spletno mesto React obsežna uporaba Reacta pomeni, da je glavna nit močno obremenjena.
Razkorak med mobilnimi in namiznimi napravami
Drugi vidik, s katerega sem pogledal raziskane podatke, je bil preučevanje, kako velik je razkorak med delom s spletnimi mesti na mobilnih in namiznih napravah. Če govorimo o primerjavi obsega kode JavaScript, potem takšna primerjava ne razkrije nič strašnega. Seveda bi bilo lepo videti manjše količine prenosljive kode, vendar ni velike razlike v količini mobilne in namizne kode.
Če pa analiziramo čas, potreben za obdelavo kode, postane opazen zelo velik razkorak med mobilnimi in namiznimi napravami.
Podaljšanje časa (v odstotkih), povezanega z obdelavo skriptov na mobilnih napravah v primerjavi z namiznimi
Percentili
10
25
50
75
90
Vsa spletna mesta
144.1
172.8
185.5
208.5
224.0
spletna mesta jQuery
188.2
187.4
191.3
209.6
221.9
Spletna mesta Vue
222.5
220.8
220.2
221.4
220.4
Kotna spletna mesta
205.1
206.0
201.6
210.4
218.7
React Sites
431.5
386.8
337.9
242.6
179.6
Čeprav je pričakovana določena razlika v hitrosti obdelave kode med telefonom in prenosnikom, mi tako velike številke povedo, da sodobna ogrodja niso dovolj usmerjena v naprave z nizko porabo energije in da si prizadevajo zapolniti vrzel, ki so jo odkrili. Celo pri 10. percentilu mesta React porabijo 431.5 % več časa za glavno nit mobilne naprave kot za glavno nit namizja. Najmanjši zaostanek ima jQuery, vendar je tudi tu ustrezna številka 188.2 %. Ko razvijalci spletnih strani naredijo svoje projekte tako, da njihova obdelava zahteva več procesorskega časa (in to se zgodi, in sčasoma postane le še slabše), morajo lastniki naprav z nizko porabo energije plačati za to.
Rezultati
Dobra ogrodja bi morala razvijalcem dati dobro osnovo za gradnjo spletnih projektov (v smislu varnosti, dostopnosti, zmogljivosti) ali pa bi morala imeti vgrajene omejitve, zaradi katerih je težko zgraditi nekaj, kar krši te omejitve.
Zdi se, da to ne velja za uspešnost spletnih projektov (in verjetno ne za njihove ).
Omeniti velja, da samo zato, ker spletna mesta React ali Angular porabijo več CPE-časa za pripravo kode kot druga, ne pomeni nujno, da so spletna mesta React med delovanjem bolj intenzivna CPE kot spletna mesta Vue. Pravzaprav podatki, ki smo jih pregledali, povedo zelo malo o operativni uspešnosti ogrodij in knjižnic. Več govorijo o razvojnih pristopih, ki jih lahko ti okviri, zavestno ali ne, potisnejo programerje. Govorimo o dokumentaciji za ogrodja, o njihovem ekosistemu, o skupnih razvojnih tehnikah.
Omeniti velja tudi nekaj, česar tukaj nismo analizirali, in sicer, koliko časa naprava porabi za izvajanje kode JavaScript pri navigaciji med stranmi spletnega mesta. Argument v prid SPA je, da ko bo aplikacija z eno stranjo naložena v brskalnik, bo uporabnik teoretično lahko hitreje odpiral strani spletnega mesta. Lastne izkušnje mi pravijo, da to še zdaleč ni dejstvo. Vendar nimamo podatkov, ki bi razjasnili to vprašanje.
Jasno je, da če uporabljate ogrodje ali knjižnico za ustvarjanje spletnega mesta, sklepate kompromis v smislu začetnega nalaganja projekta in priprave za uporabo. To velja tudi za najbolj pozitivne scenarije.
V ustreznih situacijah je povsem mogoče narediti nekaj kompromisov, vendar je pomembno, da razvijalci takšne kompromise sprejemajo zavestno.
Imamo pa tudi razlog za optimizem. Navdušen sem, ko vidim, kako tesno razvijalci Chroma sodelujejo z razvijalci nekaterih sprednjih orodij, ki smo jih pregledali, da bi pomagali izboljšati učinkovitost teh orodij.
Vendar sem pragmatična oseba. Nove arhitekture ustvarjajo težave z zmogljivostjo tako pogosto, kot jih rešujejo. In za odpravo napak je potreben čas. Tako kot ne smemo pričakovati bo rešil vse težave z zmogljivostjo, tega ne smete pričakovati od novih različic naših najljubših ogrodij.
Če želite uporabiti eno od sprednjih orodij, obravnavanih v tem članku, to pomeni, da se morate dodatno potruditi, da medtem ne škodujete uspešnosti vašega projekta. Tukaj je nekaj premislekov, ki jih morate upoštevati, preden začnete z novim okvirom:
- Preizkusite se z zdravo pametjo. Ali res morate uporabiti izbrano ogrodje? Čisti JavaScript danes zmore marsikaj.
- Ali obstaja lažja alternativa izbranemu ogrodju (na primer Preact, Svelte ali kaj drugega), ki vam lahko zagotovi 90 % zmogljivosti tega ogrodja?
- Če že uporabljate ogrodje, razmislite, ali obstaja kaj, kar ponuja boljše, bolj konzervativne, standardne možnosti (npr. Nuxt.js namesto Vue, Next.js namesto React itd.).
- Kaj bo vaš zmogljivosti JavaScript?
- Kako lahko razvojni proces, s katerim bi bilo težje vstaviti več kode JavaScript v projekt, kot je nujno potrebno?
- Če uporabljate okvir za lažji razvoj, razmislite pošlji okvirno kodo strankam. Morda lahko rešite vse težave na strežniku?
Običajno je vredno pogledati te ideje, ne glede na to, kaj natančno ste izbrali za front-end razvoj. Vendar so še posebej pomembni, ko delate na projektu, ki mu že od samega začetka manjka učinkovitost.
Drage bralke in bralci! Kako vidite idealno ogrodje JavaScript?
Vir: www.habr.com