តម្លៃនៃក្របខ័ណ្ឌ JavaScript

មិនមានវិធីលឿនជាងក្នុងការបន្ថយល្បឿនគេហទំព័រ (គ្មានចេតនា) ជាជាងដំណើរការកូដ JavaScript ជាច្រើននៅលើវា។ នៅពេលប្រើ JavaScript អ្នកត្រូវចំណាយសម្រាប់វាក្នុងការអនុវត្តគម្រោងយ៉ាងហោចណាស់បួនដង។ នេះជាអ្វីដែលកូដ JavaScript របស់គេហទំព័រផ្ទុកប្រព័ន្ធរបស់អ្នកប្រើជាមួយ៖

• ការបង្ហោះឯកសារនៅលើបណ្តាញ។
• ញែក និងចងក្រងកូដប្រភពដែលមិនបានខ្ចប់បន្ទាប់ពីទាញយក។
• ដំណើរការកូដ JavaScript ។
• ការប្រើប្រាស់អង្គចងចាំ។

ការរួមបញ្ចូលគ្នានេះប្រែទៅជា ថ្លៃ​ណាស់.

ហើយយើងកំពុងរួមបញ្ចូលកូដ JS កាន់តែច្រើនឡើងនៅក្នុងគម្រោងរបស់យើង។ នៅពេលដែលអង្គការផ្លាស់ទីឆ្ពោះទៅរកគេហទំព័រដែលដំណើរការដោយក្របខ័ណ្ឌ និងបណ្ណាល័យដូចជា React, Vue និងផ្សេងទៀត យើងកំពុងធ្វើឱ្យមុខងារស្នូលនៃគេហទំព័រពឹងផ្អែកលើ JavaScript យ៉ាងខ្លាំង។

ខ្ញុំ​បាន​ឃើញ​គេហទំព័រ​ធ្ងន់​ៗ​ជា​ច្រើន​ដែល​ប្រើ​ក្របខ័ណ្ឌ JavaScript។ ប៉ុន្តែចក្ខុវិស័យរបស់ខ្ញុំចំពោះបញ្ហាគឺមានភាពលំអៀងយ៉ាងខ្លាំង។ ការពិតគឺថាក្រុមហ៊ុនដែលខ្ញុំធ្វើការជាមួយបានមករកខ្ញុំយ៉ាងជាក់លាក់ ដោយសារតែពួកគេមានបញ្ហាដំណើរការគេហទំព័រស្មុគស្មាញ។ ជាលទ្ធផល ខ្ញុំចង់ដឹងចង់ឃើញថាតើបញ្ហានេះរីករាលដាលប៉ុណ្ណា ហើយតើ "ការផាកពិន័យ" អ្វីខ្លះដែលយើងបង់នៅពេលយើងជ្រើសរើសក្របខ័ណ្ឌមួយ ឬក្របខ័ណ្ឌផ្សេងទៀតជាមូលដ្ឋានសម្រាប់គេហទំព័រជាក់លាក់មួយ។

គម្រោងនេះបានជួយខ្ញុំដោះស្រាយរឿងនេះ។ ប័ណ្ណសារ HTTP.

ទិន្នន័យ

គម្រោង HTTP Archive តាមដានតំណភ្ជាប់សរុបចំនួន 4308655 ទៅកាន់គេហទំព័រកុំព្យូទ័រធម្មតា និង 5484239 តំណភ្ជាប់ទៅកាន់គេហទំព័រទូរស័ព្ទ។ ក្នុងចំណោមសូចនាករជាច្រើនដែលទាក់ទងនឹងតំណភ្ជាប់ទាំងនេះគឺជាបញ្ជីនៃបច្ចេកវិទ្យាដែលបានរកឃើញនៅលើគេហទំព័រដែលត្រូវគ្នា។ នេះមានន័យថាយើងអាចយកគំរូគេហទំព័ររាប់ពាន់ដែលប្រើក្របខណ្ឌ និងបណ្ណាល័យផ្សេងៗគ្នា ហើយសិក្សាពីចំនួនកូដដែលពួកគេផ្ញើទៅអតិថិជន និងចំនួនផ្ទុកកូដនោះដាក់លើប្រព័ន្ធរបស់អ្នកប្រើប្រាស់។

