JavaScript ჩარჩოების ფასი

არ არსებობს ვებსაიტის შენელების უფრო სწრაფი გზა (არ არის გამიზნული), ვიდრე მასზე JavaScript კოდის გაშვება. JavaScript-ის გამოყენებისას, თქვენ უნდა გადაიხადოთ იგი პროექტის შესრულებაში მინიმუმ ოთხჯერ. აი, რითი იტვირთება საიტის JavaScript კოდი მომხმარებლების სისტემებში:

• ფაილის ატვირთვა ქსელში.
• ჩამოტვირთვის შემდეგ შეუფუთავი კოდის გაანალიზება და შედგენა.
• JavaScript კოდის შესრულება.
• მეხსიერების მოხმარება.

ეს კომბინაცია გამოდის ძალიან ძვირი.

და ჩვენ უფრო და უფრო მეტ JS კოდს ვვრთავთ ჩვენს პროექტებში. როდესაც ორგანიზაციები გადადიან საიტებზე, რომლებიც აღჭურვილია ჩარჩოებით და ბიბლიოთეკებით, როგორიცაა React, Vue და სხვა, ჩვენ ვაქცევთ საიტების ძირითად ფუნქციონირებას ძალიან დამოკიდებული JavaScript-ზე.

მე მინახავს ბევრი ძალიან მძიმე ვებსაიტი JavaScript ჩარჩოების გამოყენებით. მაგრამ ჩემი ხედვა ამ საკითხთან დაკავშირებით ძლიერ მიკერძოებულია. ფაქტია, რომ კომპანიები, რომლებთანაც ვმუშაობ, ჩემთან მოდიან ზუსტად იმიტომ, რომ მათ აქვთ ვებსაიტის მუშაობის რთული პრობლემები. შედეგად, დავინტერესდი, რამდენად გავრცელებულია ეს პრობლემა და რა „ჯარიმებს“ ვიხდით, როდესაც ვირჩევთ ამა თუ იმ ჩარჩოს, როგორც საფუძველს კონკრეტული საიტისთვის.

ეს პროექტი დამეხმარა ამის გარკვევაში. HTTP არქივი.

მონაცემთა

HTTP Archive პროექტი აკონტროლებს სულ 4308655 ბმულს ჩვეულებრივ დესკტოპ საიტებზე და 5484239 ბმულს მობილური საიტებზე. ამ ბმულებთან დაკავშირებულ მრავალ ინდიკატორს შორის არის შესაბამის საიტებზე ნაპოვნი ტექნოლოგიების სია. ეს ნიშნავს, რომ ჩვენ შეგვიძლია შევამოწმოთ ათასობით საიტი, რომლებიც იყენებენ სხვადასხვა ჩარჩოებსა და ბიბლიოთეკებს და გავიგოთ, რამდენ კოდს უგზავნიან კლიენტებს და რამდენ დატვირთვას აყენებს ეს კოდი მომხმარებლების სისტემებზე.

მე შევაგროვე მონაცემები 2020 წლის მარტიდან, რაც იყო ყველაზე ბოლო მონაცემები, რომელზეც მქონდა წვდომა.

მე გადავწყვიტე შემედარებინა HTTP არქივის მონაცემები ყველა საიტისთვის იმ საიტების მონაცემებთან, რომლებიც იყენებდნენ 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 

საიტებზე რეაგირება
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 კბაიტით მეტ მონაცემს მობილურ მოწყობილობებზე, ვიდრე მათი უახლოესი Vue-ზე დაფუძნებული კონკურენტები. კიდევ უფრო დიდია სხვაობა Angular-სა და React-ზე დაფუძნებულ დესკტოპ საიტებსა და სხვა საიტებს შორის. მაგალითად, React დესკტოპის საიტები აგზავნიან 554.7 კბაიტით მეტ JS კოდს მოწყობილობებზე, ვიდრე მსგავსი Vue საიტები.

დრო დასჭირდა JavaScript კოდის მთავარ თემაში დამუშავებას

ზემოაღნიშნული მონაცემები ნათლად მიუთითებს, რომ საიტები, რომლებიც იყენებენ შესწავლილ ჩარჩოებსა და ბიბლიოთეკებს, შეიცავს დიდი რაოდენობით JavaScript კოდს. მაგრამ, რა თქმა უნდა, ეს ჩვენი განტოლების მხოლოდ ერთი ნაწილია.

მას შემდეგ, რაც JavaScript კოდი ბრაუზერში მოხვდება, ის უნდა მოიყვანოთ სამუშაო მდგომარეობაში. განსაკუთრებით ბევრ პრობლემას იწვევს ის მოქმედებები, რომლებიც უნდა განხორციელდეს კოდით მთავარ ბრაუზერის თემაში. მთავარი თემა პასუხისმგებელია მომხმარებლის მოქმედებების დამუშავებაზე, სტილების გამოთვლაზე და გვერდის განლაგების აგებასა და ჩვენებაზე. თუ თქვენ გადატვირთავთ მთავარ თემას JavaScript ამოცანებით, მას არ ექნება შესაძლებლობა დროულად შეასრულოს სხვა ამოცანები. ეს იწვევს გვერდების მუშაობის შეფერხებას და „დამუხრუჭებას“.

