Цена ЈаваСцрипт оквира

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

  • Отпремање датотеке преко мреже.
  • Парсирање и компајлирање распакованог изворног кода након преузимања.
  • Извршавање ЈаваСцрипт кода.
  • Потрошња меморије.

Ова комбинација се испоставља веома скупо.

Цена ЈаваСцрипт оквира

И ми укључујемо све више и више ЈС кода у наше пројекте. Како се организације крећу ка сајтовима заснованим на оквирима и библиотекама као што су Реацт, Вуе и други, ми чинимо основну функционалност сајтова веома зависним од ЈаваСцрипт-а.

Видео сам много веома тешких веб локација које користе ЈаваСцрипт оквире. Али моја визија овог питања је снажно пристрасна. Чињеница је да компаније са којима радим долазе код мене управо зато што имају сложене проблеме са перформансама веб страница. Као резултат тога, постао сам радознао да сазнам колико је овај проблем распрострањен и које „казне“ плаћамо када изаберемо један или други оквир као основу за одређени сајт.

Овај пројекат ми је помогао да схватим ово. ХТТП архива.

Подаци

ХТТП Арцхиве пројекат прати укупно 4308655 веза ка редовним десктоп сајтовима и 5484239 веза ка мобилним сајтовима. Међу многим индикаторима повезаним са овим везама је и листа технологија које се налазе на одговарајућим сајтовима. То значи да можемо узорковати хиљаде сајтова који користе различите оквире и библиотеке и сазнати колико кода шаљу клијентима и колико оптерећење тај код ставља на системе корисника.

Прикупио сам податке из марта 2020., што су били најновији подаци којима сам имао приступ.

Одлучио сам да упоредим агрегиране податке ХТТП архиве за све локације са подацима за сајтове за које је утврђено да користе Реацт, Вуе и Ангулар, иако сам размишљао о коришћењу и другог изворног материјала.

Да би било занимљивије, такође сам додао сајтове који користе јКуери у изворни скуп података. Ова библиотека је и даље веома популарна. Такође уводи приступ развоју веб локација који се разликује од модела Сингле Паге Апплицатион (СПА) који нуде Реацт, Вуе и Ангулар.

Везе у ХТТП архиви које представљају сајтове за које је утврђено да користе технологије од интереса за нас

Оквир или библиотека
Везе ка мобилним сајтовима
Везе ка редовним сајтовима

јКуери
4615474
3714643

Реаговати
489827
241023

Вуе
85649
43691

Ангулар
19423
18088

Наде и снови

Пре него што пређемо на анализу података, желим да причам о томе чему бих желео да се надам.

Верујем да би у идеалном свету оквири превазишли задовољавање потреба програмера и пружили неке конкретне предности свакодневним корисницима наших сајтова. Продуктивност је само једна од тих предности. Приступачност и безбедност овде такође падају на памет. Али ово је само најважнија ствар.

Дакле, у идеалном свету, нека врста оквира би требало да олакша креирање веб странице високих перформанси. Ово треба учинити или због чињенице да оквир даје програмеру пристојну основу за изградњу пројекта, или због чињенице да намеће ограничења развоју, постављајући захтеве за њега који отежавају развој нечега то се испоставља споро.

Најбољи оквири треба да раде обоје: да обезбеде добру основу и наметну ограничења у раду која вам омогућавају да постигнете пристојан резултат.

Анализа средњих вредности података неће нам дати информације које су нам потребне. И, у ствари, овај приступ напушта нашу пажњу много важних ствари. Уместо тога, извео сам процентуалне резултате из података које сам имао. То су 10, 25, 50 (медијана), 75, 90 процената.

Посебно ме занимају 10. и 90. перцентили. 10. перцентил представља најбоље перформансе (или барем мање или више близу најбољег) за одређени оквир. Другим речима, то значи да само 10% сајтова који користе одређени оквир достиже овај ниво или виши ниво. 90. перцентил је, с друге стране, друга страна медаље – показује нам колико лоше ствари могу бити. 90. перцентил су сајтови на крају—оних последњих 10% сајтова који имају највећу количину ЈС кода или најдуже време потребно за обраду њиховог кода у главној нити.