ខ្ញុំបានប្រមូលទិន្នន័យពីខែមីនា ឆ្នាំ 2020 ដែលជាទិន្នន័យចុងក្រោយបំផុតដែលខ្ញុំបានចូលប្រើ។

ខ្ញុំបានសម្រេចចិត្តប្រៀបធៀបទិន្នន័យ HTTP Archive សរុបសម្រាប់គេហទំព័រទាំងអស់ជាមួយនឹងទិន្នន័យសម្រាប់គេហទំព័រដែលបានរកឃើញថាកំពុងប្រើ React, Vue និង Angular ទោះបីជាខ្ញុំបានពិចារណាប្រើប្រភពផ្សេងទៀតផងដែរ។

ដើម្បីធ្វើឱ្យវាកាន់តែចាប់អារម្មណ៍ ខ្ញុំក៏បានបន្ថែមគេហទំព័រដែលប្រើ jQuery ទៅក្នុងសំណុំទិន្នន័យប្រភព។ បណ្ណាល័យនេះនៅតែមានប្រជាប្រិយភាពខ្លាំង។ វាក៏ណែនាំអំពីវិធីសាស្រ្តសម្រាប់ការអភិវឌ្ឍន៍គេហទំព័រដែលខុសពីគំរូ Single Page Application (SPA) ដែលផ្តល់ដោយ React, Vue និង Angular។

តំណភ្ជាប់នៅក្នុងបណ្ណសារ HTTP តំណាងឱ្យគេហទំព័រដែលត្រូវបានរកឃើញថាកំពុងប្រើប្រាស់បច្ចេកវិទ្យាដែលចាប់អារម្មណ៍ចំពោះយើង

ក្របខ័ណ្ឌ ឬបណ្ណាល័យ
តំណភ្ជាប់ទៅកាន់គេហទំព័រចល័ត
តំណភ្ជាប់ទៅកាន់គេហទំព័រធម្មតា។

jQuery
4615474
3714643

ប្រតិកម្ម
489827
241023

មើល
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 

ប្រតិកម្មគេហទំព័រ
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 

ប្រតិកម្មគេហទំព័រ
308.6 
469.0 
841.9 
1472.2 
2197.8 

ចំនួន​កូដ JavaScript ផ្ទេរ​ទៅ​ឧបករណ៍​កុំព្យូទ័រ

ប្រសិនបើយើងនិយាយតែអំពីទំហំនៃលេខកូដ JS ដែលគេហទំព័រផ្ញើទៅកាន់ឧបករណ៍ នោះអ្វីៗនឹងមើលទៅដូចដែលអ្នករំពឹងទុក។ ពោលគឺប្រសិនបើក្របខ័ណ្ឌមួយត្រូវបានប្រើប្រាស់ នេះមានន័យថាសូម្បីតែនៅក្នុងស្ថានភាពដ៏ល្អក៏ដោយ បរិមាណនៃកូដ JavaScript សម្រាប់គេហទំព័រនឹងកើនឡើង។ នេះមិនគួរឱ្យភ្ញាក់ផ្អើលទេ - អ្នកមិនអាចបង្កើតក្របខ័ណ្ឌ JavaScript ជាមូលដ្ឋាននៃគេហទំព័រមួយហើយរំពឹងថាបរិមាណនៃកូដ JS សម្រាប់គម្រោងនឹងមានកម្រិតទាបណាស់។

អ្វីដែលគួរឱ្យចាប់អារម្មណ៍អំពីទិន្នន័យនេះគឺថាក្របខ័ណ្ឌ និងបណ្ណាល័យមួយចំនួនអាចត្រូវបានចាត់ទុកថាជាចំណុចចាប់ផ្តើមល្អប្រសើរសម្រាប់គម្រោងមួយជាងគម្រោងផ្សេងទៀត។ គេហទំព័រដែលមាន jQuery មើលទៅល្អបំផុត។ គេហទំព័រលើតុរបស់ពួកគេមាន JavaScript ច្រើនជាងគេហទំព័រទាំងអស់ 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 desktop ផ្ញើលេខកូដ JS ច្រើនជាង 554.7 KB ទៅកាន់ឧបករណ៍ជាងគេហទំព័រ 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