HTTP არქივის მონაცემთა ბაზა შეიცავს ინფორმაციას იმის შესახებ, თუ რამდენი ხანი სჭირდება JavaScript კოდის დამუშავებას V8 ძრავის მთავარ ძაფზე. ეს ნიშნავს, რომ ჩვენ შეგვიძლია შევაგროვოთ ეს მონაცემები და გავიგოთ, რამდენი დრო სჭირდება მთავარ თემას სხვადასხვა საიტების JavaScript-ის დასამუშავებლად.

CPU დრო (მილიწამებში) დაკავშირებული სკრიპტის დამუშავებასთან მობილურ მოწყობილობებზე

პროცენტები
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

CPU დრო, რომელიც დაკავშირებულია სკრიპტის დამუშავებასთან მობილურ მოწყობილობებზე

CPU დრო (მილიწამებში) დაკავშირებული სკრიპტის დამუშავებასთან დესკტოპ მოწყობილობებზე

პროცენტები
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

CPU დრო, რომელიც დაკავშირებულია სკრიპტის დამუშავებასთან დესკტოპ მოწყობილობებზე

აქ შეგიძლიათ ნახოთ რაღაც ძალიან ნაცნობი.

დამწყებთათვის, jQuery-ის მქონე საიტები მნიშვნელოვნად ნაკლებ ხარჯავენ JavaScript-ის დამუშავებას მთავარ თემაში, ვიდრე სხვები. მე-10 პროცენტულზე, ყველა საიტთან შედარებით, jQuery საიტები მობილურ მოწყობილობებზე 61%-ით მეტ დროს ხარჯავენ JS კოდის მთავარ თემაში. დესკტოპის jQuery საიტების შემთხვევაში დამუშავების დრო 37%-ით იზრდება. 90-ე ცენტილზე jQuery საიტების ქულები ძალიან ახლოსაა საერთო ქულებთან. კონკრეტულად, jQuery საიტები მობილურ მოწყობილობებზე 1.3%-ით ნაკლებ დროს ატარებენ მთავარ თემაში, ვიდრე ყველა საიტზე, ხოლო დესკტოპ მოწყობილობებზე ისინი 0.7%-ით ნაკლებ დროს ატარებენ მთავარ თემაში.

ჩვენი რეიტინგის მეორე მხარეს არის ჩარჩოები, რომლებიც ხასიათდება ყველაზე დიდი დატვირთვით მთავარ ძაფზე. ეს არის ისევ Angular და React. მათ შორის განსხვავება მხოლოდ ისაა, რომ მიუხედავად იმისა, რომ Angular საიტები უფრო დიდი რაოდენობით კოდს აგზავნიან ბრაუზერებში, ვიდრე React საიტები, CPU-ს ნაკლები დრო სჭირდება 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

კუთხოვანი ვებსაიტები
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%. როდესაც ვებსაიტების დეველოპერები ქმნიან თავიანთ პროექტებს ისე, რომ მათ მეტი CPU დრო დასჭირდეს მათ დასამუშავებლად (და ასეც ხდება და დროთა განმავლობაში მხოლოდ უარესდება), დაბალი სიმძლავრის მოწყობილობების მფლობელებმა უნდა გადაიხადონ ეს.

შედეგები

კარგი ჩარჩოები დეველოპერებს უნდა მისცენ კარგ საფუძველს ვებ პროექტების შესაქმნელად (უსაფრთხოების, ხელმისაწვდომობის, შესრულების თვალსაზრისით), ან უნდა ჰქონდეს ჩაშენებული შეზღუდვები, რაც ართულებს რაიმეს შექმნას, რომელიც არღვევს ამ შეზღუდვებს.

როგორც ჩანს, ეს არ ეხება ვებ პროექტების შესრულებას (და აშკარად მათ ხელმისაწვდომობა).

აღსანიშნავია, რომ მხოლოდ იმიტომ, რომ React ან Angular საიტები ხარჯავენ CPU-ს უფრო მეტ დროს კოდის მომზადებაში, ვიდრე სხვები, სულაც არ ნიშნავს, რომ React საიტები უფრო CPU-ინტენსიურია ვიდრე Vue საიტები გაშვებისას. ფაქტობრივად, ჩვენ მიერ განხილული მონაცემები ძალიან ცოტას ამბობს ჩარჩოების და ბიბლიოთეკების ოპერაციულ შესრულებაზე. ისინი უფრო მეტს საუბრობენ განვითარების მიდგომებზე, რომლისკენაც, შეგნებულად თუ არა, ამ ჩარჩოებს შეუძლიათ პროგრამისტებისკენ უბიძგოს. ჩვენ ვსაუბრობთ ჩარჩოების დოკუმენტაციაზე, მათ ეკოსისტემაზე და განვითარების საერთო ტექნიკაზე.

