Ne postoji brži način za usporavanje web stranice (bez namjere igre) od pokretanja hrpe JavaScript koda na njoj. Kada koristite JavaScript, morate ga platiti u izvedbi projekta najmanje četiri puta. Evo čime JavaScript kôd web-mjesta učitava sustave korisnika:
- Prijenos datoteke preko mreže.
- Raščlanjivanje i kompajliranje raspakiranog izvornog koda nakon preuzimanja.
- Izvršavanje JavaScript koda.
- Potrošnja memorije.
Ova kombinacija ispada .
I uključujemo sve više i više JS koda u naše projekte. Kako se organizacije kreću ka web-mjestima koja pokreću okviri i biblioteke kao što su React, Vue i drugi, temeljnu funkcionalnost web-mjesta činimo vrlo ovisnom o JavaScriptu.
Vidio sam puno vrlo teških web stranica koje koriste JavaScript okvire. Ali moje viđenje problema je jako pristrano. Činjenica je da mi se tvrtke s kojima surađujem obraćaju upravo zato što imaju kompleksne probleme s radom web stranica. Kao rezultat toga, postao sam znatiželjan koliko je ovaj problem raširen i kakve „globe“ plaćamo kada odaberemo jedan ili drugi okvir kao osnovu za određenu stranicu.
Ovaj projekt mi je pomogao da to shvatim. .
Podaci
Projekt HTTP Archive prati ukupno 4308655 poveznica na redovite stolne stranice i 5484239 poveznica na mobilne stranice. Među mnogim pokazateljima povezanim s ovim vezama nalazi se popis tehnologija koje se nalaze na odgovarajućim stranicama. To znači da možemo uzorkovati tisuće stranica koje koriste različite okvire i biblioteke i naučiti koliko koda šalju klijentima i koliko taj kod opterećuje sustave korisnika.
Prikupio sam podatke od ožujka 2020., što su bili najnoviji podaci kojima sam imao pristup.
Odlučio sam usporediti agregirane podatke HTTP arhive za sve web-lokacije s podacima za web-lokacije za koje je utvrđeno da koriste React, Vue i Angular, iako sam razmišljao o korištenju i drugog izvornog materijala.
Kako bih ga učinio zanimljivijim, također sam dodao web stranice koje koriste jQuery skupu izvornih podataka. Ova je knjižnica još uvijek vrlo popularna. Također uvodi pristup razvoju web stranice koji se razlikuje od Single Page Application (SPA) modela koji nude React, Vue i Angular.
Veze u HTTP arhivi koje predstavljaju stranice za koje je utvrđeno da koriste tehnologije koje nas zanimaju
Okvir ili biblioteka
Veze na mobilne stranice
Linkovi na obične stranice
jQuery
4615474
3714643
Reagovati
489827
241023
Vue
85649
43691
Kutni
19423
18088
Nade i snovi
Prije nego što prijeđemo na analizu podataka, želim govoriti o tome čemu se želim nadati.
Vjerujem da bi u idealnom svijetu okviri išli dalje od zadovoljavanja potreba programera i pružali neke konkretne prednosti svakodnevnim korisnicima naših stranica. Produktivnost je samo jedna od tih prednosti. Ovdje također padaju na pamet pristupačnost i sigurnost. Ali ovo je samo ono najvažnije.
Dakle, u idealnom svijetu, neka vrsta okvira trebala bi olakšati stvaranje web stranice visokih performansi. To bi trebalo učiniti ili zbog činjenice da okvir daje razvojnom programeru pristojnu osnovu za izgradnju projekta ili zbog činjenice da nameće ograničenja razvoju, postavljajući zahtjeve za njega koji otežavaju razvoj nečega to ispada sporo.
Najbolji okviri trebali bi činiti oboje: pružiti dobru osnovu i nametnuti ograničenja u radu koja vam omogućuju postizanje pristojnog rezultata.
Analiza srednjih vrijednosti podataka neće nam dati informacije koje su nam potrebne. I, zapravo, ovaj pristup ostavlja izvan naše pažnje . Umjesto toga, iz podataka koje sam imao izveo sam postotke. To su 10, 25, 50 (medijan), 75, 90 percentili.
Posebno me zanimaju 10. i 90. percentil. 10. percentil predstavlja najbolju izvedbu (ili barem više ili manje blizu najbolje) za određeni okvir. Drugim riječima, to znači da samo 10% stranica koje koriste određeni framework doseže ovu razinu ili višu razinu. S druge strane, 90. percentil je druga strana medalje – on nam pokazuje koliko stvari mogu biti loše. 90. percentil su stranice na kraju—onih zadnjih 10% stranica koje imaju najveću količinu JS koda ili najdulje vrijeme potrebno za obradu njihovog koda na glavnoj niti.
Količine JavaScript koda
Za početak, ima smisla analizirati veličinu JavaScript koda koji prenose različite stranice putem mreže.
Količina JavaScript koda (KB) prenesena na mobilne uređaje
Percentili
10
25
50
75
90
Sve stranice
93.4
196.6
413.5
746.8
1201.6
jQuery stranice
110.3
219.8
430.4
748.6
1162.3
Vue web stranice
244.7
409.3
692.1
1065.5
1570.7
Angular web stranice
445.1
675.6
1066.4
1761.5
2893.2
Reagirajte web stranice
345.8
441.6
690.3
1238.5
1893.6
Količina JavaScript koda poslanog na mobilne uređaje
Količina JavaScript koda (KB) prenesena na stolne uređaje
Percentili
10
25
50
75
90
Sve stranice
105.5
226.6
450.4
808.8
1267.3
jQuery stranice
121.7
242.2
458.3
803.4
1235.3
Vue web stranice
248.0
420.1
718.0
1122.5
1643.1
Angular web stranice
468.8
716.9
1144.2
1930.0
3283.1
Reagirajte web stranice
308.6
469.0
841.9
1472.2
2197.8
Količina JavaScript koda prenesena na stolne uređaje
Ako govorimo samo o veličini JS koda koji stranice šalju uređajima, onda sve izgleda onako kako biste očekivali. Naime, ako se koristi jedan od frameworka, to znači da će se čak iu idealnoj situaciji volumen JavaScript koda za stranicu povećati. To nije iznenađujuće - ne možete napraviti JavaScript okvir kao temelj web stranice i očekivati da će količina JS koda za projekt biti vrlo niska.
Ono što je zanimljivo u vezi s ovim podacima je da se neki okviri i biblioteke mogu smatrati boljim polazištem za projekt od drugih. Web stranice s jQueryjem izgledaju najbolje. Njihove web stranice za stolna računala sadrže 15% više JavaScripta od svih web stranica, a njihove mobilne web stranice sadrže 18% više JavaScripta. (Doduše, ovdje postoji određena netočnost u podacima. Činjenica je da je jQuery prisutan na mnogim stranicama, pa je prirodno da su takve stranice uže povezane s ukupnim brojem stranica od ostalih. Međutim, to ne utječe na to kako izvorni podaci izlaze za svaki okvir.)
Iako je rast koda od 15-18% značajna brojka, u usporedbi s drugim okvirima i bibliotekama, porez koji nameće jQuery vrlo je nizak. Angular web-mjesta u 10. percentilu šalju 344% više podataka stolnim uređajima od svih web-mjesta i 377% više mobilnim uređajima. React web-mjesta su sljedeća po težini, šalju 193% više koda na desktop uređaje od svih web-mjesta i 270% više na mobilne uređaje.
Ranije sam spomenuo da iako korištenje okvira znači da će određena količina koda biti uključena u projekt na samom početku rada na njemu, nadam se da okvir može nekako ograničiti programera. Konkretno, govorimo o ograničavanju maksimalne količine koda.
Ono što je zanimljivo je da jQuery stranice slijede ovu ideju. Iako su one, na razini 10. percentila, nešto teže od svih stranica (za 15-18%), one su, na razini 90. percentila, nešto lakše od svih stranica - za oko 3% i u desktop i u mobilnoj verziji. To ne znači da je ovo vrlo značajna prednost, ali može se reći da jQuery stranice barem nemaju velike veličine JavaScript koda čak ni u svojim najvećim verzijama.
Ali isto se ne može reći za druge okvire.
Baš kao i u slučaju 10. percentila, na 90. percentilu mjesta na Angularu i Reactu razlikuju se od ostalih stranica, no razlikuju se, nažalost, na gore.
Na 90. percentilu, Angular web-mjesta šalju 141% više podataka mobilnim uređajima od svih web-mjesta i 159% više stolnim uređajima. React web-mjesta šalju 73% više na desktop uređaje od svih web-mjesta, a 58% više na mobilne uređaje. Veličina koda React stranica na 90. percentilu je 2197.8 KB. To znači da te stranice šalju 322.9 KB više podataka mobilnim uređajima od svojih najbližih konkurenata temeljenih na Vueu. Jaz između stolnih stranica temeljenih na Angularu i Reactu i drugih stranica još je veći. Na primjer, React desktop stranice šalju 554.7 KB više JS koda na uređaje od sličnih Vue stranica.
Vrijeme potrebno za obradu JavaScript koda u glavnoj niti
Gore navedeni podaci jasno pokazuju da stranice koje koriste proučavane okvire i biblioteke sadrže velike količine JavaScript koda. Ali, naravno, ovo je samo jedan dio naše jednadžbe.
Nakon što je JavaScript kod stigao u preglednik potrebno ga je dovesti u radno stanje. Osobito mnogo problema uzrokuju radnje koje se moraju izvršiti s kodom u glavnoj niti preglednika. Glavna nit je odgovorna za obradu korisničkih radnji, izračunavanje stilova te izgradnju i prikaz izgleda stranice. Ako glavnu nit zatrpate JavaScript zadacima, ona neće imati priliku izvršiti druge zadatke na vrijeme. To dovodi do kašnjenja i "kočnica" u radu stranica.
Baza podataka HTTP Archive sadrži informacije o tome koliko je vremena potrebno za obradu JavaScript koda na glavnoj niti V8 motora. To znači da možemo prikupiti te podatke i saznati koliko je vremena potrebno glavnoj niti za obradu JavaScripta različitih web stranica.
CPU vrijeme (u milisekundama) povezano s obradom skripte na mobilnim uređajima
Percentili
10
25
50
75
90
Sve stranice
356.4
959.7
2372.1
5367.3
10485.8
jQuery stranice
575.3
1147.4
2555.9
5511.0
10349.4
Vue web stranice
1130.0
2087.9
4100.4
7676.1
12849.4
Angular web stranice
1471.3
2380.1
4118.6
7450.8
13296.4
Reagirajte web stranice
2700.1
5090.3
9287.6
14509.6
20813.3
CPU vrijeme povezano s obradom skripte na mobilnim uređajima
CPU vrijeme (u milisekundama) povezano s obradom skripti na stolnim uređajima
Percentili
10
25
50
75
90
Sve stranice
146.0
351.8
831.0
1739.8
3236.8
jQuery stranice
199.6
399.2
877.5
1779.9
3215.5
Vue web stranice
350.4
650.8
1280.7
2388.5
4010.8
Angular web stranice
482.2
777.9
1365.5
2400.6
4171.8
Reagirajte web stranice
508.0
1045.6
2121.1
4235.1
7444.3
CPU vrijeme povezano s obradom skripti na stolnim uređajima
Ovdje možete vidjeti nešto vrlo poznato.
Za početak, stranice s jQueryjem troše znatno manje obrade JavaScripta na glavnu nit od ostalih. Na 10. percentilu, u usporedbi sa svim web-lokacijama, jQuery web-mjesta na mobilnim uređajima troše 61% više vremena na obradu JS koda na glavnoj niti. U slučaju stolnih jQuery stranica, vrijeme obrade povećava se za 37%. Na 90. percentilu, rezultati jQuery stranica vrlo su blizu ukupnih rezultata. Konkretno, jQuery stranice na mobilnim uređajima provode 1.3% manje vremena u glavnoj niti od svih web stranica, a na stolnim uređajima provode 0.7% manje vremena u glavnoj niti.
S druge strane naše ocjene su okviri koje karakterizira najveće opterećenje glavne niti. Ovo je, opet, Angular i React. Jedina razlika između njih je ta što, iako Angular stranice šalju veće količine koda preglednicima od React stranica, potrebno je manje CPU vremena za obradu koda Angular stranica. Daleko manje.
Na 10. percentilu, Angular web stranice za stolna računala troše 230% više vremena glavne niti na obradu JS koda od svih web stranica. Za mobilne stranice ta je brojka 313%. React stranice imaju najgore performanse. Na stolnim uređajima troše 248% više vremena na obradu koda od svih web stranica, a na mobilnim uređajima troše 658% više vremena na obradu koda. 658% nije greška pri upisu. Na 10. percentilu, React stranice troše 2.7 sekundi vremena glavne niti na obradu svog postojećeg koda.
Brojevi 90. percentila izgledaju barem malo bolje u usporedbi s ovim ogromnim brojevima. Angular projekti, u usporedbi sa svim stranicama, provode 29% više vremena u glavnoj niti na stolnim uređajima i 27% više vremena na mobilnim uređajima. U slučaju React stranica, slični pokazatelji izgledaju kao 130% odnosno 98%.
Postoci odstupanja za 90. percentil izgledaju bolje od sličnih vrijednosti za 10. percentil. Ali ovdje vrijedi zapamtiti da brojevi koji označavaju vrijeme izgledaju prilično zastrašujuće. Recimo - 20.8 sekundi u glavnoj niti mobilnog uređaja za stranicu izgrađenu na Reactu. (Vjerujem da je priča o tome što se zapravo događa tijekom tog vremena vrijedna zasebnog članka).
Ovdje postoji jedna potencijalna komplikacija (hvala što ste mi skrenuli pozornost na ovu značajku i što ste pažljivo ispitali podatke s ove točke gledišta). Činjenica je da mnoge stranice koriste nekoliko front-end alata. Konkretno, vidio sam puno stranica koje koriste jQuery uz React ili Vue dok te stranice migriraju s jQueryja na druge okvire ili biblioteke. Kao rezultat toga, vratio sam se u bazu podataka, ovaj put odabirući samo one poveznice koje odgovaraju stranicama koje koriste samo React, jQuery, Angular ili Vue, ali ne bilo koju njihovu kombinaciju. Evo što sam dobio.
Procesorsko vrijeme (u milisekundama) povezano s obradom skripti na mobilnim uređajima u situacijama kada web-mjesta koriste samo jedan okvir ili samo jednu biblioteku
Percentili
10
25
50
75
90
Stranice koje koriste samo jQuery
542.9
1062.2
2297.4
4769.7
8718.2
Stranice koje koriste samo Vue
944.0
1716.3
3194.7
5959.6
9843.8
Stranice koje koriste samo Angular
1328.9
2151.9
3695.3
6629.3
11607.7
Web stranice koje koriste samo React
2443.2
4620.5
10061.4
17074.3
24956.3
Procesorsko vrijeme vezano za obradu skripti na mobilnim uređajima u situaciji kada stranice koriste samo jedan okvir ili samo jednu biblioteku
Prvo, nešto što nije iznenađujuće: kada stranica koristi samo jedan okvir ili jednu biblioteku, performanse takve stranice se češće poboljšavaju nego ne. Izvedba za svaki instrument izgleda bolje na 10. i 25. percentilu. Ima smisla. Stranica koja je napravljena pomoću jednog okvira trebala bi biti brža od stranice koja je napravljena pomoću dva ili više okvira ili biblioteka.
Zapravo, rezultati za svaki front-end alat koji smo ispitali izgledali su bolje u svim slučajevima, s jednom čudnom iznimkom. Ono što me iznenadilo je da na 50. percentilu i više, stranice koje koriste React imaju lošiju izvedbu kada je React jedina biblioteka koju koriste. To je, inače, i bio razlog da ove podatke iznosim ovdje.
Ovo je malo čudno, ali ipak ću pokušati potražiti objašnjenje za tu neobičnost.
Ako projekt koristi i React i jQuery, tada je taj projekt najvjerojatnije negdje na pola puta u procesu prelaska s jQueryja na React. Možda on ima bazu kodova u kojoj su te biblioteke pomiješane. Budući da smo već vidjeli da jQuery web-mjesta troše manje vremena na glavnu nit nego React web-mjesta, to nam može reći da implementacija nekih funkcija u jQuery malo pomaže u poboljšanju performansi web-mjesta.
Ali kako se projekt pomiče s jQueryja na React i sve se više oslanja na React, situacija se mijenja. Ako je stranica izrađena doista visoke kvalitete, a programeri stranice pažljivo koriste React, onda će s takvom stranicom sve biti u redu. Ali za prosječnu React stranicu, opsežna upotreba Reacta znači da je glavna nit podložna povećanom opterećenju.
Jaz između mobilnih i stolnih uređaja
Drugi način na koji sam promatrao podatke bio je da istražim koliki je jaz između doživljaja na mobilnim uređajima i stolnih računala. Ako govorimo o usporedbi volumena JavaScript koda, onda takva usporedba ne otkriva ništa strašno. Naravno, bilo bi lijepo vidjeti manje količine koda za preuzimanje, ali nema velike razlike u količini mobilnog i desktop koda.
Ali ako analizirate vrijeme potrebno za obradu koda, postaje uočljiv vrlo veliki jaz između mobilnih i desktop uređaja.
Povećanje vremena (u postocima) vezano uz obradu skripte na mobilnim uređajima u usporedbi s onima na stolnim računalima
Percentili
10
25
50
75
90
Sve stranice
144.1
172.8
185.5
208.5
224.0
jQuery stranice
188.2
187.4
191.3
209.6
221.9
Vue web stranice
222.5
220.8
220.2
221.4
220.4
Angular web stranice
205.1
206.0
201.6
210.4
218.7
Reagirajte web stranice
431.5
386.8
337.9
242.6
179.6
Iako je za očekivati određenu razliku u brzini obrade koda između telefona i prijenosnog računala, tako veliki brojevi mi govore da moderni okviri nisu dovoljno usmjereni na uređaje niske potrošnje i želju da se premosti jaz koji je identificiran. Čak i na 10. percentilu, React stranice provode 431.5% više vremena na glavnoj niti za mobilne uređaje nego na glavnoj niti za stolna računala. jQuery ima najmanji razmak, ali čak i ovdje odgovarajuća brojka iznosi 188.2%. Kada programeri web stranica naprave svoje projekte na takav način da im je potrebno više CPU vremena za njihovu obradu (a to se događa i s vremenom postaje samo gore), vlasnici uređaja male snage to moraju platiti.
Rezultati
Dobri okviri trebali bi programerima dati dobru osnovu za izgradnju web projekata (u smislu sigurnosti, pristupačnosti, performansi) ili bi trebali imati ugrađena ograničenja koja otežavaju stvaranje nečega što krši ta ograničenja.
Čini se da se to ne odnosi na izvedbu web projekata (i očito na njihove ).
Vrijedno je napomenuti da samo zato što React ili Angular web-mjesta troše više CPU vremena na pripremu koda od drugih ne znači nužno da React web-mjesta intenzivnije rade na CPU-u od Vue web-mjesta kada se izvode. Zapravo, podaci koje smo pregledali govore vrlo malo o operativnim performansama okvira i knjižnica. Oni više govore o razvojnim pristupima prema kojima, svjesno ili ne, ovi okviri mogu potaknuti programere. Govorimo o dokumentaciji za okvire, njihov ekosustav i zajedničke razvojne tehnike.
Također je vrijedno spomenuti nešto što ovdje nismo analizirali, naime, koliko vremena uređaj troši na izvršavanje JavaScript koda pri prijelazu s jedne stranice na drugu. Argument u korist SPA-a je taj da će, nakon što se jednostranička aplikacija učita u preglednik, korisnik, u teoriji, moći brže pristupiti stranicama stranice. Vlastito iskustvo mi govori da je to daleko od činjenice. Ali nemamo podataka koji bi razjasnili ovo pitanje.
Ono što je jasno je da ako koristite okvir ili biblioteku za izradu web stranice, radite kompromis u smislu početnog učitavanja projekta i njegove pripreme za rad. To se odnosi čak i na najpozitivnije scenarije.
Moguće je napraviti neke kompromise u odgovarajućim situacijama, ali je važno da programeri takve kompromise rade svjesno.
Ali imamo i razloga za optimizam. Ohrabren sam koliko blisko Chromeovi razvojni programeri surađuju s onima koji stoje iza nekih prednjih alata koje smo pokrili kako bismo poboljšali izvedbu tih alata.
Međutim, ja sam pragmatična osoba. Nove arhitekture stvaraju probleme s performansama onoliko često koliko ih i rješavaju. I potrebno je vrijeme da se uklone nedostaci. Baš kao što to ne bismo trebali očekivati riješit će sve probleme s izvedbom, to ne biste trebali očekivati od novih verzija naših omiljenih okvira.
Ako želite koristiti jedan od front-end alata o kojima se govori u ovom materijalu, to znači da ćete morati uložiti dodatne napore kako biste bili sigurni da slučajno ne naštetite izvedbi svog projekta. Evo nekoliko stvari koje treba razmotriti prije nego počnete koristiti novi okvir:
- Provjerite se zdravim razumom. Trebate li doista koristiti odabrani okvir? Čisti JavaScript danas može učiniti mnogo.
- Postoji li lakša alternativa okviru po vašem izboru (kao što je Preact, Svelte ili nešto drugo) koja vam može dati 90% mogućnosti tog okvira?
- Ako već koristite framework, razmislite postoji li nešto što nudi bolje, konzervativnije, standardne opcije (primjerice Nuxt.js umjesto Vue, Next.js umjesto Reacta itd.).
- Što će vaš izvedba JavaScripta?
- Kako možeš razvojnog procesa kako bi bilo teže uvesti više JavaScript koda u projekt nego što je apsolutno potrebno?
- Ako koristite okvir za lakši razvoj, razmislite slanje koda okvira klijentima. Možda možete riješiti sve probleme na poslužitelju?
Obično se ove ideje isplati pobliže pogledati, bez obzira na to što točno odaberete za razvoj prednjeg dijela. No oni su posebno važni kada radite na projektu kojem nedostaje izvedba u početku.
Dragi čitatelji! Što vidite kao idealan JavaScript okvir?
Izvor: www.habr.com