Neexistuje rýchlejší spôsob, ako spomaliť webovú stránku (zamýšľanú slovná hračka), než na nej použiť kopu kódu JavaScript. Pri používaní JavaScriptu za to musíte zaplatiť výkonom projektov nie menej ako štvornásobok. Takto kód JavaScript stránky načítava systémy používateľov:
- Sťahovanie súboru cez sieť.
- Analýza a kompilácia rozbaleného zdrojového kódu po stiahnutí.
- Spustenie kódu JavaScript.
- Spotreba pamäte.
Táto kombinácia sa ukazuje .
A do našich projektov zaraďujeme stále viac JS kódu. Keďže organizácie smerujú k stránkam založeným na rámcoch a knižniciach, ako sú React, Vue a iné, základná funkčnosť stránok je veľmi závislá od JavaScriptu.
Videl som veľa veľmi ťažkých stránok používajúcich rámce JavaScript. Ale moja vízia problému je veľmi neobjektívna. Faktom je, že firmy, s ktorými spolupracujem, sa na mňa obracajú práve preto, že čelia zložitým problémom v oblasti výkonu stránok. V dôsledku toho som sa začal zaujímať o to, aký častý je tento problém a aké „pokuty“ platíme, keď si vyberieme ten či onen rámec ako základ pre určitú stránku.
Projekt mi pomohol prísť na to. .
Dáta
Projekt HTTP Archive sleduje celkovo 4308655 5484239 XNUMX odkazov na bežné stránky pre počítače a XNUMX XNUMX XNUMX odkazov na stránky pre mobilné zariadenia. Medzi mnohými metrikami spojenými s týmito odkazmi je zoznam technológií, ktoré sa nachádzajú na príslušných stránkach. To znamená, že môžeme vzorkovať tisíce stránok, ktoré používajú rôzne rámce a knižnice, a dozvedieť sa, koľko kódu posielajú klientom a akú záťaž tento kód vytvára v systémoch používateľov.
Zhromaždil som údaje z marca 2020, čo boli najnovšie údaje, ku ktorým som mal prístup.
Rozhodol som sa porovnať agregované údaje z archívu HTTP na všetkých stránkach s údajmi zo stránok nájdených pomocou React, Vue a Angular, hoci som zvažoval aj použitie iného zdrojového materiálu.
Aby to bolo zaujímavejšie, pridal som do zdrojového súboru údajov aj stránky, ktoré používajú jQuery. Táto knižnica je stále veľmi populárna. Zavádza tiež odlišný prístup k vývoju webu ako model Single Page Application (SPA), ktorý ponúkajú React, Vue a Angular.
Odkazy v archíve HTTP predstavujúce stránky, o ktorých sa zistilo, že používajú zaujímavé technológie
Rámec alebo knižnica
Odkazy na mobilné stránky
Odkazy na bežné stránky
jQuery
4615474
3714643
Reagovať
489827
241023
Vue
85649
43691
Hranatý
19423
18088
Nádeje a sny
Predtým, ako prejdeme k analýze údajov, chcem hovoriť o tom, v čo by som chcel dúfať.
Domnievam sa, že v ideálnom svete by rámce mali ísť nad rámec potrieb vývojárov a poskytovať nejaké špecifické výhody bežnému používateľovi, ktorý pracuje s našimi stránkami. Výkon je len jednou z týchto výhod. Tu vstupuje do hry dostupnosť a bezpečnosť. Ale toto je len to najdôležitejšie.
Takže v ideálnom svete by mal nejaký rámec uľahčovať vytváranie vysoko výkonnej stránky. Malo by sa to urobiť buď preto, že rámec dáva vývojárovi slušný základ, na ktorom môže stavať projekt, alebo preto, že ukladá obmedzenia na vývoj, kladie naň požiadavky, ktoré komplikujú vývoj niečoho, čo sa otáča. byť pomalý.
Najlepšie rámce by mali robiť oboje: poskytnúť dobrý základ a uvaliť obmedzenia na prácu, čo vám umožní dosiahnuť slušný výsledok.
Analýza stredných hodnôt údajov nám neposkytne informácie, ktoré potrebujeme. A v skutočnosti tento prístup vynecháva našu pozornosť . Namiesto toho som odvodil percentá z údajov, ktoré som mal. Ide o 10, 25, 50 (medián), 75, 90 percentilov.
Zaujíma ma najmä 10. a 90. percentil. 10. percentil predstavuje úplne najlepší výkon (alebo aspoň viac-menej blízko k najlepšiemu) pre konkrétny rámec. Inými slovami to znamená, že iba 10 % stránok používajúcich konkrétny rámec sa dostane na túto alebo vyššiu úroveň. Na druhej strane, 90. percentil je druhá strana mince – ukazuje nám, ako zlé môžu byť veci. 90. percentil sú stránky, ktoré zaostávajú za nimi – tých spodných 10 % stránok, ktoré majú najviac kódu JS alebo najdlhší čas na spracovanie kódu v hlavnom vlákne.
Objemy kódu JavaScript
Na začiatok má zmysel analyzovať veľkosť kódu JavaScript prenášaného rôznymi stránkami cez sieť.
Množstvo kódu JavaScript (Kb) preneseného do mobilných zariadení
Percentily
10
25
50
75
90
Všetky stránky
93.4
196.6
413.5
746.8
1201.6
stránky jQuery
110.3
219.8
430.4
748.6
1162.3
stránky Vue
244.7
409.3
692.1
1065.5
1570.7
Uhlové lokality
445.1
675.6
1066.4
1761.5
2893.2
Reagovať stránky
345.8
441.6
690.3
1238.5
1893.6
Množstvo kódu JavaScript odoslaného do mobilných zariadení
Množstvo kódu JavaScript (Kb) preneseného do stolných zariadení
Percentily
10
25
50
75
90
Všetky stránky
105.5
226.6
450.4
808.8
1267.3
stránky jQuery
121.7
242.2
458.3
803.4
1235.3
stránky Vue
248.0
420.1
718.0
1122.5
1643.1
Uhlové lokality
468.8
716.9
1144.2
1930.0
3283.1
Reagovať stránky
308.6
469.0
841.9
1472.2
2197.8
Množstvo kódu JavaScript odoslaného do stolných zariadení
Ak hovoríme iba o veľkosti kódu JS, ktorý stránky posielajú do zariadení, všetko vyzerá tak, ako by ste mohli očakávať. Totiž, ak sa použije niektorý z frameworkov, znamená to, že aj v ideálnej situácii sa zvýši objem JavaScript kódu stránky. To nie je prekvapujúce - nemôžete urobiť z JavaScript frameworku základ stránky a očakávať, že objem JS kódu projektu bude veľmi nízky.
Na týchto údajoch je pozoruhodné, že niektoré rámce a knižnice možno považovať za lepší východiskový bod pre projekt ako iné. Stránky s jQuery vyzerajú najlepšie. Na desktopových verziách webov obsahujú o 15 % viac JavaScriptu ako všetky weby a na mobiloch o 18 % viac. (Samozrejme, že tu dochádza k určitému poškodeniu údajov. Faktom je, že jQuery je prítomný na mnohých stránkach, takže je prirodzené, že takéto stránky sú viac spojené s celkovým počtom stránok ako iné. To však nemá vplyv na kvalitu údaje sú výstupom pre každý rámec.)
Zatiaľ čo 15-18% nárast objemu kódu je pozoruhodné číslo, v porovnaní s inými rámcami a knižnicami je možné dospieť k záveru, že „daň“ vyberaná jQuery je veľmi nízka. Uhlové weby v 10. percentile odosielajú o 344 % viac údajov do počítača ako všetky weby a o 377 % viac údajov do mobilu. Stránky React sú ďalšie najťažšie, odosielajú o 193 % viac kódu na počítač ako všetky weby a o 270 % viac na mobilné zariadenia.
Už dávnejšie som spomínal, že hoci použitie frameworku znamená, že do projektu bude zahrnuté určité množstvo kódu, na samom začiatku prác na ňom dúfam, že framework dokáže vývojára nejako obmedziť. Hovoríme najmä o obmedzení maximálneho množstva kódu.
Je zaujímavé, že stránky jQuery sa riadia touto myšlienkou. Aj keď sú na 10. percentile o niečo ťažšie ako všetky weby (o 15 – 18 %), na 90. percentile sú o niečo ľahšie, približne 3 % na počítačoch aj mobilných zariadeniach. To neznamená, že ide o veľmi významný prínos, ale dá sa povedať, že aspoň stránky jQuery nemajú veľké veľkosti kódu JavaScript, a to ani v ich najväčších verziách.
To sa však nedá povedať o iných rámcoch.
Rovnako ako v prípade 10. percentilu, aj na 90. percentile sa stránky na Angular a React líšia od iných stránok, ale líšia sa, žiaľ, k horšiemu.
Na 90. percentile posielajú weby Angular o 141 % viac dát do mobilu ako všetky weby a o 159 % viac do počítača. Stránky React posielajú o 73 % viac na počítač ako všetky weby a o 58 % viac na mobily. Veľkosť kódu stránok React na 90. percentile je 2197.8 KB. To znamená, že takéto stránky posielajú do mobilných zariadení o 322.9 KB viac dát ako ich najbližší konkurenti na základe Vue. Rozdiel medzi desktopovými webmi založenými na Angular a React a inými webmi je ešte väčší. Napríklad desktopové stránky React posielajú do zariadení o 554.7 KB viac JS kódu ako podobné stránky Vue.
Čas potrebný na spracovanie kódu JavaScript v hlavnom vlákne
Vyššie uvedené údaje jasne naznačujú, že stránky používajúce skúmané rámce a knižnice obsahujú veľké množstvo kódu JavaScript. Ale samozrejme, to je len jedna časť našej rovnice.
Po príchode kódu JavaScript do prehliadača je potrebné ho uviesť do funkčného stavu. Obzvlášť veľa problémov je spôsobených tými akciami, ktoré je potrebné vykonať s kódom v hlavnom vlákne prehliadača. Hlavné vlákno je zodpovedné za spracovanie akcií používateľa, za výpočet štýlov, za zostavenie a zobrazenie rozloženia stránky. Ak zahltíte hlavné vlákno úlohami JavaScript, nebude mať možnosť dokončiť ostatné úlohy včas. To vedie k oneskoreniam a "brzdám" v práci stránok.
Databáza HTTP Archive má informácie o tom, ako dlho trvá spracovanie kódu JavaScript v hlavnom vlákne motora V8. To znamená, že môžeme zbierať tieto údaje a zistiť, koľko času hlavnému vláknu trvá spracovanie JavaScriptu rôznych stránok.
Čas procesora (v milisekundách) súvisiaci so spracovaním skriptov na mobilných zariadeniach
Percentily
10
25
50
75
90
Všetky stránky
356.4
959.7
2372.1
5367.3
10485.8
stránky jQuery
575.3
1147.4
2555.9
5511.0
10349.4
stránky Vue
1130.0
2087.9
4100.4
7676.1
12849.4
Uhlové lokality
1471.3
2380.1
4118.6
7450.8
13296.4
Reagovať stránky
2700.1
5090.3
9287.6
14509.6
20813.3
Čas procesora súvisiaci so spracovaním skriptov na mobilných zariadeniach
Čas procesora (v milisekundách) súvisiaci so spracovaním skriptov na stolných zariadeniach
Percentily
10
25
50
75
90
Všetky stránky
146.0
351.8
831.0
1739.8
3236.8
stránky jQuery
199.6
399.2
877.5
1779.9
3215.5
stránky Vue
350.4
650.8
1280.7
2388.5
4010.8
Uhlové lokality
482.2
777.9
1365.5
2400.6
4171.8
Reagovať stránky
508.0
1045.6
2121.1
4235.1
7444.3
Čas procesora súvisiaci so spracovaním skriptov na stolných zariadeniach
Tu môžete vidieť niečo veľmi známe.
Pre začiatok, stránky s jQuery míňajú podstatne menej na spracovanie JavaScriptu v hlavnom vlákne ako iné stránky. Na 10. percentile v porovnaní so všetkými webmi trávia weby jQuery na mobilných zariadeniach o 61 % viac času spracovaním kódu JS v hlavnom vlákne. V prípade desktopových stránok jQuery sa doba spracovania zvyšuje o 37 %. Na 90. percentile majú stránky jQuery skóre veľmi blízko k súhrnnému skóre. Konkrétne stránky jQuery na mobilných zariadeniach trávia o 1.3 % menej času v hlavnom vlákne ako všetky stránky a o 0.7 % menej času na stolných zariadeniach.
Na druhej strane nášho hodnotenia sú frameworky, ktoré sa vyznačujú najvyšším zaťažením hlavného vlákna. Toto je opäť Angular a React. Jediný rozdiel medzi nimi je v tom, že zatiaľ čo stránky Angular posielajú prehliadačom viac kódu ako stránky React, stránky Angular potrebujú na spracovanie kódu menej času procesora. Ďaleko menej.
Na 10. percentile stránky Angular pre stolné počítače strávia o 230 % viac času spracovaním JS kódu hlavného vlákna ako všetky stránky. V prípade mobilných stránok je toto číslo 313 %. Stránky React sú na tom najhoršie. Na počítačoch strávia o 248 % viac času spracovaním kódu ako všetky weby a o 658 % viac na mobiloch. 658% nie je preklep. Na 10. percentile stránky React strávia spracovaním kódu 2.7 sekundy času hlavného vlákna.
90. percentil v porovnaní s týmito obrovskými číslami vyzerá aspoň o niečo lepšie. V porovnaní so všetkými stránkami trávia projekty Angular o 29 % viac času na stolných zariadeniach v hlavnom vlákne a o 27 % viac času na mobilných zariadeniach. V prípade stránok React vyzerajú rovnaké čísla ako 130 % a 98 %.
Percentuálne odchýlky pre 90. percentil vyzerajú lepšie ako podobné hodnoty pre 10. percentil. Tu je však potrebné pripomenúť, že čísla označujúce čas vyzerajú dosť strašidelne. Povedzme 20.8 sekundy na hlavnom mobilnom vlákne pre webovú stránku postavenú pomocou React. (Myslím si, že príbeh o tom, čo sa v tomto období skutočne deje, si zaslúži samostatný článok).
Je tu jedna potenciálna komplikácia (vďaka za to, že ste ma upozornili na túto vlastnosť a za starostlivé zváženie údajov z tohto hľadiska). Faktom je, že veľa stránok používa niekoľko front-end nástrojov. Najmä som videl veľa stránok, ktoré používajú jQuery spolu s React alebo Vue, pretože tieto stránky migrujú z jQuery do iných rámcov alebo knižníc. V dôsledku toho som znova zasiahol databázu, tentokrát som vybral iba tie odkazy, ktoré zodpovedajú stránkam, ktoré používajú iba React, jQuery, Angular alebo Vue, ale nie akúkoľvek ich kombináciu. Tu je to, čo som dostal.
Čas procesora (v milisekundách) súvisiaci so spracovaním skriptov na mobilných zariadeniach v situácii, keď stránky používajú iba jeden rámec alebo iba jednu knižnicu
Percentily
10
25
50
75
90
Stránky, ktoré používajú iba jQuery
542.9
1062.2
2297.4
4769.7
8718.2
Stránky, ktoré používajú iba Vue
944.0
1716.3
3194.7
5959.6
9843.8
Stránky, ktoré používajú iba Angular
1328.9
2151.9
3695.3
6629.3
11607.7
Stránky, ktoré používajú iba React
2443.2
4620.5
10061.4
17074.3
24956.3
Čas procesora súvisiaci so spracovaním skriptov na mobilných zariadeniach v situácii, keď stránky používajú iba jeden rámec alebo iba jednu knižnicu
Po prvé, niečo, čo nie je prekvapujúce: keď stránka používa iba jeden rámec alebo jednu knižnicu, výkon takejto stránky sa častejšie zlepšuje. Každý nástroj funguje lepšie na 10. a 25. percentile. To dáva zmysel. Stránka vytvorená pomocou jedného rámca by mala fungovať lepšie ako stránka vytvorená pomocou dvoch alebo viacerých rámcov alebo knižníc.
V skutočnosti výkon každého študovaného front-end nástroja vyzerá lepšie vo všetkých prípadoch, s výnimkou jednej kurióznej výnimky. Čo ma prekvapilo, bolo to, že na 50. percentile a vyššom dosahujú stránky používajúce React horšie výsledky, keď je React jedinou knižnicou, ktorú používajú. To bol mimochodom dôvod, prečo tu uvádzam tieto údaje.
Je to trochu zvláštne, ale aj tak sa pokúsim hľadať vysvetlenie pre túto zvláštnosť.
Ak projekt používa React aj jQuery, potom je tento projekt pravdepodobne niekde v polovici prechodu z jQuery na React. Možno má kódovú základňu, kde sú tieto knižnice zmiešané. Keďže sme už videli, že stránky jQuery trávia v hlavnom vlákne menej času ako stránky React, mohlo by nám to povedať, že implementácia niektorých funkcií do jQuery pomáha stránke fungovať o niečo lepšie.
Ale ako projekt prechádza z jQuery na React a viac sa spolieha na React, veci sa menia. Ak je stránka naozaj kvalitná a vývojári stránky používajú React opatrne, potom bude s takouto stránkou všetko v poriadku. Pre priemerný web React však rozsiahle používanie Reactu znamená, že hlavné vlákno je pod veľkým zaťažením.
Rozdiel medzi mobilnými a stolnými zariadeniami
Ďalším uhlom pohľadu, z ktorého som sa na skúmané dáta pozrel, bolo skúmanie, aká veľká je priepasť medzi prácou so stránkami na mobilných a desktopových zariadeniach. Ak hovoríme o porovnaní objemov kódu JavaScript, potom takéto porovnanie neodhalí nič hrozné. Samozrejme, bolo by pekné vidieť menšie množstvá kódu na stiahnutie, ale v množstve kódu pre mobil a počítač nie je veľký rozdiel.
Ak však analyzujeme čas potrebný na spracovanie kódu, zistíme, že medzi mobilnými a stolnými zariadeniami je veľmi veľký rozdiel.
Predĺženie času (percentuálny podiel) súvisiaceho so spracovaním skriptov na mobilných zariadeniach v porovnaní s počítačmi
Percentily
10
25
50
75
90
Všetky stránky
144.1
172.8
185.5
208.5
224.0
stránky jQuery
188.2
187.4
191.3
209.6
221.9
stránky Vue
222.5
220.8
220.2
221.4
220.4
Uhlové lokality
205.1
206.0
201.6
210.4
218.7
Reagovať stránky
431.5
386.8
337.9
242.6
179.6
Aj keď sa dá očakávať určitý rozdiel v rýchlosti spracovania kódu medzi telefónom a notebookom, také veľké čísla mi hovoria, že moderné rámce nie sú dostatočne zamerané na zariadenia s nízkou spotrebou energie a že sa snažia odstrániť medzeru, ktorú objavili. Dokonca aj na 10. percentile trávia stránky React o 431.5 % viac času v hlavnom vlákne pre mobilné zariadenia ako v hlavnom vlákne pre stolné počítače. Najmenšiu medzeru má jQuery, ale aj tu je zodpovedajúci údaj 188.2 %. Keď vývojári webových stránok robia svoje projekty tak, že ich spracovanie vyžaduje viac procesorového času (a stáva sa to a časom sa to len zhoršuje), majitelia zariadení s nízkou spotrebou za to musia zaplatiť.
Výsledky
Dobré rámce by mali poskytnúť vývojárom dobrý základ pre vytváranie webových projektov (pokiaľ ide o bezpečnosť, dostupnosť, výkon), alebo by mali mať zabudované obmedzenia, ktoré sťažujú vytváranie niečoho, čo tieto obmedzenia porušuje.
Zdá sa, že to neplatí pre výkon webových projektov (a pravdepodobne ani pre ich ).
Stojí za zmienku, že to, že stránky React alebo Angular trávia viac času procesora prípravou kódu ako iné, nemusí nutne znamenať, že stránky React sú počas prevádzky náročnejšie na procesor ako stránky Vue. V skutočnosti údaje, ktoré sme preskúmali, hovoria len veľmi málo o prevádzkovom výkone rámcov a knižníc. Hovoria viac o prístupoch k vývoju, ktoré, vedome alebo nie, môžu tieto rámce tlačiť na programátorov. Hovoríme o dokumentácii pre frameworky, o ich ekosystéme, o bežných technikách vývoja.
Za zmienku stojí aj niečo, čo sme tu neanalyzovali, a to, koľko času zariadenie strávi vykonávaním kódu JavaScript pri prechádzaní medzi stránkami webu. Argumentom v prospech SPA je, že po načítaní jednostránkovej aplikácie do prehliadača bude používateľ teoreticky schopný rýchlejšie otvárať stránky webu. Moja vlastná skúsenosť mi hovorí, že to zďaleka nie je skutočnosť. Nemáme však údaje na objasnenie tohto problému.
Je jasné, že ak na vytvorenie webovej stránky používate rámec alebo knižnicu, robíte kompromis, pokiaľ ide o počiatočné načítanie projektu a jeho prípravu na spustenie. To platí aj pre tie najpozitívnejšie scenáre.
Vo vhodných situáciách je úplne možné urobiť nejaké kompromisy, ale je dôležité, aby vývojári robili takéto kompromisy vedome.
Máme však aj dôvod na optimizmus. Teší ma, ako úzko spolupracujú vývojári prehliadača Chrome s vývojármi niektorých nástrojov front-end, ktoré sme preskúmali v snahe pomôcť zlepšiť výkon týchto nástrojov.
Som však pragmatický človek. Nové architektúry vytvárajú problémy s výkonom tak často, ako ich riešia. A oprava chýb si vyžaduje čas. Presne tak, ako by sme to neočakávali vyrieši všetky problémy s výkonom, nemali by ste to očakávať od nových verzií našich obľúbených rámcov.
Ak chcete použiť niektorý z nástrojov front-end, o ktorých sa hovorí v tomto článku, znamená to, že musíte vynaložiť ďalšie úsilie, aby ste medzitým nepoškodili výkon svojho projektu. Tu je niekoľko úvah, ktoré je potrebné zvážiť pred spustením nového rámca:
- Otestujte sa zdravým rozumom. Naozaj potrebujete použiť zvolený rámec? Čistý JavaScript dnes dokáže veľa.
- Existuje ľahšia alternatíva k zvolenému rámcu (ako Preact, Svelte alebo niečo iné), ktorá vám môže poskytnúť 90% schopností tohto rámca?
- Ak už používate framework, zvážte, či neexistuje niečo, čo ponúka lepšie, konzervatívnejšie, štandardné možnosti (napr. Nuxt.js namiesto Vue, Next.js namiesto React a tak ďalej).
- Čo bude tvoje Výkon JavaScriptu?
- Ako môžeš vývojový proces, ktorý sťaží vloženie väčšieho množstva kódu JavaScript do projektu, ako je absolútne nevyhnutné?
- Ak používate rámec pre jednoduchý vývoj, zvážte to posielať rámcový kód klientom. Možno dokážete vyriešiť všetky problémy na serveri?
Zvyčajne sa tieto nápady oplatí pozrieť, bez ohľadu na to, čo presne ste si vybrali pre vývoj front-endu. Ale sú dôležité najmä vtedy, keď pracujete na projekte, ktorému od začiatku chýba výkon.
Vážení čitatelia! Ako vidíte ideálny rámec JavaScriptu?
Zdroj: hab.com