Ne postoji brži način da usporite web stranicu (bez igre riječi) nego da na njoj pokrenete gomilu JavaScript koda. Kada koristite JavaScript, morate ga platiti u izvedbi projekta najmanje četiri puta. Evo čime JavaScript kod stranice učitava sisteme korisnika:
- Učitavanje fajla preko mreže.
- Parsiranje i kompajliranje raspakovanog izvornog koda nakon preuzimanja.
- Izvršavanje JavaScript koda.
- Potrošnja memorije.
Ispostavilo se da je ova kombinacija .
I mi uključujemo sve više JS koda u naše projekte. Kako se organizacije kreću ka web lokacijama koje pokreću okviri i biblioteke kao što su React, Vue i drugi, mi činimo jezgru funkcionalnosti stranica veoma zavisnim od JavaScripta.
Vidio sam mnogo vrlo teških web stranica koje koriste JavaScript okvire. Ali moja vizija ovog pitanja je izrazito pristrasna. Činjenica je da kompanije s kojima radim dolaze kod mene upravo zato što imaju složene probleme s radom web stranica. Kao rezultat toga, postao sam znatiželjan da saznam koliko je ovaj problem raširen i koje „kazne“ plaćamo kada izaberemo jedan ili drugi okvir kao osnovu za određenu stranicu.
Ovaj projekat mi je pomogao da ovo shvatim. .
podaci
HTTP Archive projekat prati ukupno 4308655 linkova ka redovnim desktop sajtovima i 5484239 linkova ka mobilnim sajtovima. Među brojnim pokazateljima povezanim sa ovim vezama je i lista tehnologija koje se nalaze na odgovarajućim stranicama. To znači da možemo uzorkovati hiljade lokacija koje koriste različite okvire i biblioteke i naučiti koliko koda šalju klijentima i koliko opterećenje taj kod stavlja na sisteme korisnika.
Prikupio sam podatke iz marta 2020. godine, što su bili najnoviji podaci kojima sam imao pristup.
Odlučio sam da uporedim agregirane podatke HTTP arhive za sve lokacije sa podacima za sajtove za koje je utvrđeno da koriste React, Vue i Angular, iako sam razmišljao o upotrebi i drugog izvornog materijala.
Da bi bilo zanimljivije, u izvorni skup podataka sam dodao i web lokacije koje koriste jQuery. Ova biblioteka je i dalje veoma popularna. Takođe uvodi pristup razvoju web stranica koji se razlikuje od modela Single Page Application (SPA) koji nude React, Vue i Angular.
Veze u HTTP arhivi koje predstavljaju sajtove za koje je utvrđeno da koriste tehnologije od interesa za nas
Okvir ili biblioteka
Linkovi na mobilne stranice
Linkovi ka redovnim stranicama
jQuery
4615474
3714643
reagovati
489827
241023
Vue
85649
43691
ugaoni
19423
18088
Nade i snovi
Prije nego što pređemo na analizu podataka, želim razgovarati o tome čemu bih se želio 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. Pristupačnost i sigurnost ovdje također padaju na pamet. Ali ovo je samo najvažnija stvar.
Dakle, u idealnom svijetu, neka vrsta okvira bi trebala olakšati kreiranje web stranice visokih performansi. To bi trebalo učiniti ili zbog činjenice da okvir daje 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 ispostavilo se da je to sporo.
Najbolji okviri bi trebali učiniti oboje: pružiti dobru osnovu i nametnuti ograničenja u radu koja vam omogućavaju da postignete pristojan rezultat.
Analiza srednjih vrijednosti podataka neće nam dati informacije koje su nam potrebne. I, u stvari, ovaj pristup napušta našu pažnju . Umjesto toga, izveo sam percentilne rezultate iz podataka koje sam imao. To su 10, 25, 50 (medijan), 75, 90 percentili.
Posebno me zanimaju 10. i 90. percentili. 10. percentil predstavlja najbolju izvedbu (ili barem više ili manje blizu najboljem) za određeni okvir. Drugim rečima, to znači da samo 10% sajtova koji koriste određeni okvir dostiže ovaj nivo ili viši nivo. 90. percentil je, s druge strane, druga strana medalje – pokazuje nam koliko loše stvari mogu biti. 90. percentil su zadnje lokacije—onih zadnjih 10% web lokacija koje imaju najveću količinu JS koda ili najduže vrijeme potrebno za obradu njihovog koda na glavnoj niti.
Volume JavaScript koda
Za početak, ima smisla analizirati veličinu JavaScript koda koji prenose različite stranice preko 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 lokacije
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 desktop uređaje
Percentili
10
25
50
75
90
Sve stranice
105.5
226.6
450.4
808.8
1267.3
jQuery lokacije
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 prenesenog na desktop 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 neki od okvira, to znači da će se čak i u idealnoj situaciji povećati obim JavaScript koda za stranicu. Ovo nije iznenađujuće – ne možete napraviti JavaScript okvir kao osnovu sajta i očekivati da će količina JS koda za projekat biti veoma mala.
Ono što je zanimljivo u vezi sa ovim podacima je da se neki okviri i biblioteke mogu smatrati boljom polaznom tačkom za projekat od drugih. Web lokacije sa jQueryjem izgledaju najbolje. Njihove desktop stranice sadrže 15% više JavaScripta od svih stranica, a njihove mobilne stranice sadrže 18% više JavaScripta. (Doduše, ovdje postoji određena iskrivljenost podataka. Činjenica je da je jQuery prisutan na mnogim stranicama, pa je prirodno da su takve stranice bliže povezane s ukupnim brojem stranica od drugih. Međutim, to ne utiče na to kako izvorni podaci izlaze za svaki okvir.)
Dok je rast koda od 15-18% značajan broj, u poređenju sa drugim okvirima i bibliotekama, porez koji nameće jQuery je veoma nizak. Angular web lokacije u 10. percentilu šalju 344% više podataka na desktop uređaje od svih web lokacija i 377% više na mobilne uređaje. React stranice su sljedeće po veličini, šalju 193% više koda na desktop uređaje od svih web lokacija i 270% više na mobilne uređaje.
Ranije sam spomenuo da iako korištenje framework-a znači da će određena količina koda biti uključena u projekat 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 oni, na nivou 10. percentila, nešto teži od svih sajtova (za 15-18%), oni su na nivou 90. percentila nešto lakši od svih sajtova - za oko 3% iu desktop iu mobilnoj verziji. Ovo ne znači da je ovo vrlo značajna prednost, ali se može reći da jQuery stranice barem nemaju velike veličine JavaScript koda čak ni u svojim najvećim verzijama.
Ali to se ne može reći za druge okvire.
Baš kao iu slučaju 10. percentila, na 90. percentilu stranice na Angularu i Reactu se razlikuju od drugih stranica, ali se razlikuju, nažalost, na gore.
Na 90. percentilu, Angular web lokacije šalju 141% više podataka na mobilne uređaje od svih web lokacija i 159% više na desktop uređaje. React stranice šalju 73% više na desktop uređaje od svih web lokacija i 58% više na mobilne uređaje. Veličina koda React lokacija na 90. percentilu je 2197.8 KB. To znači da ove stranice šalju 322.9 KB više podataka na mobilne uređaje od svojih najbližih konkurenata baziranih na Vueu. Jaz između desktop sajtova zasnovanih na Angularu i Reactu i drugih sajtova je još 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 na glavnoj niti
Gore navedeni podaci jasno pokazuju da web lokacije koje koriste proučavane okvire i biblioteke sadrže velike količine JavaScript koda. Ali, naravno, ovo je samo jedan dio naše jednačine.
Nakon što JavaScript kod stigne u pretraživač, potrebno ga je dovesti u radno stanje. Posebno mnoge probleme uzrokuju one radnje koje se moraju izvršiti s kodom u glavnoj niti pretraživača. Glavna nit je odgovorna za obradu radnji korisnika, izračunavanje stilova i izgradnju i prikaz izgleda stranice. Ako zatrpate glavnu nit JavaScript zadacima, ona neće imati priliku da obavi druge zadatke na vrijeme. To dovodi do kašnjenja i “kočnice” u radu stranica.
Baza podataka HTTP arhive sadrži informacije o tome koliko dugo je potrebno za obradu JavaScript koda na glavnoj niti V8 motora. To znači da možemo prikupiti ove podatke i saznati koliko je vremena potrebno glavnoj niti da obradi JavaScript različitih stranica.
CPU vrijeme (u milisekundama) vezano za obradu skripte na mobilnim uređajima
Percentili
10
25
50
75
90
Sve stranice
356.4
959.7
2372.1
5367.3
10485.8
jQuery lokacije
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 vezano za obradu skripte na mobilnim uređajima
CPU vrijeme (u milisekundama) vezano za obradu skripte na desktop uređajima
Percentili
10
25
50
75
90
Sve stranice
146.0
351.8
831.0
1739.8
3236.8
jQuery lokacije
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 vezano za obradu skripte na desktop uređajima
Ovdje možete vidjeti nešto vrlo poznato.
Za početak, sajtovi sa jQuery troše znatno manje obrade JavaScript-a na glavnoj niti od drugih. Na 10. percentilu, u poređenju sa svim sajtovima, jQuery sajtovi na mobilnim uređajima troše 61% više vremena na obradu JS koda na glavnoj niti. U slučaju desktop jQuery lokacija, vrijeme obrade se povećava za 37%. Na 90. percentilu, rezultati jQuery lokacija su vrlo blizu ukupnim ocjenama. Konkretno, jQuery stranice na mobilnim uređajima provode 1.3% manje vremena u glavnoj niti od svih web lokacija, a na desktop uređajima provode 0.7% manje vremena u glavnoj niti.
S druge strane naše ocjene su okviri koje karakterizira najveće opterećenje na glavnoj niti. Ovo je, opet, Angular i React. Jedina razlika između njih je u tome što, iako Angular web lokacije šalju veće količine koda u pretraživače nego React lokacije, potrebno je manje CPU vremena za obradu koda Angular lokacija. Daleko manje.
Na 10. percentilu, Angular desktop stranice troše 230% više vremena glavne niti na obradu JS koda od svih web lokacija. Za mobilne stranice ova brojka iznosi 313%. React stranice imaju najgore performanse. Na desktop uređajima troše 248% više vremena na obradu koda od svih web lokacija, a na mobilnim uređajima troše 658% više vremena na obradu koda. 658% nije greška u kucanju. Na 10. percentilu, React lokacije troše 2.7 sekundi vremena glavne niti na obradu svog postojećeg koda.
Brojevi od 90. percentila izgledaju barem malo bolje u poređenju sa ovim ogromnim brojevima. Angular projekti, u poređenju sa svim stranicama, provode 29% više vremena u glavnoj niti na desktop uređajima i 27% više vremena na mobilnim uređajima. U slučaju React lokacija, slični pokazatelji izgledaju kao 130% odnosno 98%.
Procenti odstupanja za 90. percentil izgledaju bolje od sličnih vrijednosti za 10. percentil. Ali ovdje vrijedi zapamtiti da brojke koje 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 šta se zapravo događa za ovo vrijeme vrijedna posebnog članka).
Ovdje postoji jedna potencijalna komplikacija (hvala za skretanje pažnje na ovu osobinu i za pažljivo ispitivanje podataka sa ove tačke gledišta). Činjenica je da mnoge stranice koriste nekoliko front-end alata. Konkretno, vidio sam mnogo web lokacija koje koriste jQuery uz React ili Vue jer se ove stranice migriraju sa jQueryja na druge okvire ili biblioteke. Kao rezultat toga, vratio sam se u bazu podataka, ovaj put odabravši samo one veze koje su odgovarale stranicama koje su koristile samo React, jQuery, Angular ili Vue, ali ne bilo koju njihovu kombinaciju. Evo šta sam dobio.
Vrijeme procesora (u milisekundama) povezano s obradom skripte na mobilnim uređajima u situacijama kada web stranice koriste samo jedan okvir ili samo jednu biblioteku
Percentili
10
25
50
75
90
Web lokacije koje koriste samo jQuery
542.9
1062.2
2297.4
4769.7
8718.2
Web lokacije koje koriste samo Vue
944.0
1716.3
3194.7
5959.6
9843.8
Web lokacije 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
Vrijeme procesora vezano za obradu skripti na mobilnim uređajima u situaciji kada web stranice koriste samo jedan okvir ili samo jednu biblioteku
Prvo, nešto što nije iznenađujuće: kada web lokacija koristi samo jedan okvir ili jednu biblioteku, performanse takve stranice se češće poboljšavaju nego ne. Performanse za svaki instrument izgledaju 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.
U stvari, rezultati za svaki front-end alat koji smo ispitali izgledali su bolje u svim slučajevima, sa jednim čudnim izuzetkom. Ono što me iznenadilo je da na 50. percentilu i više, stranice koje koriste React rade lošije kada je React jedina biblioteka koju koriste. To je, inače, bio razlog da ovdje iznosim ove podatke.
Ovo je malo čudno, ali ću ipak pokušati da potražim objašnjenje za ovu neobičnost.
Ako projekat koristi i React i jQuery, onda je taj projekat najvjerovatnije negdje na pola puta u procesu migracije sa jQueryja na React. Možda on ima kodnu bazu u kojoj su ove biblioteke pomiješane. Budući da smo već vidjeli da jQuery lokacije provode manje vremena na glavnoj niti nego React stranice, to nam može reći da implementacija neke funkcionalnosti u jQueryju pomaže da se malo poboljša performanse stranice.
Ali kako se projekat kreće sa jQueryja na React i sve više se oslanja na React, situacija se mijenja. Ako je stranica napravljena zaista kvalitetno, a programeri stranice pažljivo koriste React, onda će sve biti u redu s takvom web lokacijom. Ali za prosječnu React lokaciju, ekstenzivna upotreba Reacta znači da je glavna nit podložna povećanom opterećenju.
Jaz između mobilnih i desktop uređaja
Drugi način na koji sam pogledao podatke bio je da istražim koliki je jaz između mobilnih i desktop iskustava. Ako govorimo o poređenju volumena JavaScript koda, onda takvo poređenje ne otkriva ništa strašno. Naravno, bilo bi lijepo vidjeti manje količine koda za preuzimanje, ali nema velike razlike u količini koda za mobilni i desktop.
Ali ako analizirate vrijeme potrebno za obradu koda, postaje primjetan vrlo veliki jaz između mobilnih i desktop uređaja.
Povećanje vremena (u procentima) vezano za obradu skripte na mobilnim uređajima u odnosu na desktop uređaje
Percentili
10
25
50
75
90
Sve stranice
144.1
172.8
185.5
208.5
224.0
jQuery lokacije
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 se može očekivati određena razlika u brzini obrade koda između telefona i laptopa, tako veliki brojevi govore mi da moderni okviri nisu dovoljno ciljani na uređaje male snage i želju da se zatvori jaz koji je identificiran. Čak i na 10. percentilu, React lokacije provode 431.5% više vremena na glavnoj niti za mobilne uređaje nego na glavnoj niti na desktopu. jQuery ima najmanji jaz, 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 procesorskog vremena za njihovu obradu (a to se događa, a vremenom se samo pogoršava), vlasnici uređaja male potrošnje to moraju platiti.
Ishodi
Dobri okviri trebali bi programerima pružiti 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 ovo ne odnosi na izvedbu web projekata (i očigledno na njihove ).
Vrijedi napomenuti da samo zato što React ili Angular lokacije troše više CPU vremena na pripremu koda od drugih, ne znači nužno da su React lokacije više CPU-intenzivne od Vue lokacija kada su pokrenute. U stvari, podaci koje smo pogledali govore vrlo malo o operativnim performansama okvira i biblioteka. Oni više govore o razvojnim pristupima prema kojima, svjesno ili ne, ovi okviri mogu gurnuti programere. Govorimo o dokumentaciji za okvire, njihovom ekosistemu i uobičajenim tehnikama razvoja.
Vrijedi spomenuti i nešto što ovdje nismo analizirali, a to je koliko vremena uređaj troši na izvršavanje JavaScript koda prilikom tranzicije između stranica stranice. Argument u prilog SPA je da kada se aplikacija sa jednom stranicom učita u pretraživač, korisnik će, teoretski, moći brže da pristupi stranicama sajta. Moje iskustvo mi govori da je to daleko od činjenice. Ali nemamo podatke koji bi razjasnili ovo pitanje.
Ono što je jasno je da ako koristite okvir ili biblioteku za kreiranje web stranice, pravite kompromis u smislu početnog učitavanja projekta i spremanja za rad. Ovo se odnosi čak i na najpozitivnije scenarije.
Moguće je napraviti neke kompromise u odgovarajućim situacijama, ali je važno da programeri svjesno prave takve kompromise.
Ali imamo i razloga za optimizam. Ohrabruje me koliko blisko razvojni programeri Chromea rade sa onima koji stoje iza nekih od front-end alata koje smo pokrili kako bi pomogli u poboljšanju performansi tih alata.
Međutim, ja sam pragmatična osoba. Nove arhitekture stvaraju probleme performansi onoliko često koliko ih rješavaju. I potrebno je vrijeme da se otklone nedostaci. Kao što to ne treba očekivati će riješiti sve probleme s performansama, 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 osigurali da, uzgred, ne štetite performansama vašeg projekta. Evo nekoliko razmatranja koje treba uzeti u obzir prije nego počnete koristiti novi okvir:
- Provjerite sebe zdravim razumom. Da li zaista trebate koristiti okvir koji ste odabrali? Č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 okvir, razmislite da li postoji nešto što nudi bolje, konzervativnije, standardne opcije (na primjer, Nuxt.js umjesto Vue, Next.js umjesto Reacta, itd.).
- Šta će tvoj JavaScript performanse?
- Kako možeš razvojnog procesa kako bi se otežalo uvođenje više JavaScript koda u projekat nego što je apsolutno neophodno?
- Ako koristite okvir za lakši razvoj, razmislite poslati Framework kod klijentima. Možda možete riješiti sve probleme na serveru?
Obično, ove ideje vredi pažljivije pogledati, bez obzira na to šta tačno odaberete za razvoj prednjeg dela. Ali oni su posebno važni kada radite na projektu koji za početak nema performanse.
Dragi čitaoci! Šta vidite kao idealan JavaScript okvir?
izvor: www.habr.com