ប្រតិកម្មគេហទំព័រ
2700.1
5090.3
9287.6
14509.6
20813.3

ពេលវេលា 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

គេហទំព័រ Angular
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 ។ ប្រហែលជាគាត់មាន codebase ដែលបណ្ណាល័យទាំងនេះត្រូវបានលាយបញ្ចូលគ្នា។ ដោយសារយើងបានឃើញរួចហើយថាគេហទំព័រ 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

ប្រតិកម្មគេហទំព័រ
431.5
386.8
337.9
242.6
179.6

ខណៈពេលដែលភាពខុសគ្នាខ្លះនៃល្បឿនដំណើរការកូដរវាងទូរស័ព្ទ និងកុំព្យូទ័រយួរដៃមួយត្រូវបានរំពឹងទុក តួលេខដ៏ច្រើនបែបនេះប្រាប់ខ្ញុំថា ក្របខ័ណ្ឌទំនើបមិនត្រូវបានកំណត់គោលដៅគ្រប់គ្រាន់សម្រាប់ឧបករណ៍ថាមពលទាប និងបំណងប្រាថ្នាដើម្បីបិទគម្លាតដែលត្រូវបានកំណត់អត្តសញ្ញាណនោះទេ។ ទោះបីជានៅភាគរយទី 10 ក៏ដោយ គេហទំព័រ React ចំណាយពេល 431.5% បន្ថែមទៀតលើបណ្តាញទូរស័ព្ទចល័តជាងនៅលើបណ្តាញមេរបស់កុំព្យូទ័រ។ jQuery មានគម្លាតតូចបំផុត ប៉ុន្តែសូម្បីតែនៅទីនេះ តួលេខដែលត្រូវគ្នាគឺ 188.2% ។ នៅពេលដែលអ្នកបង្កើតគេហទំព័របង្កើតគម្រោងរបស់ពួកគេតាមរបៀបដែលពួកគេត្រូវការពេលវេលាស៊ីភីយូបន្ថែមទៀតដើម្បីដំណើរការពួកវា (ហើយនេះគឺជាអ្វីដែលកើតឡើង ហើយវាកាន់តែអាក្រក់ទៅៗតាមពេលវេលា) ម្ចាស់ឧបករណ៍ថាមពលទាបត្រូវចំណាយសម្រាប់វា។

លទ្ធផល

ក្របខ័ណ្ឌល្អគួរតែផ្តល់ឱ្យអ្នកអភិវឌ្ឍន៍នូវមូលដ្ឋានគ្រឹះដ៏ល្អសម្រាប់ការកសាងគម្រោងគេហទំព័រ (ទាក់ទងនឹងសុវត្ថិភាព ភាពងាយស្រួល ការអនុវត្ត) ឬគួរតែមានការរឹតបន្តឹងដែលបង្កការលំបាកក្នុងការបង្កើតអ្វីមួយដែលបំពានលើការរឹតបន្តឹងទាំងនោះ។

នេះហាក់ដូចជាមិនអនុវត្តចំពោះការអនុវត្តគម្រោងបណ្តាញ (ហើយជាក់ស្តែងចំពោះគម្រោងរបស់ពួកគេ។ ភាពងាយស្រួល).

