Neexistuje rychlejší způsob, jak zpomalit web (bez slovní hříčky), než na něm spustit hromadu kódu JavaScript. Při použití JavaScriptu za to musíte zaplatit ve výkonu projektu minimálně čtyřikrát. Kód JavaScript webu načítá systémy uživatelů takto:
- Nahrání souboru přes síť.
- Analýza a kompilace rozbaleného zdrojového kódu po stažení.
- Spouštění kódu JavaScript.
- Spotřeba paměti.
Tato kombinace se ukazuje být .
A do našich projektů zařazujeme stále více JS kódu. Vzhledem k tomu, že organizace přecházejí na stránky založené na rámcích a knihovnách jako React, Vue a další, činí základní funkce stránek velmi závislými na JavaScriptu.
Viděl jsem spoustu velmi těžkých webových stránek používajících frameworky JavaScript. Ale moje vize problému je silně zaujatá. Faktem je, že firmy, se kterými pracuji, za mnou přicházejí právě proto, že mají složité problémy s výkonem webu. V důsledku toho jsem se začal zajímat o to, jak rozšířený je tento problém a jaké „pokuty“ platíme, když si jako základ pro určitý web vybereme ten či onen rámec.
Tento projekt mi pomohl to zjistit. .
Data
Projekt HTTP Archive sleduje celkem 4308655 5484239 XNUMX odkazů na běžné stránky pro počítače a XNUMX XNUMX XNUMX odkazů na mobilní stránky. Mezi mnoha indikátory spojenými s těmito odkazy je seznam technologií nalezených na odpovídajících stránkách. To znamená, že můžeme ochutnat tisíce webů, které používají různé rámce a knihovny, a zjistit, kolik kódu posílají klientům a jakou zátěž tento kód zatěžuje systémy uživatelů.
Sbíral jsem data z března 2020, což byla nejnovější data, ke kterým jsem měl přístup.
Rozhodl jsem se porovnat agregovaná data HTTP Archive pro všechny weby s daty pro weby, u kterých bylo zjištěno, že používají React, Vue a Angular, i když jsem zvažoval použití i jiného zdrojového materiálu.
Aby to bylo zajímavější, přidal jsem do zdrojové datové sady také weby, které používají jQuery. Tato knihovna je stále velmi oblíbená. Představuje také přístup k vývoji webových stránek, který se liší od modelu Single Page Application (SPA) nabízeného společnostmi React, Vue a Angular.
Odkazy v archivu HTTP představující stránky, u kterých bylo zjištěno, že používají technologie, které nás zajímají
Rámec nebo knihovna
Odkazy na mobilní stránky
Odkazy na běžné stránky
jQuery
4615474
3714643
REACT
489827
241023
Vue
85649
43691
ANGULAR
19423
18088
Naděje a sny
Než přejdeme k analýze dat, chci mluvit o tom, v co bych chtěl doufat.
Domnívám se, že v ideálním světě by frameworky šly nad rámec plnění potřeb vývojářů a poskytovaly by určité konkrétní výhody každodenním uživatelům našich stránek. Produktivita je jen jednou z těchto výhod. Myslí se zde i na dostupnost a bezpečnost. Ale to je jen to nejdůležitější.
Takže v ideálním světě by měl nějaký rámec usnadnit vytvoření vysoce výkonného webu. To by mělo být provedeno buď kvůli skutečnosti, že rámec poskytuje vývojáři slušný základ, na kterém může stavět projekt, nebo kvůli skutečnosti, že ukládá omezení na vývoj a klade na něj požadavky, které ztěžují vývoj něčeho. to se ukazuje být pomalé.
Nejlepší rámce by měly dělat obojí: poskytovat dobrý základ a ukládat omezení práce, která vám umožní dosáhnout slušného výsledku.
Analýza středních hodnot dat nám neposkytne informace, které potřebujeme. A ve skutečnosti tento přístup nechává mimo naši pozornost . Místo toho jsem z dat, která jsem měl, odvodil percentilové skóre. Jedná se o percentily 10, 25, 50 (medián), 75, 90.
Zajímají mě zejména 10. a 90. percentil. Desátý percentil představuje nejlepší výkon (nebo alespoň více či méně blízko nejlepšímu) pro konkrétní rámec. Jinými slovy to znamená, že pouze 10 % webů využívajících konkrétní framework dosáhne této úrovně nebo vyšší úrovně. 10. percentil je naopak druhá strana mince – ukazuje nám, jak špatné věci mohou být. 90. percentil jsou koncové weby – posledních 90 % webů, které mají největší množství kódu JS nebo nejdelší čas potřebný ke zpracování kódu v hlavním vláknu.
Objemy kódu JavaScript
Pro začátek má smysl analyzovat velikost kódu JavaScript přenášeného různými weby po síti.
Množství kódu JavaScript (KB) přeneseného do mobilních zařízení
Percentily
10
25
50
75
90
Všechny weby
93.4
196.6
413.5
746.8
1201.6
stránky jQuery
110.3
219.8
430.4
748.6
1162.3
webové stránky Vue
244.7
409.3
692.1
1065.5
1570.7
Angular webové stránky
445.1
675.6
1066.4
1761.5
2893.2
Reagovat weby
345.8
441.6
690.3
1238.5
1893.6
Množství kódu JavaScript odeslaného do mobilních zařízení
Množství kódu JavaScript (KB) přeneseného do stolních zařízení
Percentily
10
25
50
75
90
Všechny weby
105.5
226.6
450.4
808.8
1267.3
stránky jQuery
121.7
242.2
458.3
803.4
1235.3
webové stránky Vue
248.0
420.1
718.0
1122.5
1643.1
Angular webové stránky
468.8
716.9
1144.2
1930.0
3283.1
Reagovat weby
308.6
469.0
841.9
1472.2
2197.8
Množství kódu JavaScript přenesené do stolních zařízení
Pokud se budeme bavit pouze o velikosti JS kódu, který stránky odesílají do zařízení, pak vše vypadá tak, jak byste mohli očekávat. Totiž, pokud je použit některý z frameworků, znamená to, že i v ideální situaci se objem JavaScript kódu pro web zvýší. To není překvapivé – nemůžete udělat z JavaScriptového frameworku základ webu a očekávat, že množství JS kódu pro projekt bude velmi nízké.
Na těchto datech je zajímavé, že některé rámce a knihovny lze považovat za lepší výchozí body projektu než jiné. Weby s jQuery vypadají nejlépe. Jejich weby pro počítače obsahují o 15 % více JavaScriptu než všechny weby a jejich mobilní weby obsahují o 18 % více JavaScriptu. (Je pravda, že zde dochází k určitému zkreslení údajů. Faktem je, že jQuery je přítomen na mnoha webech, takže je přirozené, že takové weby souvisejí s celkovým počtem webů těsněji než jiné. To však nemá vliv na to, jak zdrojová data jsou výstupem pro každý rámec.)
Zatímco 15-18% růst kódu je významné číslo, ve srovnání s jinými frameworky a knihovnami je daň uvalená jQuery velmi nízká. Úhlové weby v 10. percentilu odesílají o 344 % více dat do stolních zařízení než všechny weby a o 377 % více do mobilních zařízení. Weby React jsou další nejtěžší, odesílají o 193 % více kódu na stolní zařízení než všechny weby a o 270 % více do mobilních zařízení.
Již dříve jsem zmínil, že ačkoli použití frameworku znamená, že určité množství kódu bude zahrnuto do projektu hned na začátku práce na něm, doufám, že framework dokáže vývojáře nějak omezit. Zejména mluvíme o omezení maximálního množství kódu.
Zajímavé je, že weby jQuery se této myšlenky řídí. Přestože jsou na úrovni 10. percentilu o něco těžší než všechny weby (o 15–18 %), na úrovni 90. percentilu jsou o něco lehčí než všechny weby – asi o 3 % v desktopové i mobilní verzi. Neznamená to, že by se jednalo o velmi významný přínos, ale lze říci, že stránky jQuery přinejmenším nemají obrovské velikosti kódu JavaScript ani ve svých největších verzích.
To samé se ale nedá říci o jiných frameworkech.
Stejně jako v případě 10. percentilu se stránky na 90. percentilu na Angular a React liší od ostatních webů, ale liší se bohužel k horšímu.
Na 90. percentilu odesílají weby Angular o 141 % více dat do mobilních zařízení než všechny weby a o 159 % více do stolních zařízení. Weby React odesílají o 73 % více na stolní zařízení než všechny weby a o 58 % více na mobilní zařízení. Velikost kódu webů React na 90. percentilu je 2197.8 KB. To znamená, že tyto weby odesílají do mobilních zařízení o 322.9 KB více dat než jejich nejbližší konkurenti se sídlem na Vue. Rozdíl mezi desktopovými weby založenými na Angular a React a dalšími weby je ještě větší. Například desktopové weby React odesílají do zařízení o 554.7 KB více JS kódu než podobné weby Vue.
Doba potřebná ke zpracování kódu JavaScript v hlavním vláknu
Výše uvedená data jasně naznačují, že stránky využívající studované rámce a knihovny obsahují velké množství kódu JavaScript. Ale to je samozřejmě jen jedna část naší rovnice.
Poté, co kód JavaScript dorazí do prohlížeče, je třeba jej uvést do funkčního stavu. Zvláště mnoho problémů je způsobeno těmi akcemi, které je třeba provést s kódem v hlavním vláknu prohlížeče. Hlavní vlákno je zodpovědné za zpracování uživatelských akcí, výpočet stylů a vytváření a zobrazování rozvržení stránky. Pokud zahltíte hlavní vlákno úlohami JavaScriptu, nebude mít možnost včas dokončit další úkoly. To vede ke zpožděním a „brzdám“ v provozu stránek.
Databáze HTTP Archive obsahuje informace o tom, jak dlouho trvá zpracování kódu JavaScript v hlavním vláknu enginu V8. To znamená, že můžeme shromáždit tato data a zjistit, jak dlouho trvá hlavnímu vláknu zpracování JavaScriptu různých stránek.
Čas CPU (v milisekundách) související se zpracováním skriptů na mobilních zařízeních
Percentily
10
25
50
75
90
Všechny weby
356.4
959.7
2372.1
5367.3
10485.8
stránky jQuery
575.3
1147.4
2555.9
5511.0
10349.4
webové stránky Vue
1130.0
2087.9
4100.4
7676.1
12849.4
Angular webové stránky
1471.3
2380.1
4118.6
7450.8
13296.4
Reagovat weby
2700.1
5090.3
9287.6
14509.6
20813.3
CPU čas související se zpracováním skriptů na mobilních zařízeních
Čas procesoru (v milisekundách) související se zpracováním skriptů na stolních zařízeních
Percentily
10
25
50
75
90
Všechny weby
146.0
351.8
831.0
1739.8
3236.8
stránky jQuery
199.6
399.2
877.5
1779.9
3215.5
webové stránky Vue
350.4
650.8
1280.7
2388.5
4010.8
Angular webové stránky
482.2
777.9
1365.5
2400.6
4171.8
Reagovat weby
508.0
1045.6
2121.1
4235.1
7444.3
CPU čas související se zpracováním skriptů na stolních zařízeních
Zde můžete vidět něco velmi známého.
Pro začátek, weby s jQuery tráví podstatně méně zpracování JavaScriptu v hlavním vláknu než ostatní. Na 10. percentilu ve srovnání se všemi weby tráví weby jQuery na mobilních zařízeních o 61 % více času zpracováním JS kódu v hlavním vláknu. V případě desktopových stránek jQuery se doba zpracování prodlouží o 37 %. Na 90. percentilu jsou skóre webů jQuery velmi blízko souhrnnému skóre. Konkrétně weby jQuery na mobilních zařízeních tráví o 1.3 % méně času v hlavním vláknu než všechny weby a na stolních zařízeních stráví v hlavním vlákně o 0.7 % méně času.
Na druhé straně našeho hodnocení jsou frameworky, které se vyznačují největším zatížením hlavního vlákna. Toto je opět Angular a React. Jediný rozdíl mezi nimi je v tom, že ačkoli weby Angular odesílají do prohlížečů větší množství kódu než weby React, zpracování kódu webů Angular zabere méně času CPU. Daleko méně.
Na 10. percentilu tráví desktopové weby Angular o 230 % více času hlavního vlákna zpracováním kódu JS než všechny weby. U mobilních webů je toto číslo 313 %. Nejhorší výkon mají stránky React. Na stolních zařízeních stráví zpracováním kódu o 248 % více času než všechny weby a na mobilních zařízeních stráví zpracováním kódu o 658 % více času. 658 % není překlep. Na 10. percentilu stráví weby React 2.7 sekundy času hlavního vlákna zpracováním svého stávajícího kódu.
Čísla 90. percentilu vypadají alespoň o něco lépe ve srovnání s těmito obrovskými čísly. Angular projekty ve srovnání se všemi weby tráví o 29 % více času v hlavním vláknu na stolních zařízeních a o 27 % více času na mobilních zařízeních. V případě stránek React vypadají podobné ukazatele jako 130 %, respektive 98 %.
Procenta odchylky pro 90. percentil vypadají lépe než podobné hodnoty pro 10. percentil. Zde se ale sluší připomenout, že čísla udávající čas působí dost děsivě. Řekněme – 20.8 sekundy v hlavním vláknu mobilního zařízení pro web postavený na Reactu. (Věřím, že příběh o tom, co se během této doby skutečně děje, si zaslouží samostatný článek).
Je zde jedna potenciální komplikace (díky za to, že jsem na tuto vlastnost upozornil a pečlivě zkoumal data z tohoto úhlu pohledu). Faktem je, že mnoho webů používá několik front-endových nástrojů. Zejména jsem viděl, že mnoho webů používá jQuery vedle React nebo Vue, když tyto weby migrují z jQuery do jiných rámců nebo knihoven. V důsledku toho jsem se vrátil do databáze, tentokrát jsem vybral pouze ty odkazy, které odpovídaly webům, které používaly pouze React, jQuery, Angular nebo Vue, ale ne žádnou jejich kombinaci. Tady je to, co mám.
Čas procesoru (v milisekundách) související se zpracováním skriptů na mobilních zařízeních v situacích, kdy weby používají pouze jeden rámec nebo pouze jednu knihovnu
Percentily
10
25
50
75
90
Stránky, které používají pouze jQuery
542.9
1062.2
2297.4
4769.7
8718.2
Stránky, které používají pouze Vue
944.0
1716.3
3194.7
5959.6
9843.8
Stránky, které používají pouze Angular
1328.9
2151.9
3695.3
6629.3
11607.7
Webové stránky, které používají pouze React
2443.2
4620.5
10061.4
17074.3
24956.3
Čas procesoru související se zpracováním skriptů na mobilních zařízeních v situaci, kdy weby používají pouze jeden rámec nebo pouze jednu knihovnu
Za prvé, něco, co není překvapivé: když web používá pouze jeden rámec nebo jednu knihovnu, výkon takového webu se častěji zlepšuje než ne. Výkon každého nástroje vypadá lépe na 10. a 25. percentilu. To dává smysl. Web vytvořený pomocí jednoho rámce by měl být rychlejší než web vytvořený pomocí dvou nebo více rámců nebo knihoven.
Ve skutečnosti skóre pro každý front-end nástroj, který jsme zkoumali, vypadalo lépe ve všech případech, s jednou zvláštní výjimkou. Překvapilo mě, že na 50. percentilu a výše mají weby používající React horší výkon, když je React jedinou knihovnou, kterou používají. To byl mimochodem důvod, proč zde tyto údaje uvádím.
To je trochu zvláštní, ale přesto se pokusím hledat vysvětlení pro tuto podivnost.
Pokud projekt používá React i jQuery, pak je tento projekt s největší pravděpodobností někde v polovině procesu migrace z jQuery na React. Možná má kódovou základnu, ve které jsou tyto knihovny smíchány. Protože jsme již viděli, že weby jQuery tráví v hlavním vláknu méně času než weby React, může nám to říct, že implementace některých funkcí do jQuery pomáhá trochu zlepšit výkon webu.
Ale jak se projekt přesouvá z jQuery na React a stále více se spoléhá na React, situace se mění. Pokud je stránka vytvořena skutečně kvalitně a vývojáři stránek používají React opatrně, pak bude s takovou stránkou vše v pořádku. Pro průměrný web React však rozsáhlé používání Reactu znamená, že hlavní vlákno je vystaveno zvýšené zátěži.
Rozdíl mezi mobilními a stolními zařízeními
Dalším způsobem, jak jsem se podíval na data, bylo prozkoumat, jak velký je rozdíl mezi mobilními a stolními počítači. Pokud mluvíme o porovnávání objemů kódu JavaScript, pak takové srovnání neodhalí nic hrozného. Samozřejmě by bylo hezké vidět menší množství kódu ke stažení, ale v množství kódu pro mobily a počítače není velký rozdíl.
Ale pokud analyzujete čas potřebný ke zpracování kódu, objeví se velmi velká propast mezi mobilními a stolními zařízeními.
Prodloužení času (v procentech) související se zpracováním skriptů na mobilních zařízeních ve srovnání s desktopy
Percentily
10
25
50
75
90
Všechny weby
144.1
172.8
185.5
208.5
224.0
stránky jQuery
188.2
187.4
191.3
209.6
221.9
webové stránky Vue
222.5
220.8
220.2
221.4
220.4
Angular webové stránky
205.1
206.0
201.6
210.4
218.7
Reagovat weby
431.5
386.8
337.9
242.6
179.6
I když se dá očekávat určitý rozdíl v rychlosti zpracování kódu mezi telefonem a notebookem, tak velká čísla mi říkají, že moderní frameworky nejsou dostatečně zaměřeny na zařízení s nízkou spotřebou a touhu zacelit mezeru, která byla zjištěna. I na 10. percentilu tráví weby React o 431.5 % více času v hlavním vláknu pro mobilní zařízení než v hlavním vláknu pro počítače. Nejmenší mezeru má jQuery, ale i zde je odpovídající údaj 188.2 %. Když vývojáři webů dělají své projekty tak, že vyžadují více CPU na jejich zpracování (a to se stává a časem se to jen zhoršuje), majitelé zařízení s nízkou spotřebou za to musí zaplatit.
Výsledky
Dobré rámce by měly dát vývojářům dobrý základ pro vytváření webových projektů (z hlediska bezpečnosti, dostupnosti, výkonu) nebo by měly mít vestavěná omezení, která znesnadňují vytvoření něčeho, co tato omezení porušuje.
Zdá se, že to neplatí pro výkon webových projektů (a zřejmě jejich ).
Stojí za zmínku, že to, že weby React nebo Angular tráví více času CPU přípravou kódu než ostatní, nemusí nutně znamenat, že weby React jsou při běhu náročnější na CPU než weby Vue. Data, na která jsme se podívali, ve skutečnosti říkají velmi málo o provozním výkonu rámců a knihoven. Mluví více o vývojových přístupech, k nimž mohou tyto rámce, ať už vědomě nebo ne, tlačit programátory. Hovoříme o dokumentaci pro frameworky, jejich ekosystému a běžných vývojových technikách.
Za zmínku také stojí něco, co jsme zde neanalyzovali, konkrétně kolik času zařízení stráví prováděním kódu JavaScript při přechodu mezi stránkami webu. Argumentem ve prospěch SPA je to, že jakmile se do prohlížeče načte jednostránková aplikace, uživatel bude teoreticky moci přistupovat na stránky webu rychleji. Moje vlastní zkušenost mi říká, že to zdaleka není skutečnost. Nemáme ale k dispozici data, která by tento problém objasnila.
Jasné je, že pokud k vytvoření webu použijete framework nebo knihovnu, uděláte kompromis, pokud jde o počáteční načtení projektu a jeho přípravu k provozu. To platí i pro ty nejpozitivnější scénáře.
Ve vhodných situacích je možné dělat nějaké kompromisy, ale je důležité, aby vývojáři takové kompromisy dělali vědomě.
Máme ale také důvod k optimismu. Povzbuzuje mě, jak úzce spolupracují vývojáři Chromu s těmi, kteří stojí za některými front-endovými nástroji, které jsme probrali, abychom pomohli zlepšit výkon těchto nástrojů.
Jsem však pragmatický člověk. Nové architektury vytvářejí problémy s výkonem tak často, jak je řeší. A odstranění nedostatků vyžaduje čas. Stejně jako bychom to neměli očekávat vyřeší všechny problémy s výkonem, to byste od nových verzí našich oblíbených frameworků neměli očekávat.
Pokud chcete použít některý z front-endových nástrojů popsaných v tomto materiálu, znamená to, že budete muset vynaložit další úsilí, abyste zajistili, že mimochodem nepoškodíte výkon svého projektu. Zde je několik úvah, které je třeba zvážit, než začnete používat nový framework:
- Zkontrolujte se zdravým rozumem. Opravdu potřebujete použít vámi vybraný rámec? Čistý JavaScript dnes umí hodně.
- Existuje lehčí alternativa k rámci vašeho výběru (jako Preact, Svelte nebo něco jiného), která vám poskytne 90 % schopností tohoto rámce?
- Pokud už nějaký framework používáte, zamyslete se, zda neexistuje něco, co nabízí lepší, konzervativnější, standardní možnosti (například Nuxt.js místo Vue, Next.js místo React atd.).
- Jaká bude vaše Výkon JavaScriptu?
- Jak můžeš vývojový proces, aby bylo obtížnější zavést do projektu více kódu JavaScript, než je nezbytně nutné?
- Pokud používáte framework pro snadný vývoj, zvažte odeslat rámcový kód klientům. Možná můžete vyřešit všechny problémy na serveru?
Obvykle stojí za to se na tyto nápady podívat blíže, bez ohledu na to, co přesně zvolíte pro vývoj frontendu. Ale jsou zvláště důležité, když pracujete na projektu, který zpočátku postrádá výkon.
Vážení čtenáři! Co považujete za ideální rámec JavaScriptu?
Zdroj: www.habr.com