Обим ЈаваСцрипт кода

За почетак, има смисла анализирати величину ЈаваСцрипт кода који преносе различите локације преко мреже.

Количина ЈаваСцрипт кода (КБ) пренета на мобилне уређаје

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

Сви сајтови
93.4 
196.6 
413.5 
746.8 
1201.6 

јКуери сајтови
110.3 
219.8 
430.4 
748.6 
1162.3 

Вуе веб странице
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 

Цена ЈаваСцрипт оквира
Количина ЈаваСцрипт кода послатог на мобилне уређаје

Количина ЈаваСцрипт кода (КБ) пренета на десктоп уређаје

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

Сви сајтови
105.5 
226.6 
450.4 
808.8 
1267.3 

јКуери сајтови
121.7 
242.2 
458.3 
803.4 
1235.3 

Вуе веб странице
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 

Цена ЈаваСцрипт оквира
Количина ЈаваСцрипт кода пренета на десктоп уређаје

Ако говоримо само о величини ЈС кода који сајтови шаљу уређајима, онда све изгледа онако како бисте очекивали. Наиме, ако се користи неки од оквира, то значи да ће се чак и у идеалној ситуацији повећати обим ЈаваСцрипт кода за сајт. Ово није изненађујуће – не можете направити ЈаваСцрипт оквир као основу сајта и очекивати да ће количина ЈС кода за пројекат бити веома мала.

Оно што је интересантно у вези са овим подацима је да се неки оквири и библиотеке могу сматрати бољом полазном тачком за пројекат од других. Веб локације са јКуери изгледају најбоље. Њихови веб сајтови за рачунаре садрже 15% више ЈаваСцрипт-а од свих сајтова, а њихови мобилни сајтови садрже 18% више ЈаваСцрипт-а. (Додуше, овде постоји извесна искривљеност података. Чињеница је да је јКуери присутан на многим сајтовима, па је природно да су такви сајтови ближе повезани са укупним бројем сајтова од других. Међутим, то не утиче на то како изворни подаци се излазе за сваки оквир.)

Док је раст кода од 15-18% значајан број, у поређењу са другим оквирима и библиотекама, порез који намеће јКуери је веома низак. Ангулар сајтови у 10. перцентилу шаљу 344% више података на десктоп уређаје од свих сајтова и 377% више на мобилне уређаје. Реацт сајтови су следећи по величини, шаљу 193% више кода на десктоп уређаје од свих сајтова и 270% више на мобилне уређаје.

Раније сам поменуо да иако коришћење оквира значи да ће одређена количина кода бити укључена у пројекат на самом почетку рада на њему, надам се да је оквир у стању да некако ограничи програмера. Конкретно, говоримо о ограничавању максималне количине кода.

Оно што је интересантно је да јКуери сајтови следе ову идеју. Иако су они, на нивоу 10. перцентила, нешто тежи од свих сајтова (за 15-18%), они су на нивоу 90. перцентила нешто лакши од свих сајтова – за око 3% иу десктоп иу мобилној верзији. Ово не значи да је ово веома значајна предност, али се може рећи да јКуери сајтови барем немају огромне величине ЈаваСцрипт кода чак ни у својим највећим верзијама.

Али то се не може рећи за друге оквире.

Баш као иу случају 10. перцентила, на 90. перцентилу сајтови на Ангулар и Реацт се разликују од других сајтова, али се разликују, нажалост, на горе.

На 90. перцентилу, Ангулар сајтови шаљу 141% више података на мобилне уређаје од свих сајтова и 159% више на десктоп уређаје. Реацт сајтови шаљу 73% више на десктоп уређаје од свих сајтова и 58% више на мобилне уређаје. Величина кода Реацт локација на 90. перцентилу је 2197.8 КБ. То значи да ове локације шаљу 322.9 КБ више података мобилним уређајима од својих најближих конкурената заснованих на Вуе-у. Јаз између десктоп сајтова заснованих на Ангулар и Реацт-у и других сајтова је још већи. На пример, Реацт десктоп сајтови шаљу 554.7 КБ више ЈС кода на уређаје од сличних Вуе локација.