វាគួរឱ្យកត់សម្គាល់ថាដោយសារតែគេហទំព័រ React ឬ Angular ចំណាយពេល CPU ច្រើនក្នុងការរៀបចំកូដជាងកន្លែងផ្សេងទៀត មិនមានន័យថាគេហទំព័រ React ប្រើប្រាស់ស៊ីភីយូច្រើនជាងគេហទំព័រ Vue នៅពេលដំណើរការនោះទេ។ តាមពិត ទិន្នន័យដែលយើងមើលនិយាយតិចតួចណាស់អំពីដំណើរការប្រតិបត្តិការនៃក្របខ័ណ្ឌ និងបណ្ណាល័យ។ ពួកគេនិយាយបន្ថែមអំពីវិធីសាស្រ្តនៃការអភិវឌ្ឍន៍ ដែលក្របខ័ណ្ឌទាំងនេះអាចជំរុញអ្នកសរសេរកម្មវិធីឆ្ពោះទៅរកដោយដឹងខ្លួន ឬអត់។ យើងកំពុងនិយាយអំពីឯកសារសម្រាប់ក្របខ័ណ្ឌ ប្រព័ន្ធអេកូឡូស៊ី និងបច្ចេកទេសអភិវឌ្ឍន៍ទូទៅ។

វាក៏មានតម្លៃផងដែរក្នុងការនិយាយអំពីអ្វីមួយដែលយើងមិនបានវិភាគនៅទីនេះ ពោលគឺថាតើឧបករណ៍ចំណាយពេលប៉ុន្មានក្នុងការប្រតិបត្តិកូដ JavaScript នៅពេលផ្លាស់ប្តូររវាងទំព័រនៃគេហទំព័រ។ អាគុយម៉ង់នៅក្នុងការពេញចិត្តនៃ SPA គឺថានៅពេលដែលកម្មវិធីទំព័រតែមួយត្រូវបានផ្ទុកទៅក្នុងកម្មវិធីរុករក អ្នកប្រើប្រាស់នឹងអាចចូលប្រើទំព័រគេហទំព័របានលឿនជាងមុន។ បទពិសោធន៍ផ្ទាល់របស់ខ្ញុំប្រាប់ខ្ញុំថា នេះគឺនៅឆ្ងាយពីការពិត។ ប៉ុន្តែយើងមិនមានទិន្នន័យដើម្បីបញ្ជាក់បញ្ហានេះទេ។

អ្វីដែលច្បាស់នោះគឺថា ប្រសិនបើអ្នកប្រើក្របខណ្ឌ ឬបណ្ណាល័យដើម្បីបង្កើតគេហទំព័រ នោះអ្នកកំពុងធ្វើការសម្របសម្រួលក្នុងលក្ខខណ្ឌនៃការផ្ទុកគម្រោងដំបូង ហើយរៀបចំវាឱ្យរួចរាល់។ នេះអនុវត្តសូម្បីតែចំពោះសេណារីយ៉ូវិជ្ជមានបំផុត។

វាអាចទៅរួចក្នុងការសម្របសម្រួលខ្លះក្នុងស្ថានភាពសមស្រប ប៉ុន្តែវាជាការសំខាន់ណាស់ដែលអ្នកអភិវឌ្ឍន៍ធ្វើការសម្របសម្រួលបែបនេះដោយមនសិការ។

ប៉ុន្តែយើងក៏មានហេតុផលសម្រាប់សុទិដ្ឋិនិយមផងដែរ។ ខ្ញុំត្រូវបានលើកទឹកចិត្តដោយភាពជិតស្និទ្ធរបស់អ្នកអភិវឌ្ឍន៍ Chrome កំពុងធ្វើការជាមួយអ្នកដែលនៅពីក្រោយឧបករណ៍ផ្នែកខាងមុខមួយចំនួនដែលយើងបានគ្របដណ្តប់ ដើម្បីជួយកែលម្អដំណើរការនៃឧបករណ៍ទាំងនោះ។

ទោះយ៉ាងណាក៏ដោយ ខ្ញុំជាមនុស្សដែលមានប្រាជ្ញា។ ស្ថាបត្យកម្មថ្មីបង្កើតបញ្ហាក្នុងការអនុវត្តជាញឹកញាប់នៅពេលដែលពួកគេដោះស្រាយវា។ ហើយវាត្រូវការពេលវេលាដើម្បីលុបបំបាត់ចំណុចខ្វះខាត។ ដូចដែលយើងមិនគួររំពឹងនោះទេ។ បច្ចេកវិទ្យាបណ្តាញថ្មី។ នឹងដោះស្រាយបញ្ហាដំណើរការទាំងអស់ អ្នកមិនគួររំពឹងពីកំណែថ្មីនៃក្របខ័ណ្ឌដែលយើងចូលចិត្តនោះទេ។

