Цена на JavaScript frameworks

Няма по-бърз начин да забавите уебсайт (игра на думи), отколкото да използвате куп JavaScript код върху него. Когато използвате JavaScript, трябва да платите за това с изпълнението на проекти не по-малко от четири пъти. Ето как JavaScript кодът на сайта зарежда системите на потребителите:

• Изтегляне на файл по мрежата.
• Разбор и компилиране на разопакован изходен код след изтегляне.
• Изпълнение на JavaScript код.
• Консумация на памет.

Тази комбинация се оказва много скъп.

И ние включваме все повече и повече JS код в нашите проекти. Тъй като организациите преминават към сайтове, захранвани от рамки и библиотеки като React, Vue и други, ние правим основната функционалност на сайтовете много силно зависима от JavaScript.

Виждал съм много много тежки сайтове, използващи JavaScript рамки. Но моята визия по въпроса е много пристрастна. Факт е, че компаниите, с които работя, се обръщат към мен именно защото се сблъскват с комплексни проблеми в областта на работата на сайта. В резултат на това ми стана любопитно колко често срещан е този проблем и какви "неустойки" плащаме, когато избираме една или друга рамка за основа на даден сайт.

Проектът ми помогна да разбера това. HTTP архив.

Данни

Проектът HTTP Archive проследява общо 4308655 5484239 XNUMX връзки към обикновени десктоп сайтове и XNUMX XNUMX XNUMX връзки към мобилни сайтове. Сред многото показатели, свързани с тези връзки, е списък с технологии, открити на съответните сайтове. Това означава, че можем да вземем проби от хиляди сайтове, които използват различни рамки и библиотеки, и да научим колко код изпращат на клиентите и колко натоварване създава този код в системите на потребителите.

Събрах данни от март 2020 г., които бяха най-новите данни, до които имах достъп.

Реших да сравня обобщените HTTP архивни данни във всички сайтове с данни от сайтове, намерени с помощта на React, Vue и Angular, въпреки че обмислях да използвам и друг изходен материал.

За да го направя по-интересно, добавих и сайтове, които използват jQuery, към изходния набор от данни. Тази библиотека все още е много популярна. Той също така въвежда различен подход към уеб разработката от модела Single Page Application (SPA), предлаган от React, Vue и Angular.

Връзки в HTTP архива, представящи сайтове, за които е установено, че използват представляващи интерес технологии

Рамка или библиотека
Връзки към мобилни сайтове
Връзки към редовни сайтове

Jquery
4615474
3714643

Реагират
489827
241023

Vue
85649
43691

ъглов
19423
18088

Надежди и мечти

Преди да преминем към анализ на данни, искам да говоря за това, на което бих искал да се надявам.

Вярвам, че в един идеален свят рамките трябва да надхвърлят нуждите на разработчиците и да предоставят някаква конкретна полза на средния потребител, който работи с нашите сайтове. Производителността е само едно от тези предимства. Тук влизат в действие достъпността и сигурността. Но това е само най-важното.

Така че в един идеален свят някаква рамка трябва да улесни създаването на сайт с висока производителност. Това трябва да се направи или поради факта, че рамката дава на разработчика прилична основа, върху която да изгради проект, или поради факта, че налага ограничения върху развитието, поставя изисквания към него, които усложняват развитието на нещо, което се превръща да бъде бавен.

Най-добрите рамки трябва да правят и двете: да дават добра основа и да налагат ограничения върху работата, което ви позволява да постигнете приличен резултат.

Анализирането на средните стойности на данните няма да ни даде информацията, от която се нуждаем. И всъщност този подход остава извън нашето внимание много важно. Вместо това извлякох проценти от данните, които имах. Това са 10, 25, 50 (медиана), 75, 90 персентили.

Особено се интересувам от 10-ия и 90-ия процентил. 10-ият процентил представлява най-доброто представяне (или поне повече или по-малко близо до най-доброто) за определена рамка. С други думи, това означава, че само 10% от сайтовете, използващи определена рамка, достигат това ниво или по-високо. 90-ият процентил, от друга страна, е обратната страна на монетата – той ни показва колко лоши могат да станат нещата. 90-ият процентил са сайтовете, които изостават – тези долни 10% от сайтовете, които имат най-много JS код или най-дългото време за обработка на техния код в основната нишка.