ასევე ღირს იმის აღნიშვნა, რაც აქ არ გავაანალიზეთ, კერძოდ, რამდენ დროს ხარჯავს მოწყობილობა JavaScript კოდის შესრულებაზე საიტის გვერდებს შორის გადასვლისას. SPA-ს სასარგებლოდ არგუმენტი არის ის, რომ როგორც კი ერთი გვერდიანი აპლიკაცია ჩაიტვირთება ბრაუზერში, მომხმარებელი, თეორიულად, შეძლებს საიტის გვერდებზე უფრო სწრაფად წვდომას. ჩემი საკუთარი გამოცდილება მეუბნება, რომ ეს შორს არის ფაქტისგან. მაგრამ ჩვენ არ გვაქვს მონაცემები ამ საკითხის გასარკვევად.

რა ცხადია, რომ თუ იყენებთ ფრეიმიზორს ან ბიბლიოთეკას ვებსაიტის შესაქმნელად, თქვენ მიდიხართ კომპრომისზე, რომ თავიდან ატვირთოთ პროექტი და მოამზადოთ იგი წასასვლელად. ეს ეხება ყველაზე პოზიტიურ სცენარებსაც კი.

შესაძლებელია გარკვეული კომპრომისების გაკეთება შესაბამის სიტუაციებში, მაგრამ მნიშვნელოვანია, რომ დეველოპერებმა ასეთი კომპრომისები შეგნებულად განახორციელონ.

მაგრამ ჩვენ ასევე გვაქვს ოპტიმიზმის საფუძველი. მე გამხნევებული ვარ იმით, თუ რამდენად მჭიდროდ მუშაობენ Chrome-ის დეველოპერები მათთან, ვინც დგას ზოგიერთი წინა ინსტრუმენტების უკან, რომლებიც ჩვენ განვიხილეთ, რათა დაეხმაროს ამ ხელსაწყოების მუშაობის გაუმჯობესებას.

თუმცა მე პრაგმატული ადამიანი ვარ. ახალი არქიტექტურები ქმნიან შესრულების პრობლემებს იმდენჯერ, რამდენადაც ისინი წყვეტენ მათ. და დრო სჭირდება ხარვეზების აღმოფხვრას. ისევე, როგორც ამას არ უნდა ველოდოთ ახალი ქსელური ტექნოლოგიები მოაგვარებს მუშაობის ყველა პრობლემას, ამას არ უნდა ელოდოთ ჩვენი საყვარელი ჩარჩოების ახალი ვერსიებისგან.

თუ გსურთ გამოიყენოთ ამ მასალაში განხილული ერთ-ერთი ფრონტ-ენდის ინსტრუმენტი, ეს ნიშნავს, რომ მოგიწევთ დამატებითი ძალისხმევის გატარება იმის უზრუნველსაყოფად, რომ, სხვათა შორის, არ დააზიანოთ თქვენი პროექტის შესრულება. აქ არის რამდენიმე მოსაზრება, რომელიც გასათვალისწინებელია ახალი ჩარჩოს გამოყენებამდე:

• შეამოწმეთ საკუთარი თავი საღი აზრით. ნამდვილად გჭირდებათ არჩეული ჩარჩოს გამოყენება? სუფთა JavaScript-ს დღეს ბევრის გაკეთება შეუძლია.
• არის თუ არა თქვენი არჩეული ჩარჩოს უფრო მსუბუქი ალტერნატივა (როგორიცაა Preact, Svelte ან რამე სხვა), რომელიც მოგცემთ ამ ფრეიმურის შესაძლებლობების 90%-ს?
• თუ უკვე იყენებთ Framework-ს, იფიქრეთ იმაზე, არის თუ არა რამე, რომელიც გთავაზობთ უკეთეს, უფრო კონსერვატიულ, სტანდარტულ ვარიანტებს (მაგალითად, Nuxt.js Vue-ს ნაცვლად, Next.js ნაცვლად React და ა.შ.).
• რა იქნება შენი ბიუჯეტი JavaScript შესრულება?
• Როგორ შეგიძლია შეზღუდოს განვითარების პროცესი, რათა გართულდეს პროექტში მეტი JavaScript კოდის დანერგვა, ვიდრე აბსოლუტურად აუცილებელია?
• თუ თქვენ იყენებთ ჩარჩოს განვითარების სიმარტივისთვის, გაითვალისწინეთ გჭირდებათ გაუგზავნეთ ჩარჩო კოდი კლიენტებს. იქნებ ყველა პრობლემა მოაგვარო სერვერზე?

ჩვეულებრივ, ამ იდეების უფრო დეტალურად განხილვა ღირს, იმისდა მიუხედავად, თუ რას აირჩევთ წინა ნაწილის გასავითარებლად. მაგრამ ისინი განსაკუთრებით მნიშვნელოვანია, როდესაც თქვენ მუშაობთ პროექტზე, რომელსაც არ აქვს შესრულება.

ძვირფასო მკითხველს! რას ხედავთ JavaScript-ის იდეალურ ჩარჩოდ?

წყარო: www.habr.com