JavaScript շրջանակների գինը

Կայքը դանդաղեցնելու ավելի արագ միջոց չկա (բառախաղը նախատեսված է), քան դրա վրա JavaScript կոդ օգտագործելը: JavaScript-ն օգտագործելիս դրա համար պետք է վճարել նախագծերի կատարմամբ ոչ պակաս, քան չորս անգամ։ Ահա, թե ինչպես է կայքի JavaScript կոդը բեռնում օգտատերերի համակարգերը.

• Ֆայլի ներբեռնում ցանցից:
• Ներբեռնումից հետո չփաթեթավորված ելակետային կոդի վերլուծություն և կազմում:
• JavaScript կոդի կատարում:
• Հիշողության սպառում.

Այս համադրությունը պարզվում է շատ թանկ.

Եվ մենք ավելի ու ավելի շատ JS կոդ ենք ներառում մեր նախագծերում: Քանի որ կազմակերպությունները շարժվում են դեպի կայքեր, որոնք սնուցվում են շրջանակներով և գրադարաններով, ինչպիսիք են React, Vue և այլն, մենք կայքերի հիմնական գործառույթները մեծապես կախված ենք JavaScript-ից:

Ես տեսել եմ շատ ծանր կայքեր, որոնք օգտագործում են JavaScript շրջանակներ: Բայց հարցի իմ տեսլականը շատ կողմնակալ է։ Փաստն այն է, որ այն ընկերությունները, որոնց հետ ես աշխատում եմ, դիմում են ինձ հենց այն պատճառով, որ բախվում են կայքի աշխատանքի ոլորտում բարդ խնդիրների։ Արդյունքում, ինձ հետաքրքրեց, թե որքանով է տարածված այս խնդիրը, և ինչպիսի «տույժեր» ենք վճարում, երբ այս կամ այն ​​շրջանակն ընտրում ենք որպես որոշակի կայքի հիմք:

Նախագիծն օգնեց ինձ հասկանալ դա: HTTP արխիվ.

Տվյալներ

HTTP Archive նախագիծը հետևում է ընդհանուր առմամբ 4308655 հղում դեպի սովորական աշխատասեղանի կայքեր և 5484239 հղումներ դեպի շարժական կայքեր: Այս հղումների հետ կապված բազմաթիվ չափանիշների թվում է համապատասխան կայքերում հայտնաբերված տեխնոլոգիաների ցանկը: Սա նշանակում է, որ մենք կարող ենք նմուշառել հազարավոր կայքեր, որոնք օգտագործում են տարբեր շրջանակներ և գրադարաններ և իմանալ, թե որքան կոդ են նրանք ուղարկում հաճախորդներին և որքան բեռ է ստեղծում այս կոդը օգտատերերի համակարգերում:

Ես հավաքել եմ 2020 թվականի մարտի տվյալներ, որոնք ամենավերջին տվյալներն էին, որոնց հասանելիություն ունեի:

Ես որոշեցի համեմատել HTTP Archive-ի համախմբված տվյալները բոլոր կայքերում React-ի, Vue-ի և Angular-ի միջոցով հայտնաբերված կայքերի տվյալների հետ, թեև ես մտածում էի օգտագործել նաև այլ սկզբնաղբյուր նյութեր:

Այն ավելի հետաքրքիր դարձնելու համար ես նաև jQuery օգտագործող կայքեր եմ ավելացրել աղբյուրի տվյալների հավաքածուում: Այս գրադարանը դեռ շատ տարածված է: Այն նաև ներկայացնում է վեբ մշակման այլ մոտեցում, քան React-ի, Vue-ի և Angular-ի կողմից առաջարկվող Single Page Application (SPA) մոդելը:

Հղումներ 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 

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 

Անկյունային կայքեր
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-ի կողմից գանձվող «հարկը» շատ ցածր է: 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 ԿԲ է: Սա նշանակում է, որ նման կայքերը 322.9 ԿԲ-ով ավելի շատ տվյալներ են ուղարկում բջջային սարքերին, քան իրենց ամենամոտ մրցակիցները՝ հիմնված Vue-ի վրա: Angular-ի և React-ի վրա հիմնված աշխատասեղանի կայքերի և այլ կայքերի միջև բացն էլ ավելի մեծ է: Օրինակ, Desktop React կայքերը սարքերին ուղարկում են 554.7 ԿԲ ավելի շատ 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

Անկյունային կայքեր
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

Անկյունային կայքեր
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 կոդը մշակելու համար: Desktop jQuery կայքերի դեպքում մշակման ժամանակը ավելանում է 37%-ով։ 90-րդ տոկոսային կետում jQuery կայքերը շատ մոտ են միավորների միավորներին: Մասնավորապես, շարժական սարքերում jQuery կայքերը 1.3%-ով ավելի քիչ ժամանակ են ծախսում հիմնական թեմայի վրա, քան բոլոր կայքերը, և 0.7%-ով ավելի քիչ ժամանակ աշխատասեղանի սարքերում:

Մեր վարկանիշի մյուս կողմում այն ​​շրջանակներն են, որոնք բնութագրվում են հիմնական թելի վրա ամենաբարձր ծանրաբեռնվածությամբ: Սա, կրկին, Angular և React է: Այս երկուսի միջև միակ տարբերությունն այն է, որ մինչ Angular կայքերն ավելի շատ կոդ են ուղարկում բրաուզերներին, քան React կայքերը, Angular կայքերը CPU-ի ավելի քիչ ժամանակ են պահանջում ծածկագիրը մշակելու համար: Շատ ավելի քիչ:

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երեմի այս հատկանիշի վրա իմ ուշադրությունը հրավիրելու և այս տեսանկյունից տվյալները ուշադիր դիտարկելու համար): Փաստն այն է, որ շատ կայքեր օգտագործում են մի քանի front-end գործիքներ: Մասնավորապես, ես տեսել եմ բազմաթիվ կայքեր, որոնք օգտագործում են 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

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 շրջանակը:

Source: www.habr.com