Обеми JavaScript код

Като начало има смисъл да анализираме размера на JavaScript кода, предаван от различни сайтове по мрежата.

Количеството JavaScript код (Kb), прехвърлено на мобилни устройства

Процентили
10
25
50
75
90

Всички сайты
93.4 
196.6 
413.5 
746.8 
1201.6 

jQuery сайтове
110.3 
219.8 
430.4 
748.6 
1162.3 

Vue сайтове
244.7 
409.3 
692.1 
1065.5 
1570.7 

Angular сайтове
445.1 
675.6 
1066.4 
1761.5 
2893.2 

React сайтове
345.8 
441.6 
690.3 
1238.5 
1893.6 

Количество JavaScript код, изпратен до мобилни устройства

Количество JavaScript код (Kb), прехвърлено на настолни устройства

Процентили
10
25
50
75
90

Всички сайты
105.5 
226.6 
450.4 
808.8 
1267.3 

jQuery сайтове
121.7 
242.2 
458.3 
803.4 
1235.3 

Vue сайтове
248.0 
420.1 
718.0 
1122.5 
1643.1 

Angular сайтове
468.8 
716.9 
1144.2 
1930.0 
3283.1 

React сайтове
308.6 
469.0 
841.9 
1472.2 
2197.8 

Количество JavaScript код, изпратен до настолни устройства

Ако говорим само за размера на JS кода, който сайтовете изпращат на устройствата, тогава всичко изглежда така, както бихте очаквали. А именно, ако се използва една от рамките, това означава, че дори в идеална ситуация обемът на JavaScript кода на сайта ще се увеличи. Това не е изненадващо - не можете да направите JavaScript рамка в основата на сайт и да очаквате, че обемът на JS кода на проекта ще бъде много малък.

Забележителното в тези данни е, че някои рамки и библиотеки могат да се считат за по-добра отправна точка за проект от други. Сайтовете с jQuery изглеждат най-добре. На настолни версии на сайтове те съдържат 15% повече JavaScript от всички сайтове, а на мобилни устройства съдържат 18% повече. (Разбира се, тук има известна повреда на данните. Факт е, че jQuery присъства на много сайтове, така че е съвсем естествено такива сайтове да са по-тясно свързани от други с общия брой сайтове. Това обаче не влияе на това колко необработени данните се извеждат за всяка рамка.)

Докато 15-18% увеличение на обема на кода е забележителна цифра, сравнявайки това с други рамки и библиотеки, може да се заключи, че „данъкът“, наложен от jQuery, е много нисък. Angular сайтовете в 10-ия процентил изпращат 344% повече данни към настолен компютър от всички сайтове и 377% повече към мобилни устройства. Сайтовете на React са следващите най-тежки, като изпращат 193% повече код към настолен компютър от всички сайтове и 270% повече към мобилни устройства.

По-рано споменах, че въпреки че използването на рамка означава, че определено количество код ще бъде включено в проекта, в самото начало на работата по него се надявам, че рамката е в състояние по някакъв начин да ограничи разработчика. По-специално, говорим за ограничаване на максималното количество код.

Интересното е, че jQuery сайтовете следват тази идея. Въпреки че са малко по-тежки от всички сайтове на 10-ия персентил (с 15-18%), те са малко по-леки на 90-ия персентил с около 3% както на настолни компютри, така и на мобилни устройства. Това не означава, че това е много значителна полза, но може да се каже, че jQuery сайтовете поне нямат огромни размери на JavaScript код, дори в най-големите си версии.

Но същото не може да се каже за други рамки.

Точно както в случая с 10-ия процентил, при 90-ия процентил сайтовете на Angular и React се различават от другите сайтове, но за съжаление се различават в по-лоша посока.

На 90-ия процентил сайтовете на Angular изпращат 141% повече данни към мобилни устройства от всички сайтове и 159% повече към настолни компютри. Сайтовете на React изпращат 73% повече към настолни компютри от всички сайтове и 58% повече към мобилни устройства. Размерът на кода на сайтовете на React на 90-ия процентил е 2197.8 KB. Това означава, че такива сайтове изпращат 322.9 KB повече данни към мобилни устройства от най-близките им конкуренти, базирани на Vue. Разликата между сайтовете за настолни компютри, базирани на Angular и React, и други сайтове е още по-голяма. Например сайтовете React за настолни компютри изпращат 554.7 KB повече JS код към устройствата, отколкото еквивалентните сайтове Vue.