Време потребно за обраду ЈаваСцрипт кода на главној нити

Горе наведени подаци јасно показују да сајтови који користе проучаване оквире и библиотеке садрже велике количине ЈаваСцрипт кода. Али, наравно, ово је само један део наше једначине.

Након што ЈаваСцрипт код стигне у претраживач, потребно га је довести у радно стање. Нарочито много проблема изазивају оне радње које се морају извршити са кодом у главној нити претраживача. Главна нит је одговорна за обраду радњи корисника, израчунавање стилова и изградњу и приказивање изгледа странице. Ако затрпате главну нит ЈаваСцрипт задацима, она неће имати прилику да обави друге задатке на време. То доводи до кашњења и „кочнице“ у раду страница.

База података ХТТП архиве садржи информације о томе колико дуго је потребно за обраду ЈаваСцрипт кода на главној нити В8 машине. То значи да можемо прикупити ове податке и сазнати колико времена је главној нити потребно да обради ЈаваСцрипт различитих сајтова.

ЦПУ време (у милисекундама) у вези са обрадом скрипте на мобилним уређајима

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

Сви сајтови
356.4
959.7
2372.1
5367.3
10485.8

јКуери сајтови
575.3
1147.4
2555.9
5511.0
10349.4

Вуе веб странице
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

јКуери сајтови
199.6
399.2
877.5
1779.9
3215.5

Вуе веб странице
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

Цена ЈаваСцрипт оквира
ЦПУ време које се односи на обраду скрипте на десктоп уређајима

Овде можете видети нешто веома познато.

За почетак, сајтови са јКуери троше знатно мање обраде ЈаваСцрипт-а на главној нити од других. На 10. перцентилу, у поређењу са свим сајтовима, јКуери сајтови на мобилним уређајима троше 61% више времена на обраду ЈС кода на главној нити. У случају десктоп јКуери сајтова, време обраде се повећава за 37%. На 90. перцентилу, резултати јКуери сајтова су веома близу збирним оценама. Конкретно, јКуери сајтови на мобилним уређајима проводе 1.3% мање времена у главној нити од свих сајтова, а на десктоп уређајима проводе 0.7% мање времена у главној нити.

На другој страни нашег рејтинга су оквири који се одликују највећим оптерећењем главне нити. Ово је, опет, Ангулар и Реацт. Једина разлика између њих је у томе што, иако Ангулар локације шаљу веће количине кода у прегледаче од Реацт сајтова, потребно је мање процесорског времена за обраду кода Ангулар сајтова. Далеко мање.

На 10. перцентилу, Ангулар десктоп сајтови троше 230% више времена главне нити на обраду ЈС кода од свих сајтова. За мобилне сајтове ова цифра је 313%. Реацт сајтови имају најгоре перформансе. На десктоп уређајима троше 248% више времена на обраду кода од свих сајтова, а на мобилним уређајима троше 658% више времена на обраду кода. 658% није штампарска грешка. На 10. перцентилу, Реацт сајтови троше 2.7 секунди времена главне нити на обраду свог постојећег кода.

Бројеви од 90. перцентила изгледају барем мало боље у поређењу са овим огромним бројевима. Ангулар пројекти, у поређењу са свим сајтовима, проводе 29% више времена у главној нити на десктоп уређајима и 27% више времена на мобилним уређајима. У случају Реацт сајтова, слични индикатори изгледају као 130% и 98%, респективно.

Проценти одступања за 90. перцентил изгледају боље од сличних вредности за 10. перцентил. Али овде вреди запамтити да бројеви који означавају време изгледају прилично застрашујуће. Рецимо - 20.8 секунди у главној нити мобилног уређаја за сајт изграђен на Реацт-у. (Верујем да је прича о томе шта се заправо дешава током овог времена вредна посебног чланка).

