Цена на JavaScript рамки

Не постои побрз начин да се забави веб-локација (без намера за игра на зборови) отколку да се изврши куп JavaScript код на неа. Кога користите JavaScript, мора да платите за тоа во перформансите на проектот најмалку четири пати. Еве со што JavaScript кодот на страницата ги вчитува системите на корисниците:

• Поставување датотека преку мрежата.
• Парсирање и компајлирање на неотпакуваниот изворен код по преземањето.
• Извршување JavaScript код.
• Потрошувачка на меморија.

Излегува дека е оваа комбинација многу скапо.

И ние вклучуваме се повеќе и повеќе JS код во нашите проекти. Како што организациите се движат кон страници овозможени од рамки и библиотеки како React, Vue и други, ние ја правиме основната функционалност на сајтовите многу зависна од JavaScript.

Сум видел многу многу тешки веб-локации кои користат JavaScript рамки. Но, мојата визија за ова прашање е силно пристрасна. Факт е дека компаниите со кои работам доаѓаат кај мене токму затоа што имаат сложени проблеми со изведбата на веб-страниците. Како резултат на тоа, станав љубопитен да знам колку е распространет овој проблем и какви „казни“ плаќаме кога избираме една или друга рамка како основа за одредена локација.

Овој проект ми помогна да го сфатам ова. Архива HTTP.

Податоци

Проектот HTTP Archive следи вкупно 4308655 врски до обични десктоп страници и 5484239 врски до мобилни сајтови. Меѓу многуте индикатори поврзани со овие врски е списокот на технологии кои се наоѓаат на соодветните страници. Ова значи дека можеме да земеме примерок од илјадници локации кои користат различни рамки и библиотеки и да дознаеме колку код испраќаат до клиентите и колку оптоварување тој код им става на системите на корисниците.

Собрав податоци од март 2020 година, кои беа најновите податоци до кои имав пристап.

Решив да ги споредам збирните податоци од архивата на HTTP за сите страници со податоците за локациите за кои беше откриено дека користат React, Vue и Angular, иако размислував да користам и друг изворен материјал.

За да биде поинтересно, додадов и страници кои користат jQuery во изворниот сет на податоци. Оваа библиотека е сè уште многу популарна. Исто така, воведува пристап за развој на веб-локации што се разликува од моделот на апликација за една страница (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 

Аголни веб-страници
445.1 
675.6 
1066.4 
1761.5 
2893.2 

Реагирајте веб-локации
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 

Аголни веб-страници
468.8 
716.9 
1144.2 
1930.0 
3283.1 

Реагирајте веб-локации
308.6 
469.0 
841.9 
1472.2 
2197.8 

Количина на JavaScript код префрлен на десктоп уреди

Ако зборуваме само за големината на кодот JS што сајтовите го испраќаат до уредите, тогаш сè изгледа како што може да очекувате. Имено, доколку се користи една од рамките, тоа значи дека дури и во идеална ситуација, обемот на JavaScript кодот за страницата ќе се зголеми. Ова не е изненадувачки - не можете да направите JavaScript рамка основа на страницата и да очекувате дека количината на JS код за проектот ќе биде многу мала.

Она што е интересно за овие податоци е тоа што некои рамки и библиотеки може да се сметаат за подобри појдовни точки за проект од другите. Веб-страниците со jQuery изгледаат најдобро. Нивните десктоп страници содржат 15% повеќе JavaScript од сите страници, а нивните мобилни сајтови содржат 18% повеќе JavaScript. (Да мора да се признае, има извесна искривување во податоците овде. Факт е дека jQuery е присутен на многу сајтови, па природно е што таквите страници се поблиску поврзани со вкупниот број на сајтови од другите. Сепак, тоа не влијае на тоа како Изворните податоци се излезни за секоја рамка.)

Додека растот на кодот од 15-18% е значајна бројка, во споредба со другите рамки и библиотеки, данокот наметнат од jQuery е многу низок. Аголните страници во 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 содржи информации за тоа колку време е потребно за обработка на 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

Аголни веб-страници
1471.3
2380.1
4118.6
7450.8
13296.4

Реагирајте веб-локации
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

Аголни веб-страници
482.2
777.9
1365.5
2400.6
4171.8

Реагирајте веб-локации
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. (Верувам дека приказната за тоа што всушност се случува во ова време е достојна за посебна статија).

Има една потенцијална компликација овде (благодарам Ereереми за привлекување на моето внимание на оваа карактеристика и за внимателно испитување на податоците од оваа гледна точка). Факт е дека многу сајтови користат неколку предни алатки. Конкретно, видов дека многу сајтови користат 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

Аголни веб-страници
205.1
206.0
201.6
210.4
218.7

Реагирајте веб-локации
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 код во проект отколку што е апсолутно неопходно?
• Ако користите рамка за леснотија на развој, размислете дали ви треба испрати рамковен код до клиентите. Можеби можете да ги решите сите проблеми на серверот?

Вообичаено, овие идеи вреди да се разгледаат подетално, без оглед на тоа што точно ќе изберете да го развиете предниот дел. Но, тие се особено важни кога работите на проект кој за почеток нема перформанси.

Почитувани читатели! Што гледате како идеална JavaScript рамка?

Извор: www.habr.com