Време, необходимо за обработка на JavaScript код в основната нишка

Горните данни ясно показват, че сайтовете, използващи изследваните рамки и библиотеки, съдържат големи количества JavaScript код. Но разбира се, това е само една част от нашето уравнение.

След като кодът на JavaScript пристигне в браузъра, той трябва да бъде приведен в работещо състояние. Особено много проблеми се причиняват от онези действия, които трябва да се извършват с кода в основната нишка на браузъра. Основната нишка е отговорна за обработката на потребителските действия, за изчисляването на стилове, за изграждането и показването на оформлението на страницата. Ако затрупате основната нишка с JavaScript задачи, тя няма да има възможност да изпълни останалите задачи навреме. Това води до забавяне и "спиране" в работата на страниците.

Базата данни HTTP Archive съдържа информация за това колко време отнема обработката на JavaScript код в основната нишка на двигателя V8. Това означава, че можем да събираме тези данни и да разберем колко време отнема основната нишка за обработка на JavaScript на различни сайтове.

Процесорно време (в милисекунди), свързано с обработката на скриптове на мобилни устройства

Процентили
10
25
50
75
90

Всички сайты
356.4
959.7
2372.1
5367.3
10485.8

jQuery сайтове
575.3
1147.4
2555.9
5511.0
10349.4

Vue сайтове
1130.0
2087.9
4100.4
7676.1
12849.4

Angular сайтове
1471.3
2380.1
4118.6
7450.8
13296.4

React сайтове
2700.1
5090.3
9287.6
14509.6
20813.3

Процесорно време, свързано с обработката на скриптове на мобилни устройства

Процесорно време (в милисекунди), свързано с обработката на скриптове на настолни устройства

Процентили
10
25
50
75
90

Всички сайты
146.0
351.8
831.0
1739.8
3236.8

jQuery сайтове
199.6
399.2
877.5
1779.9
3215.5

Vue сайтове
350.4
650.8
1280.7
2388.5
4010.8

Angular сайтове
482.2
777.9
1365.5
2400.6
4171.8

React сайтове
508.0
1045.6
2121.1
4235.1
7444.3

Процесорно време, свързано с обработката на скриптове на настолни устройства

Тук можете да видите нещо много познато.

Като за начало, сайтовете с jQuery харчат значително по-малко за обработка на JavaScript в основната нишка, отколкото други сайтове. На 10-ия процентил, в сравнение с всички сайтове, jQuery сайтовете на мобилни устройства прекарват 61% повече време за обработка на JS код в основната нишка. В случай на настолни jQuery сайтове, времето за обработка се увеличава с 37%. На 90-ия процентил сайтовете на jQuery имат резултат много близо до общите резултати. По-конкретно, jQuery сайтовете на мобилни устройства прекарват 1.3% по-малко време в основната нишка от всички сайтове и 0.7% по-малко време на настолни устройства.

От другата страна на нашия рейтинг са рамките, които се характеризират с най-голямо натоварване на основната нишка. Това отново е Angular и React. Единствената разлика между двете е, че докато Angular сайтовете изпращат повече код към браузърите, отколкото React сайтовете, Angular сайтовете отнемат по-малко процесорно време за обработка на кода. Много по.

На 10-ия процентил сайтовете Angular за настолни компютри прекарват 230% повече време в основната нишка, обработвайки JS код, отколкото всички сайтове. За мобилните сайтове тази цифра е 313%. Сайтовете на React се представят най-зле. На настолен компютър те прекарват 248% повече време за обработка на код от всички сайтове и 658% повече на мобилни устройства. 658% не е печатна грешка. На 10-ия процентил сайтовете на React прекарват 2.7 секунди от времето на основната нишка за обработка на своя код.

90-ият процентил, в сравнение с тези огромни числа, изглежда поне малко по-добре. В сравнение с всички сайтове, Angular проектите прекарват 29% повече време на настолни устройства в основната нишка и 27% повече време на мобилни устройства. В случая на сайтовете на React същите цифри изглеждат съответно 130% и 98%.