Овде постоји једна потенцијална компликација (хвала Јеремиах за скретање пажње на ову особину и за пажљиво испитивање података са ове тачке гледишта). Чињеница је да многе локације користе неколико фронт-енд алата. Конкретно, видео сам много сајтова који користе јКуери заједно са Реацт-ом или Вуе-ом јер се ове локације мигрирају са јКуери-ја на друге оквире или библиотеке. Као резултат тога, вратио сам се у базу података, овог пута одабравши само оне везе које су одговарале сајтовима који су користили само Реацт, јКуери, Ангулар или Вуе, али не било коју њихову комбинацију. Ево шта сам добио.

Време процесора (у милисекундама) које се односи на обраду скрипте на мобилним уређајима у ситуацијама када сајтови користе само један оквир или само једну библиотеку

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

Сајтови који користе само јКуери
542.9
1062.2
2297.4
4769.7
8718.2

Сајтови који користе само Вуе
944.0
1716.3
3194.7
5959.6
9843.8

Сајтови који користе само Ангулар
1328.9
2151.9
3695.3
6629.3
11607.7

Веб локације које користе само Реацт
2443.2
4620.5
10061.4
17074.3
24956.3

Цена ЈаваСцрипт оквира
Процесорско време које се односи на обраду скрипти на мобилним уређајима у ситуацији када сајтови користе само један оквир, или само једну библиотеку

Прво, нешто што није изненађујуће: када сајт користи само један оквир или једну библиотеку, перформансе таквог сајта се чешће побољшавају него не. Перформансе за сваки инструмент изгледају боље на 10. и 25. перцентилу. Има смисла. Сајт који је направљен коришћењем једног оквира треба да буде бржи од сајта који је направљен коришћењем два или више оквира или библиотека.

У ствари, резултати за сваки фронт-енд алат који смо испитали изгледали су боље у свим случајевима, са једним чудним изузетком. Оно што ме је изненадило је да на 50. перцентилу и више, сајтови који користе Реацт имају лошије резултате када је Реацт једина библиотека коју користе. То је, иначе, био разлог да овде износим ове податке.

Ово је мало чудно, али ћу ипак покушати да потражим објашњење за ову необичност.

Ако пројекат користи и Реацт и јКуери, онда је тај пројекат највероватније негде на пола пута у процесу миграције са јКуери на Реацт. Можда он има кодну базу у којој су ове библиотеке помешане. Пошто смо већ видели да јКуери сајтови проводе мање времена на главној нити од Реацт сајтова, то нам може рећи да примена неке функционалности у јКуери-ју помаже да се мало побољша перформансе сајта.

Али како пројекат прелази са јКуери на Реацт и све више се ослања на Реацт, ситуација се мења. Ако је сајт направљен заиста високог квалитета, а програмери сајта пажљиво користе Реацт, онда ће са таквим сајтом све бити у реду. Али за просечну Реацт локацију, екстензивна употреба Реацт-а значи да је главна нит подложна повећаном оптерећењу.

Јаз између мобилних и десктоп уређаја

Други начин на који сам погледао податке био је да истражим колики је јаз између мобилних и десктоп искустава. Ако говоримо о поређењу обима ЈаваСцрипт кода, онда такво поређење не открива ништа страшно. Наравно, било би лепо видети мање количине кода за преузимање, али нема велике разлике у количини кода за мобилни и десктоп.

Али ако анализирате време потребно за обраду кода, постаје приметан веома велики јаз између мобилних и десктоп уређаја.

Повећање времена (у процентима) везано за обраду скрипте на мобилним уређајима у поређењу са десктоп уређајима

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

Сви сајтови
144.1
172.8
185.5
208.5
224.0

јКуери сајтови
188.2
187.4
191.3
209.6
221.9