ប្រសិនបើអ្នកចង់ប្រើឧបករណ៍ផ្នែកខាងមុខមួយដែលបានពិភាក្សានៅក្នុងសម្ភារៈនេះ នេះមានន័យថាអ្នកនឹងត្រូវខិតខំប្រឹងប្រែងបន្ថែមទៀតដើម្បីធានាថា ចៃដន្យ អ្នកមិនបង្កគ្រោះថ្នាក់ដល់ការអនុវត្តគម្រោងរបស់អ្នក។ នេះ​ជា​ការ​ពិចារណា​មួយ​ចំនួន​ដែល​ត្រូវ​ពិចារណា មុន​ពេល​អ្នក​ចាប់​ផ្តើម​ប្រើ​ក្រប​ខ័ណ្ឌ​ថ្មី៖

• ពិនិត្យខ្លួនអ្នកដោយសុភវិនិច្ឆ័យ។ តើអ្នកពិតជាត្រូវការប្រើក្របខណ្ឌដែលអ្នកបានជ្រើសរើសមែនទេ? JavaScript សុទ្ធអាចធ្វើបានច្រើនថ្ងៃនេះ។
• តើមានជម្រើសស្រាលជាងទៅនឹងក្របខ័ណ្ឌនៃជម្រើសរបស់អ្នក (ដូចជា Preact, Svelte ឬអ្វីផ្សេងទៀត) ដែលអាចផ្តល់ឱ្យអ្នក 90% នៃសមត្ថភាពនៃក្របខ័ណ្ឌនោះ?
• ប្រសិនបើអ្នកកំពុងប្រើក្របខ័ណ្ឌរួចហើយ សូមគិតអំពីថាតើមានអ្វីមួយដែលផ្តល់នូវជម្រើសស្តង់ដារដែលប្រសើរជាងមុន អភិរក្សនិយម (ឧទាហរណ៍ Nuxt.js ជំនួសឱ្យ Vue, Next.js ជំនួសឱ្យ React ។ល។)។
• អ្វីដែលអ្នកនឹង ថវិកា ដំណើរការ JavaScript?
• របៀប​ដែល​អ្នក​អាច​ធ្វើ​បាន កំណត់។ ដំណើរការអភិវឌ្ឍន៍ដើម្បីធ្វើឱ្យវាពិបាកក្នុងការណែនាំកូដ JavaScript បន្ថែមទៀតទៅក្នុងគម្រោង ជាងការចាំបាច់មែនទេ?
• ប្រសិនបើអ្នកកំពុងប្រើក្របខ័ណ្ឌសម្រាប់ភាពងាយស្រួលនៃការអភិវឌ្ឍន៍ សូមពិចារណា តើ​អ្នក​ត្រូវការ ផ្ញើកូដក្របខ័ណ្ឌទៅអតិថិជន។ ប្រហែលជាអ្នកអាចដោះស្រាយបញ្ហាទាំងអស់នៅលើម៉ាស៊ីនមេ?

ជាធម្មតា គំនិតទាំងនេះមានតម្លៃក្នុងការពិនិត្យមើលឱ្យកាន់តែដិតដល់ ដោយមិនគិតពីអ្វីដែលអ្នកជ្រើសរើសដើម្បីអភិវឌ្ឍផ្នែកខាងមុខនោះទេ។ ប៉ុន្តែពួកវាមានសារៈសំខាន់ជាពិសេសនៅពេលដែលអ្នកកំពុងធ្វើការលើគម្រោងដែលខ្វះការអនុវត្តដើម្បីចាប់ផ្តើម។

អ្នកអានជាទីស្រឡាញ់! តើអ្នកឃើញអ្វីជាក្របខ័ណ្ឌ JavaScript ដ៏ល្អ?

ប្រភព: www.habr.com