Процентните отклонения за 90-ия персентил изглеждат по-добре от подобни стойности за 10-ия персентил. Но тук си струва да си припомним, че числата, показващи времето, изглеждат доста страшни. Да кажем 20.8 секунди в основната мобилна нишка за уебсайт, създаден с React. (Мисля, че историята за това какво всъщност се случва през това време е достойна за отделна статия).

Тук има едно потенциално усложнение (благодаря Еремия че насочихте вниманието ми към тази характеристика и че внимателно разгледахте данните от тази гледна точка). Факт е, че много сайтове използват няколко предни инструменти. По-конкретно, виждал съм много сайтове, използващи jQuery заедно с React или Vue, тъй като тези сайтове мигрират от jQuery към други рамки или библиотеки. В резултат на това ударих отново базата данни, като този път избрах само онези връзки, които съответстват на сайтове, които използват само React, jQuery, Angular или Vue, но не и комбинация от тях. Ето какво имам.

Процесорно време (в милисекунди), свързано с обработката на скриптове на мобилни устройства в ситуация, в която сайтовете използват само една рамка или само една библиотека

Процентили
10
25
50
75
90

Сайтове, които използват само jQuery
542.9
1062.2
2297.4
4769.7
8718.2

Сайтове, които използват само Vue
944.0
1716.3
3194.7
5959.6
9843.8

Сайтове, които използват само Angular
1328.9
2151.9
3695.3
6629.3
11607.7

Сайтове, които използват само React
2443.2
4620.5
10061.4
17074.3
24956.3

Процесорно време, свързано с обработка на скриптове на мобилни устройства в ситуация, в която сайтовете използват само една рамка или само една библиотека

Първо, нещо, което не е изненадващо: когато един сайт използва само една рамка или една библиотека, производителността на такъв сайт се подобрява по-често, отколкото не. Всеки инструмент се представя по-добре при 10-ия и 25-ия процентил. Има смисъл. Сайт, който е направен с помощта на една рамка, трябва да работи по-добре от сайт, който е направен с помощта на две или повече рамки или библиотеки.

Всъщност производителността за всеки изследван интерфейсен инструмент изглежда по-добра във всички случаи, с изключение на едно любопитно изключение. Това, което ме изненада, беше, че при 50-ия процентил и нагоре сайтовете, използващи React, се представят по-зле, когато React е единствената библиотека, която използват. Това между другото беше причината да представя тези данни тук.

Това е малко странно, но все пак ще се опитам да потърся обяснение за тази странност.

Ако даден проект използва React и jQuery, тогава този проект вероятно е някъде по средата на прехода от jQuery към React. Може би има кодова база, в която тези библиотеки са смесени. Тъй като вече видяхме, че сайтовете на jQuery прекарват по-малко време в основната нишка от сайтовете на React, това може да ни каже, че внедряването на някои функции в jQuery помага на сайта да работи малко по-добре.

Но тъй като проектът преминава от jQuery към React и разчита повече на React, нещата се променят. Ако сайтът е наистина висококачествен и разработчиците на сайта използват React внимателно, тогава всичко ще бъде наред с такъв сайт. Но за средния сайт на React, широкото използване на React означава, че основната нишка е под голямо натоварване.

Пропастта между мобилни и настолни устройства

Друга гледна точка, от която разгледах изследваните данни, беше да проуча колко голяма е разликата между работата със сайтове на мобилни и настолни устройства. Ако говорим за сравняване на обемите на JavaScript код, тогава такова сравнение не разкрива нищо ужасно. Разбира се, би било хубаво да видите по-малки количества код за изтегляне, но няма голяма разлика в количеството на кода за мобилни устройства и настолен компютър.

Но ако анализираме времето, необходимо за обработка на кода, се забелязва много голяма разлика между мобилните и настолните устройства.

Увеличаване на времето (процент), свързано с обработката на скриптове на мобилни устройства в сравнение с настолни компютри

Процентили
10
25
50
75
90

Всички сайты
144.1
172.8
185.5
208.5
224.0

jQuery сайтове
188.2
187.4
191.3
209.6
221.9

Vue сайтове
222.5
220.8
220.2
221.4
220.4

Angular сайтове
205.1
206.0
201.6
210.4
218.7

React сайтове
431.5
386.8
337.9
242.6
179.6