Вуе веб странице
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. перцентилу, Реацт локације проводе 431.5% више времена на главној нити за мобилне уређаје него на главној нити за десктоп рачунаре. јКуери има најмањи јаз, али чак и овде одговарајућа цифра износи 188.2%. Када програмери веб локација направе своје пројекте на такав начин да им је потребно више процесорског времена за њихову обраду (а то се дешава, а временом се само погоршава), власници уређаја мале снаге морају то да плате.

Резултати

Добри оквири треба да дају програмерима добру основу за изградњу веб пројеката (у смислу безбедности, приступачности, перформанси) или би требало да имају уграђена ограничења која отежавају креирање нечега што крши та ограничења.

Чини се да се ово не односи на перформансе веб пројеката (и очигледно на њихове приступачност).

Вреди напоменути да само зато што Реацт или Ангулар локације троше више ЦПУ времена на припрему кода од других, не значи нужно да су Реацт локације више ЦПУ-интензивне од Вуе локација када су покренуте. У ствари, подаци које смо погледали говоре врло мало о оперативним перформансама оквира и библиотека. Они више говоре о развојним приступима према којима, свјесно или не, ови оквири могу гурнути програмере. Говоримо о документацији за оквире, њиховом екосистему и уобичајеним техникама развоја.

Такође је вредно поменути нешто што овде нисмо анализирали, наиме, колико времена уређај троши на извршавање ЈаваСцрипт кода при преласку између страница сајта. Аргумент у корист СПА је да када се апликација за једну страницу учита у претраживач, корисник ће, у теорији, моћи брже да приступи страницама сајта. Моје искуство ми говори да је то далеко од чињенице. Али немамо податке који би разјаснили ово питање.

Оно што је јасно је да ако користите оквир или библиотеку за креирање веб странице, правите компромис у смислу почетног учитавања пројекта и припреме за рад. Ово се односи чак и на најпозитивније сценарије.

Могуће је направити неке компромисе у одговарајућим ситуацијама, али је важно да програмери свесно праве такве компромисе.

Али имамо и разлога за оптимизам. Охрабрује ме колико блиско програмери Цхроме-а сарађују са онима који стоје иза неких од фронт-енд алата које смо покрили да би помогли у побољшању перформанси тих алата.

Међутим, ја сам прагматична особа. Нове архитектуре стварају проблеме перформанси онолико често колико их решавају. И потребно је време да се отклоне недостаци. Као што то не треба очекивати нове мрежне технологије ће решити све проблеме са перформансама, то не бисте требали очекивати од нових верзија наших омиљених оквира.

Ако желите да користите један од фронт-енд алата о којима се говори у овом материјалу, то значи да ћете морати да уложите додатне напоре како бисте осигурали да, узгред, не оштетите перформансе вашег пројекта. Ево неколико разматрања које треба узети у обзир пре него што почнете да користите нови оквир:

  • Проверите себе здравим разумом. Да ли заиста треба да користите оквир који сте изабрали? Чисти ЈаваСцрипт данас може учинити много.
  • Постоји ли лакша алтернатива оквиру по вашем избору (као што је Преацт, Свелте или нешто друго) која вам може дати 90% могућности тог оквира?
  • Ако већ користите оквир, размислите о томе да ли постоји нешто што нуди боље, конзервативније, стандардне опције (на пример, Нукт.јс уместо Вуе, Нект.јс уместо Реацт, итд.).
  • Шта ће твоје буџет Перформансе ЈаваСцрипта?
  • Како можеш да ограничите развојни процес да би се отежало увођење више ЈаваСцрипт кода у пројекат него што је апсолутно неопходно?
  • Ако користите оквир за лакши развој, размислите да ли ти треба послати код за оквир клијентима. Можда можете да решите све проблеме на серверу?

Обично, ове идеје вреди пажљивије погледати, без обзира на то шта тачно одаберете да развијете предњи крај. Али они су посебно важни када радите на пројекту који за почетак нема перформансе.

Драги читаоци! Шта видите као идеалан ЈаваСцрипт оквир?

Цена ЈаваСцрипт оквира

Извор: ввв.хабр.цом

Додај коментар