Nu există o modalitate mai rapidă de a încetini un site web (fără joc de cuvinte) decât să rulezi o grămadă de cod JavaScript pe el. Când utilizați JavaScript, trebuie să plătiți pentru performanța proiectului de cel puțin patru ori. Iată cu ce încarcă codul JavaScript al site-ului sistemele utilizatorilor:
- Încărcarea unui fișier prin rețea.
- Analizarea și compilarea codului sursă dezambalat după descărcare.
- Se execută cod JavaScript.
- Consumul de memorie.
Această combinație se dovedește a fi .
Și includem din ce în ce mai mult cod JS în proiectele noastre. Pe măsură ce organizațiile se îndreaptă către site-uri bazate pe cadre și biblioteci precum React, Vue și altele, facem ca funcționalitatea de bază a site-urilor să fie foarte dependentă de JavaScript.
Am văzut o mulțime de site-uri web foarte grele care folosesc cadre JavaScript. Dar viziunea mea asupra problemei este puternic părtinitoare. Cert este că companiile cu care lucrez vin la mine tocmai pentru că au probleme complexe de performanță a site-ului. Drept urmare, am devenit curios să știu cât de răspândită este această problemă și ce „amenzi” plătim atunci când alegem unul sau altul ca bază pentru un anumit site.
Acest proiect m-a ajutat să-mi dau seama. .
De date
Proiectul HTTP Archive urmărește un total de 4308655 de link-uri către site-uri desktop obișnuite și 5484239 de link-uri către site-uri mobile. Printre numeroșii indicatori asociați cu aceste legături se numără o listă de tehnologii găsite pe site-urile corespunzătoare. Aceasta înseamnă că putem eșantiona mii de site-uri care folosesc cadre și biblioteci diferite și putem afla cât de mult cod trimit clienților și cât de multă încărcare a aceluia cod pune pe sistemele utilizatorilor.
Am colectat date din martie 2020, care au fost cele mai recente date la care am avut acces.
Am decis să compar datele agregate de arhivă HTTP pentru toate site-urile cu datele pentru site-urile care s-au dovedit a utiliza React, Vue și Angular, deși m-am gândit să folosesc și alte surse.
Pentru a o face mai interesantă, am adăugat și site-uri care folosesc jQuery la setul de date sursă. Această bibliotecă este încă foarte populară. De asemenea, introduce o abordare a dezvoltării site-urilor web care diferă de modelul de aplicație cu o singură pagină (SPA) oferit de React, Vue și Angular.
Link-uri din Arhiva HTTP care reprezintă site-uri despre care s-a constatat că utilizează tehnologii de interes pentru noi
Cadru sau bibliotecă
Link-uri către site-uri mobile
Link-uri către site-uri obișnuite
jQuery
4615474
3714643
Reacţiona
489827
241023
Vue
85649
43691
Unghiular
19423
18088
Sperante si vise
Înainte de a trece la analiza datelor, vreau să vorbesc despre ceea ce aș vrea să sper.
Cred că într-o lume ideală, cadrele ar depăși satisfacerea nevoilor dezvoltatorilor și ar oferi unele beneficii concrete utilizatorilor de zi cu zi ai site-urilor noastre. Productivitatea este doar unul dintre aceste beneficii. Accesibilitatea și siguranța vin în minte și aici. Dar acesta este doar cel mai important lucru.
Deci, într-o lume ideală, un fel de cadru ar trebui să faciliteze crearea unui site web de înaltă performanță. Acest lucru ar trebui făcut fie datorită faptului că cadrul oferă dezvoltatorului o bază decentă pe care să construiască un proiect, fie datorită faptului că impune restricții asupra dezvoltării, propunând cerințe pentru acesta care îngreunează dezvoltarea a ceva. care se dovedește a fi lent.
Cele mai bune cadre ar trebui să facă ambele: să ofere o bază bună și să impună restricții asupra muncii care vă permit să obțineți un rezultat decent.
Analizarea valorilor medii ale datelor nu ne va oferi informațiile de care avem nevoie. Și, de fapt, această abordare lasă dincolo de atenția noastră . În schimb, am obținut scoruri percentile din datele pe care le aveam. Acestea sunt percentilele 10, 25, 50 (mediana), 75, 90.
Sunt interesat în special de percentilele a 10-a și a 90-a. Percentila a 10-a reprezintă cea mai bună performanță (sau cel puțin mai mult sau mai puțin aproape de cea mai bună) pentru un anumit cadru. Cu alte cuvinte, asta înseamnă că doar 10% dintre site-urile care folosesc un anumit cadru ajung la acest nivel sau un nivel superior. Percentila 90, pe de altă parte, este cealaltă față a monedei - ne arată cât de rele pot fi lucrurile. Cea de-a 90-a percentilă sunt site-urile de ultimă oră — ultimele 10% dintre site-uri care au cea mai mare cantitate de cod JS sau cel mai lung timp necesar pentru a-și procesa codul pe firul principal.
Volume de cod JavaScript
Pentru început, este logic să analizăm dimensiunea codului JavaScript transmis de diferite site-uri prin intermediul rețelei.
Cantitatea de cod JavaScript (KB) transferată pe dispozitive mobile
Percentile
10
25
50
75
90
Toate site-urile
93.4
196.6
413.5
746.8
1201.6
site-uri jQuery
110.3
219.8
430.4
748.6
1162.3
Site-uri web Vue
244.7
409.3
692.1
1065.5
1570.7
Site-uri web angulare
445.1
675.6
1066.4
1761.5
2893.2
React site-uri
345.8
441.6
690.3
1238.5
1893.6
Cantitatea de cod JavaScript trimisă pe dispozitivele mobile
Cantitatea de cod JavaScript (KB) transferată pe dispozitive desktop
Percentile
10
25
50
75
90
Toate site-urile
105.5
226.6
450.4
808.8
1267.3
site-uri jQuery
121.7
242.2
458.3
803.4
1235.3
Site-uri web Vue
248.0
420.1
718.0
1122.5
1643.1
Site-uri web angulare
468.8
716.9
1144.2
1930.0
3283.1
React site-uri
308.6
469.0
841.9
1472.2
2197.8
Cantitatea de cod JavaScript transferată pe dispozitive desktop
Dacă vorbim doar despre dimensiunea codului JS pe care site-urile îl trimit către dispozitive, atunci totul arată așa cum v-ați aștepta. Și anume, dacă se folosește unul dintre cadre, asta înseamnă că și într-o situație ideală, volumul de cod JavaScript pentru site va crește. Acest lucru nu este surprinzător - nu puteți face din un cadru JavaScript baza unui site și vă așteptați ca cantitatea de cod JS pentru proiect să fie foarte mică.
Ceea ce este interesant la aceste date este că unele cadre și biblioteci pot fi considerate puncte de plecare mai bune pentru un proiect decât altele. Site-urile web cu jQuery arată cel mai bine. Site-urile lor desktop conțin cu 15% mai mult JavaScript decât toate site-urile, iar site-urile lor mobile conțin cu 18% mai mult JavaScript. (Desigur, există o oarecare distorsiune în datele de aici. Faptul este că jQuery este prezent pe multe site-uri, deci este firesc ca astfel de site-uri să fie mai strâns legate de numărul total de site-uri decât altele. Cu toate acestea, acest lucru nu afectează modul în care datele sursă sunt ieșite pentru fiecare cadru.)
În timp ce creșterea codului de 15-18% este o cifră semnificativă, în comparație cu alte cadre și biblioteci, taxa impusă de jQuery este foarte mică. Site-urile unghiulare din a 10-a percentila trimit cu 344% mai multe date către dispozitivele desktop decât toate site-urile și cu 377% mai multe către dispozitivele mobile. Site-urile React sunt următoarele cele mai grele, trimițând cu 193% mai mult cod către dispozitivele desktop decât toate site-urile și cu 270% mai mult către dispozitivele mobile.
Am menționat mai devreme că, deși folosirea unui cadru înseamnă că o anumită cantitate de cod va fi inclusă în proiect chiar la începutul lucrului asupra acestuia, sper că framework-ul este capabil să limiteze cumva dezvoltatorul. În special, vorbim despre limitarea cantității maxime de cod.
Ceea ce este interesant este că site-urile jQuery urmează această idee. Deși, la nivelul percentilei 10, sunt puțin mai grele decât toate site-urile (cu 15-18%), ele, la nivelul percentilei 90, sunt puțin mai ușoare decât toate site-urile - cu aproximativ 3% atât în versiunea desktop, cât și în versiunea mobilă. Acest lucru nu înseamnă că acesta este un beneficiu foarte semnificativ, dar se poate spune că site-urile jQuery cel puțin nu au dimensiuni uriașe de cod JavaScript chiar și în versiunile lor cele mai mari.
Dar nu același lucru se poate spune despre alte cadre.
La fel ca și în cazul percentilei a 10-a, la percentilei a 90-a site-urile de pe Angular și React diferă de alte site-uri, dar diferă, din păcate, în mai rău.
La a 90-a percentila, site-urile Angular trimit cu 141% mai multe date către dispozitivele mobile decât toate site-urile și cu 159% mai multe către dispozitivele desktop. Site-urile React trimit cu 73% mai mult pe dispozitivele desktop decât toate site-urile și cu 58% mai mult către dispozitivele mobile. Dimensiunea codului site-urilor React la percentila 90 este de 2197.8 KB. Aceasta înseamnă că aceste site-uri trimit cu 322.9 KB mai multe date către dispozitivele mobile decât cei mai apropiați concurenți bazați pe Vue. Diferența dintre site-urile desktop bazate pe Angular și React și alte site-uri este și mai mare. De exemplu, site-urile desktop React trimit cu 554.7 KB mai mult cod JS către dispozitive decât site-urile Vue similare.
Timp necesar procesării codului JavaScript în firul principal
Datele de mai sus indică clar că site-urile care utilizează cadrele și bibliotecile studiate conțin cantități mari de cod JavaScript. Dar, desigur, aceasta este doar o parte a ecuației noastre.
După ce codul JavaScript a ajuns în browser, acesta trebuie adus într-o stare de funcționare. Mai ales multe probleme sunt cauzate de acele acțiuni care trebuie efectuate cu cod în firul principal al browserului. Firul principal este responsabil pentru procesarea acțiunilor utilizatorului, calcularea stilurilor și construirea și afișarea aspectului paginii. Dacă copleșiți firul principal cu sarcini JavaScript, acesta nu va avea posibilitatea de a finaliza alte sarcini în timp util. Acest lucru duce la întârzieri și „frâne” în funcționarea paginilor.
Baza de date HTTP Archive conține informații despre cât timp durează procesarea codului JavaScript în firul principal al motorului V8. Aceasta înseamnă că putem colecta aceste date și putem afla cât timp durează firul principal pentru a procesa JavaScript-ul diferitelor site-uri.
Timpul CPU (în milisecunde) legat de procesarea scripturilor pe dispozitivele mobile
Percentile
10
25
50
75
90
Toate site-urile
356.4
959.7
2372.1
5367.3
10485.8
site-uri jQuery
575.3
1147.4
2555.9
5511.0
10349.4
Site-uri web Vue
1130.0
2087.9
4100.4
7676.1
12849.4
Site-uri web angulare
1471.3
2380.1
4118.6
7450.8
13296.4
React site-uri
2700.1
5090.3
9287.6
14509.6
20813.3
Timpul CPU legat de procesarea scripturilor pe dispozitivele mobile
Timpul CPU (în milisecunde) legat de procesarea scripturilor pe dispozitivele desktop
Percentile
10
25
50
75
90
Toate site-urile
146.0
351.8
831.0
1739.8
3236.8
site-uri jQuery
199.6
399.2
877.5
1779.9
3215.5
Site-uri web Vue
350.4
650.8
1280.7
2388.5
4010.8
Site-uri web angulare
482.2
777.9
1365.5
2400.6
4171.8
React site-uri
508.0
1045.6
2121.1
4235.1
7444.3
Timpul CPU legat de procesarea scripturilor pe dispozitivele desktop
Aici puteți vedea ceva foarte familiar.
Pentru început, site-urile cu jQuery cheltuiesc mult mai puțin procesând JavaScript pe firul principal decât altele. La a 10-a percentila, comparativ cu toate site-urile, site-urile jQuery de pe dispozitive mobile petrec cu 61% mai mult timp procesând codul JS pe firul principal. În cazul site-urilor jQuery desktop, timpul de procesare crește cu 37%. La percentila 90, scorurile site-urilor jQuery sunt foarte apropiate de scorurile agregate. Mai exact, site-urile jQuery de pe dispozitivele mobile petrec cu 1.3% mai puțin timp în firul principal decât toate site-urile, iar pe dispozitivele desktop petrec cu 0.7% mai puțin timp în firul principal.
De cealaltă parte a evaluării noastre sunt cadrele care se caracterizează prin cea mai mare sarcină pe firul principal. Acesta este, din nou, Angular și React. Singura diferență dintre ele este că, deși site-urile Angular trimit cantități mai mari de cod către browsere decât site-urile React, este nevoie de mai puțin timp CPU pentru a procesa codul site-urilor Angular. Mult mai putin.
La a 10-a percentila, site-urile desktop Angular petrec cu 230% mai mult timp pentru thread-ul principal procesând codul JS decât toate site-urile. Pentru site-urile mobile, această cifră este de 313%. Site-urile React au cele mai slabe performanțe. Pe dispozitivele desktop ei petrec cu 248% mai mult timp procesând codul decât toate site-urile, iar pe dispozitivele mobile petrec cu 658% mai mult timp procesând codul. 658% nu este o greșeală de tipar. La a 10-a percentila, site-urile React petrec 2.7 secunde din timpul firului principal procesând codul existent.
Numerele percentilei 90 arată cel puțin puțin mai bine în comparație cu aceste numere uriașe. Proiectele angulare, în comparație cu toate site-urile, petrec cu 29% mai mult timp în firul principal pe dispozitive desktop și cu 27% mai mult timp pe dispozitive mobile. În cazul site-urilor React, indicatori similari arată ca 130%, respectiv 98%.
Procentele de abatere pentru a 90-a percentila arată mai bine decât valorile similare pentru a 10-a percentila. Dar aici merită să ne amintim că numerele care indică timpul par destul de înfricoșătoare. Să spunem - 20.8 secunde în firul principal al unui dispozitiv mobil pentru un site construit pe React. (Cred că povestea a ceea ce se întâmplă de fapt în acest timp este demnă de un articol separat).
Există o posibilă complicație aici (mulțumesc pentru că mi-a atras atenția asupra acestei caracteristici și pentru că am examinat cu atenție datele din acest punct de vedere). Faptul este că multe site-uri folosesc mai multe instrumente front-end. În special, am văzut multe site-uri care folosesc jQuery alături de React sau Vue, deoarece aceste site-uri migrează de la jQuery la alte cadre sau biblioteci. Drept urmare, am revenit la baza de date, selectând de data aceasta doar acele linkuri care corespundeau site-urilor care foloseau doar React, jQuery, Angular sau Vue, dar nu orice combinație a acestora. Iată ce am primit.
Timpul procesorului (în milisecunde) legat de procesarea scripturilor pe dispozitivele mobile în situațiile în care site-urile folosesc doar un cadru sau o singură bibliotecă
Percentile
10
25
50
75
90
Site-uri care folosesc doar jQuery
542.9
1062.2
2297.4
4769.7
8718.2
Site-uri care folosesc numai Vue
944.0
1716.3
3194.7
5959.6
9843.8
Site-uri care folosesc numai Angular
1328.9
2151.9
3695.3
6629.3
11607.7
Site-uri web care folosesc doar React
2443.2
4620.5
10061.4
17074.3
24956.3
Timpul procesorului legat de procesarea scripturilor pe dispozitive mobile într-o situație în care site-urile folosesc un singur cadru sau o singură bibliotecă
În primul rând, ceva care nu este surprinzător: atunci când un site folosește doar un cadru sau o singură bibliotecă, performanța unui astfel de site se îmbunătățește de cele mai multe ori. Performanța pentru fiecare instrument arată mai bine la percentilele 10 și 25. Are sens. Un site care este realizat folosind un cadru ar trebui să fie mai rapid decât un site care este realizat folosind două sau mai multe cadre sau biblioteci.
De fapt, scorurile pentru fiecare instrument front-end pe care l-am examinat au arătat mai bine în toate cazurile, cu o curioasă excepție. Ceea ce m-a surprins a fost că la percentila 50 și mai sus, site-urile care folosesc React au rezultate mai slabe când React este singura bibliotecă pe care o folosesc. Acesta, de altfel, a fost motivul pentru care am prezentat aceste date aici.
Acest lucru este puțin ciudat, dar voi încerca totuși să caut o explicație pentru această ciudățenie.
Dacă un proiect folosește atât React, cât și jQuery, atunci acel proiect este cel mai probabil undeva la jumătatea procesului de migrare de la jQuery la React. Poate că are o bază de cod în care aceste biblioteci sunt amestecate. Deoarece am văzut deja că site-urile jQuery petrec mai puțin timp pe firul principal decât site-urile React, acest lucru ne poate spune că implementarea unor funcționalități în jQuery ajută la îmbunătățirea performanței site-ului.
Dar pe măsură ce proiectul trece de la jQuery la React și se bazează din ce în ce mai mult pe React, situația se schimbă. Dacă site-ul este realizat cu o calitate cu adevărat înaltă, iar dezvoltatorii site-ului folosesc React cu atenție, atunci totul va fi bine cu un astfel de site. Dar pentru site-ul mediu React, utilizarea extensivă a React înseamnă că firul principal este supus unei sarcini crescute.
Diferența dintre dispozitivele mobile și desktop
Un alt mod în care am privit datele a fost să explorez cât de mare este diferența dintre experiențele mobile și cele desktop. Dacă vorbim despre compararea volumelor de cod JavaScript, atunci o astfel de comparație nu dezvăluie nimic teribil. Desigur, ar fi bine să vedem cantități mai mici de cod descărcabil, dar nu există o mare diferență în cantitatea de cod mobil și desktop.
Dar dacă analizezi timpul necesar procesării codului, devine vizibil un decalaj foarte mare între dispozitivele mobile și cele desktop.
Creștere în timp (în procente) legată de procesarea scripturilor pe dispozitivele mobile comparativ cu cele desktop
Percentile
10
25
50
75
90
Toate site-urile
144.1
172.8
185.5
208.5
224.0
site-uri jQuery
188.2
187.4
191.3
209.6
221.9
Site-uri web Vue
222.5
220.8
220.2
221.4
220.4
Site-uri web angulare
205.1
206.0
201.6
210.4
218.7
React site-uri
431.5
386.8
337.9
242.6
179.6
Deși este de așteptat o oarecare diferență în viteza de procesare a codului între un telefon și un laptop, un număr atât de mare îmi spune că cadrele moderne nu sunt suficient de vizate către dispozitivele cu consum redus și dorința de a reduce decalajul care a fost identificat. Chiar și la a 10-a percentila, site-urile React petrec cu 431.5% mai mult timp pe firul principal mobil decât pe firul principal desktop. jQuery are cel mai mic decalaj, dar chiar și aici cifra corespunzătoare este de 188.2%. Când dezvoltatorii de site-uri își realizează proiectele în așa fel încât necesită mai mult timp CPU pentru a le procesa (și asta se întâmplă și doar se înrăutățește în timp), proprietarii de dispozitive cu consum redus de energie trebuie să plătească pentru asta.
Rezultatele
Frame-urile bune ar trebui să ofere dezvoltatorilor o bază bună pentru construirea de proiecte web (în termeni de securitate, accesibilitate, performanță) sau ar trebui să aibă restricții încorporate care să facă dificilă crearea a ceva care încalcă aceste restricții.
Acest lucru nu pare să se aplice performanței proiectelor web (și, aparent, a acestora ).
Merită remarcat faptul că doar pentru că site-urile React sau Angular petrec mai mult timp CPU pregătind codul decât altele, nu înseamnă neapărat că site-urile React consumă mai mult CPU decât site-urile Vue atunci când rulează. De fapt, datele pe care le-am analizat spun foarte puțin despre performanța operațională a cadrelor și bibliotecilor. Ei vorbesc mai mult despre abordările de dezvoltare către care, conștient sau nu, aceste cadre pot împinge programatorii. Vorbim despre documentarea cadrelor, ecosistemul acestora și tehnicile comune de dezvoltare.
De asemenea, merită menționat un lucru pe care nu l-am analizat aici, și anume, cât timp petrece dispozitivul executând cod JavaScript atunci când face tranziția între paginile site-ului. Argumentul în favoarea SPA este că odată ce aplicația cu o singură pagină este încărcată în browser, utilizatorul va putea, teoretic, să acceseze mai rapid paginile site-ului. Propria mea experiență îmi spune că acest lucru este departe de a fi un fapt. Dar nu avem date care să clarifice această problemă.
Ceea ce este clar este că, dacă utilizați un cadru sau o bibliotecă pentru a crea un site web, faceți un compromis în ceea ce privește încărcarea inițială a proiectului și pregătirea acestuia pentru a începe. Acest lucru este valabil chiar și pentru cele mai pozitive scenarii.
Este posibil să faci unele compromisuri în situații adecvate, dar este important ca dezvoltatorii să facă astfel de compromisuri în mod conștient.
Dar avem și motive de optimism. Sunt încurajat de cât de strâns lucrează dezvoltatorii Chrome cu cei din spatele unora dintre instrumentele front-end pe care le-am acoperit pentru a ajuta la îmbunătățirea performanței acestor instrumente.
Cu toate acestea, sunt o persoană pragmatică. Noile arhitecturi creează probleme de performanță ori de câte ori le rezolvă. Și este nevoie de timp pentru a elimina deficiențele. Așa cum nu ar trebui să ne așteptăm la asta va rezolva toate problemele de performanță, nu ar trebui să vă așteptați la acest lucru de la noile versiuni ale cadrelor noastre preferate.
Dacă doriți să utilizați unul dintre instrumentele front-end discutate în acest material, aceasta înseamnă că va trebui să depuneți eforturi suplimentare pentru a vă asigura că, întâmplător, nu veți afecta performanța proiectului dumneavoastră. Iată câteva considerații de luat în considerare înainte de a începe să utilizați un nou cadru:
- Verificați-vă cu bunul simț. Chiar trebuie să utilizați cadrul pe care l-ați ales? JavaScript pur poate face multe astăzi.
- Există o alternativă mai ușoară la cadrul ales de dvs. (cum ar fi Preact, Svelte sau altceva) care vă poate oferi 90% din capacitățile acelui cadru?
- Dacă utilizați deja un cadru, gândiți-vă dacă există ceva care oferă opțiuni standard mai bune, mai conservatoare (de exemplu, Nuxt.js în loc de Vue, Next.js în loc de React etc.).
- Ce va ta Performanța JavaScript?
- Cum poți proces de dezvoltare pentru a face mai dificilă introducerea mai multor cod JavaScript într-un proiect decât este absolut necesar?
- Dacă utilizați un cadru pentru ușurință de dezvoltare, luați în considerare trimite cod cadru clienților. Poate poți rezolva toate problemele de pe server?
De obicei, aceste idei merită să le aruncăm o privire mai atentă, indiferent de ce anume alegeți să dezvoltați front end. Dar acestea sunt deosebit de importante atunci când lucrați la un proiect care nu are performanță pentru început.
Dragi cititori! Care credeți că este cadrul JavaScript ideal?
Sursa: www.habr.com