Въпреки че може да се очаква известна разлика в скоростта на обработка на код между телефон и лаптоп, толкова големи числа ми казват, че съвременните рамки не са достатъчно насочени към устройства с ниска мощност и че се стремят да запълнят празнината, която са открили. Дори при 10-ия процентил сайтовете на React прекарват 431.5% повече време в основната нишка за мобилни устройства, отколкото в основната нишка за настолни компютри. jQuery има най-малка разлика, но дори и тук съответната цифра е 188.2%. Когато разработчиците на уебсайтове правят проектите си по такъв начин, че обработката им изисква повече процесорно време (и това се случва и само се влошава с времето), собствениците на устройства с ниска мощност трябва да плащат за това.

Резултати от

Добрите рамки трябва да дават на разработчиците добра основа за изграждане на уеб проекти (по отношение на сигурност, достъпност, производителност) или трябва да имат вградени ограничения, които затрудняват изграждането на нещо, което нарушава тези ограничения.

Това изглежда не се отнася за изпълнението на уеб проекти (и вероятно не и за техните достъпност).

Струва си да се отбележи, че това, че сайтовете на React или Angular прекарват повече процесорно време за подготовка на код, отколкото други, не означава непременно, че сайтовете на React са по-интензивни на процесора от сайтовете на Vue, докато работят. Всъщност данните, които прегледахме, говорят много малко за оперативната ефективност на рамките и библиотеките. Те говорят повече за подходите за разработка, които, съзнателно или не, тези рамки могат да прокарат програмистите. Говорим за документация за рамки, за тяхната екосистема, за общи техники за разработка.

Струва си да споменем и нещо, което не сме анализирали тук, а именно колко време отделя устройството за изпълнение на JavaScript код при навигиране между страниците на сайта. Аргументът в полза на SPA е, че след като едностраничното приложение бъде заредено в браузъра, потребителят теоретично ще може да отваря страниците на сайта по-бързо. Моят собствен опит ми казва, че това далеч не е факт. Но ние нямаме данни, за да изясним този въпрос.

Ясно е, че ако използвате рамка или библиотека за създаване на уебсайт, вие правите компромис по отношение на първоначалното зареждане на проекта и подготовката му за работа. Това важи дори за най-положителните сценарии.

Напълно възможно е да се направят някои компромиси в подходящи ситуации, но е важно разработчиците да правят такива компромиси съзнателно.

Но имаме и основания за оптимизъм. Вълнувам се да видя колко тясно работят разработчиците на Chrome с разработчиците на някои от предните инструменти, които прегледахме в опит да помогнем за подобряване на ефективността на тези инструменти.

Аз обаче съм прагматичен човек. Новите архитектури създават проблеми с производителността толкова често, колкото ги решават. И отнема време за коригиране на грешки. Точно както не трябва да очакваме нови мрежови технологии ще реши всички проблеми с производителността, не трябва да очаквате това от новите версии на любимите ни рамки.

Ако искате да използвате един от инструментите за преден край, обсъдени в тази статия, това означава, че трябва да положите допълнителни усилия, за да не навредите междувременно на ефективността на вашия проект. Ето някои съображения, които трябва да имате предвид, преди да започнете нова рамка:

• Тествайте се със здравия разум. Наистина ли трябва да използвате избраната рамка? Чистият JavaScript днес е способен на много.
• Има ли по-лека алтернатива на избраната рамка (като Preact, Svelte или нещо друго), която може да ви даде 90% от възможностите на тази рамка?
• Ако вече използвате рамка, помислете дали има нещо, което предлага по-добри, по-консервативни стандартни опции (напр. Nuxt.js вместо Vue, Next.js вместо React и т.н.).
• Какво ще си бюджета производителност на JavaScript?
• Как можеш да се ограничи процес на разработка, за да затрудни инжектирането на повече JavaScript код в проект, отколкото е абсолютно необходимо?
• Ако използвате рамка за улесняване на разработката, помислете Имате ли нужда от изпращайте рамков код на клиентите. Може би можете да разрешите всички проблеми на сървъра?

Обикновено тези идеи си струва да се разгледат, независимо какво точно сте избрали за front-end разработка. Но те са особено важни, когато работите върху проект, който няма производителност от самото начало.

Уважаеми читатели! Как виждате идеалната JavaScript рамка?

Източник: www.habr.com