जाभास्क्रिप्ट फ्रेमवर्कको मूल्य

त्यहाँ जाभास्क्रिप्ट कोड को एक गुच्छा प्रयोग गर्नु भन्दा एक वेबसाइट (श्लेष अभिप्रेत) को ढिलो गर्न को लागी कुनै छिटो तरिका छैन। जाभास्क्रिप्ट प्रयोग गर्दा, तपाईंले चार पटक भन्दा कम परियोजनाहरूको प्रदर्शनको साथ यसको लागि तिर्नुपर्छ। यहाँ छ कसरी साइटको JavaScript कोडले प्रयोगकर्ताहरूको प्रणाली लोड गर्छ:

• नेटवर्कमा फाइल डाउनलोड गर्दै।
• डाउनलोड पछि अनप्याक गरिएको स्रोत कोड पार्सिङ र कम्पाइल गर्दै।
• जाभास्क्रिप्ट कोडको कार्यान्वयन।
• मेमोरी खपत।

यो संयोजन बाहिर जान्छ अति महङ्गो.

र हामी हाम्रो परियोजनाहरूमा अधिक र अधिक JS कोड समावेश गर्दछौं। संस्थाहरू फ्रेमवर्क र React, Vue र अन्य जस्ता पुस्तकालयहरूद्वारा सञ्चालित साइटहरूतर्फ सर्दा, हामी साइटहरूको मूल कार्यक्षमतालाई JavaScript मा धेरै निर्भर बनाउँदैछौं।

मैले JavaScript फ्रेमवर्क प्रयोग गरेर धेरै धेरै भारी साइटहरू देखेको छु। तर यस मुद्दामा मेरो दृष्टिकोण धेरै पक्षपाती छ। तथ्य यो हो कि मैले काम गर्ने कम्पनीहरू मलाई ठ्याक्कै फर्काउँछन् किनभने तिनीहरू साइट प्रदर्शनको क्षेत्रमा जटिल समस्याहरूको सामना गरिरहेका छन्। नतिजाको रूपमा, म यो समस्या कत्तिको सामान्य छ भन्ने बारे उत्सुक भएँ, र हामीले एक निश्चित साइटको आधारको रूपमा एक वा अर्को फ्रेमवर्क छनौट गर्दा हामीले कस्तो प्रकारको "दण्ड" तिर्छौं भन्ने बारे उत्सुक भएँ।

परियोजनाले मलाई यो पत्ता लगाउन मद्दत गर्यो। HTTP अभिलेख.

डाटा

HTTP अभिलेख परियोजनाले नियमित डेस्कटप साइटहरूमा कुल 4308655 लिङ्कहरू र मोबाइल साइटहरूमा 5484239 लिङ्कहरू ट्र्याक गर्दछ। यी लिङ्कहरूसँग सम्बन्धित धेरै मेट्रिकहरू मध्ये सम्बन्धित साइटहरूमा फेला परेका प्रविधिहरूको सूची हो। यसको मतलब हामी विभिन्न फ्रेमवर्क र लाइब्रेरीहरू प्रयोग गर्ने हजारौं साइटहरूको नमूना लिन सक्छौं र उनीहरूले ग्राहकहरूलाई कति कोड पठाउँछन् र यो कोडले प्रयोगकर्ताहरूको प्रणालीमा कति लोड गर्छ भन्ने बारे जान्न सक्छौं।

मैले मार्च २०२० को डेटा सङ्कलन गरें, जुन मैले पहुँच गरेको सबैभन्दा हालको डाटा थियो।

मैले React, Vue, र Angular प्रयोग गरेर फेला परेका साइटहरूको डेटासँग सबै साइटहरूमा एकत्रित HTTP अभिलेख डेटा तुलना गर्ने निर्णय गरेँ, यद्यपि मैले अन्य स्रोत सामग्रीहरू पनि प्रयोग गर्ने विचार गरें।

यसलाई थप रोचक बनाउनको लागि, मैले स्रोत डेटा सेटमा jQuery प्रयोग गर्ने साइटहरू पनि थपेको छु। यो पुस्तकालय अझै पनि धेरै लोकप्रिय छ। यसले React, Vue र Angular द्वारा प्रस्ताव गरेको एकल पृष्ठ अनुप्रयोग (SPA) मोडेल भन्दा वेब विकासको लागि फरक दृष्टिकोण पनि प्रस्तुत गर्दछ।

HTTP अभिलेखमा रहेका लिंकहरूले साइटहरूलाई प्रतिनिधित्व गर्ने रुचिका प्रविधिहरू प्रयोग गरिरहेको फेला परेको छ

फ्रेमवर्क वा पुस्तकालय
मोबाइल साइटहरूमा लिङ्कहरू
नियमित साइटहरूमा लिङ्कहरू

jQuery
4615474
3714643

प्रतिक्रिया
489827
241023

Vue
85649
43691

कोणीय
19423
18088

आशा र सपनाहरु

हामी डेटा विश्लेषणमा जानु अघि, म के आशा गर्न चाहन्छु भन्ने बारे कुरा गर्न चाहन्छु।

मलाई विश्वास छ कि एक आदर्श संसारमा, फ्रेमवर्कहरू विकासकर्ताहरूको आवश्यकताहरू पूरा गर्न र हाम्रा साइटहरूसँग काम गर्ने औसत प्रयोगकर्तालाई केही विशेष फाइदाहरू प्रदान गर्नुपर्दछ। प्रदर्शन ती फाइदाहरू मध्ये एक मात्र हो। यो जहाँ पहुँच र सुरक्षा खेलमा आउँछ। तर यो मात्र सबैभन्दा महत्त्वपूर्ण छ।

त्यसोभए, एक आदर्श संसारमा, केहि प्रकारको फ्रेमवर्कले उच्च-प्रदर्शन साइट सिर्जना गर्न सजिलो बनाउनु पर्छ। यो या त यस तथ्यको कारणले गर्दा गरिनु पर्छ कि ढाँचाले विकासकर्तालाई परियोजना निर्माण गर्नको लागि एक सभ्य आधार दिन्छ, वा यसले विकासमा प्रतिबन्धहरू थोपर्छ, यसको लागि आवश्यकताहरू अगाडि राख्छ जसले कुनै चीजको विकासलाई जटिल बनाउँछ। ढिलो हुन बाहिर।

उत्कृष्ट ढाँचाहरूले दुवै गर्नुपर्छ: राम्रो आधार दिनुहोस्, र काममा प्रतिबन्धहरू लगाउनुहोस्, तपाईंलाई राम्रो परिणाम प्राप्त गर्न अनुमति दिनुहोस्।

डाटाको मध्य मानहरूको विश्लेषणले हामीलाई आवश्यक जानकारी दिनेछैन। र, वास्तवमा, यो दृष्टिकोण हाम्रो ध्यान बाहिर छोड्छ धेरै महत्त्वपूर्ण। बरु, मैले मसँग भएको डाटाबाट प्रतिशतहरू निकालें। यी हुन् १०, २५, ५० (मध्य), ७५, ९० प्रतिशत।

मलाई विशेष गरी १० औं र ९० औं प्रतिशतमा रुचि छ। 10 औं प्रतिशतले एक विशेष फ्रेमवर्कको लागि धेरै राम्रो प्रदर्शन (वा कम्तिमा धेरै वा कम भन्दा राम्रोको नजिक) प्रतिनिधित्व गर्दछ। अर्को शब्दहरूमा, यसको मतलब यो हो कि केवल 90% साइटहरू एक विशेष फ्रेमवर्क प्रयोग गरेर यो स्तरमा, वा उच्च बनाउँछन्। 10 औं प्रतिशत, अर्कोतर्फ, सिक्काको अर्को पक्ष हो - यसले हामीलाई कसरी खराब चीजहरू प्राप्त गर्न सक्छ भनेर देखाउँदछ। ९० औं प्रतिशत भनेको पछाडि रहेका साइटहरू हुन् — ती तल्लो १०% साइटहरू जसमा सबैभन्दा धेरै JS कोड छ वा मुख्य थ्रेडमा तिनीहरूको कोड प्रशोधन गर्न सबैभन्दा लामो समय छ।

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 

जाभास्क्रिप्ट कोडको मात्रा मोबाइल उपकरणहरूमा पठाइयो

जाभास्क्रिप्ट कोडको मात्रा (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 

जाभास्क्रिप्ट कोडको मात्रा डेस्कटप उपकरणहरूमा पठाइयो

यदि हामीले JS कोडको साइजको बारेमा मात्र कुरा गर्छौं जुन साइटहरूले यन्त्रहरूमा पठाउँछन्, तब सबै कुरा तपाईंले अपेक्षा गरे जस्तै देखिन्छ। अर्थात्, यदि फ्रेमवर्कहरू मध्ये एक प्रयोग गरिन्छ, यसको मतलब यो हो कि एक आदर्श स्थितिमा पनि, साइटको JavaScript कोडको मात्रा बढ्नेछ। यो अचम्मको कुरा होइन - तपाइँ जाभास्क्रिप्ट फ्रेमवर्कलाई साइटको आधार बनाउन सक्नुहुन्न र आशा गर्न सक्नुहुन्छ कि परियोजनाको JS कोडको भोल्युम धेरै कम हुनेछ।

यस डेटाको बारेमा के उल्लेखनीय छ कि केहि फ्रेमवर्क र पुस्तकालयहरू अन्य भन्दा परियोजनाको लागि राम्रो सुरूवात बिन्दु मान्न सकिन्छ। jQuery भएका साइटहरू उत्तम देखिन्छन्। साइटहरूको डेस्कटप संस्करणहरूमा, तिनीहरूले सबै साइटहरू भन्दा 15% बढी जाभास्क्रिप्ट समावेश गर्दछ, र मोबाइलमा तिनीहरूले 18% बढी समावेश गर्दछ। (मान्य रूपमा, यहाँ केहि डाटा भ्रष्टाचार छ। तथ्य यो हो कि jQuery धेरै साइटहरूमा अवस्थित छ, त्यसैले यो स्वाभाविक हो कि त्यस्ता साइटहरू अन्य साइटहरूको कुल संख्याको तुलनामा धेरै नजिक छन्। यद्यपि, यसले कच्चा कत्तिको असर गर्दैन। डाटा प्रत्येक फ्रेमवर्कको लागि आउटपुट हो।)

जबकि कोड भोल्युममा 15-18% वृद्धि एक उल्लेखनीय आंकडा हो, यसलाई अन्य फ्रेमवर्क र पुस्तकालयहरूसँग तुलना गर्दा, एक निष्कर्षमा पुग्न सक्छ कि jQuery द्वारा लगाइएको "कर" धेरै कम छ। १० औं पर्सेन्टाइलमा रहेका कोणीय साइटहरूले सबै साइटहरू भन्दा डेस्कटपमा ३४४% बढी डाटा र मोबाइलमा ३७७% बढी डेटा पठाउँछन्। प्रतिक्रिया साइटहरू सबै साइटहरू भन्दा डेस्कटपमा 10% बढी कोड पठाउने र मोबाइलमा 344% बढी कोड पठाउने अर्को सबैभन्दा भारी हुन्।

पहिले, मैले उल्लेख गरें कि ढाँचा प्रयोग गर्नुको मतलब यो हो कि कोडको एक निश्चित मात्रामा परियोजनामा ​​​​समावेश हुनेछ, यसमा कामको शुरुवातमा, मलाई आशा छ कि फ्रेमवर्कले विकासकर्तालाई सीमित गर्न सक्षम छ। विशेष गरी, हामी कोडको अधिकतम मात्रा सीमित गर्ने बारे कुरा गर्दैछौं।

चाखलाग्दो कुरा, jQuery साइटहरूले यो विचार पछ्याउँछन्। जबकि तिनीहरू 10 औं प्रतिशतमा सबै साइटहरू भन्दा थोरै भारी छन् (15-18% द्वारा), तिनीहरू डेस्कटप र मोबाइल दुवैमा लगभग 90% मा 3 औं प्रतिशतमा थोरै हल्का छन्। यो भन्नको लागि होइन कि यो एक धेरै महत्त्वपूर्ण लाभ हो, तर यो भन्न सकिन्छ कि jQuery साइटहरू, कम्तिमा, ठूलो जाभास्क्रिप्ट कोड आकारहरू छैनन्, तिनीहरूको सबैभन्दा ठूलो संस्करणहरूमा पनि।

तर अन्य ढाँचाहरूको बारेमा पनि यही भन्न सकिँदैन।

10 औं पर्सेन्टाइलको मामलामा जस्तै, Angular र React मा 90 औं पर्सेन्टाइल साइटहरू अन्य साइटहरू भन्दा भिन्न हुन्छन्, तर तिनीहरू फरक हुन्छन्, दुर्भाग्यवश, खराबको लागि।

९० औं प्रतिशतमा, एङ्गुलर साइटहरूले सबै साइटहरू भन्दा मोबाइलमा १४१% बढी डाटा पठाउँछन्, र १५९% बढी डेस्कटपमा। प्रतिक्रिया साइटहरूले सबै साइटहरू भन्दा डेस्कटपमा 90% बढी र मोबाइलमा 141% बढी पठाउँछन्। 159 औं प्रतिशतमा प्रतिक्रिया साइटहरूको कोड साइज 73 KB हो। यसको मतलब त्यस्ता साइटहरूले Vue मा आधारित आफ्ना निकटतम प्रतिद्वन्द्वीहरू भन्दा मोबाइल उपकरणहरूमा 58 KB बढी डाटा पठाउँछन्। Angular र React र अन्य साइटहरूमा आधारित डेस्कटप साइटहरू बीचको अन्तर अझ ठूलो छ। उदाहरणका लागि, डेस्कटप प्रतिक्रिया साइटहरूले समान Vue साइटहरू भन्दा उपकरणहरूमा 90 KB बढी JS कोड पठाउँछन्।

मुख्य थ्रेडमा JavaScript कोड प्रशोधन गर्न लाग्ने समय

माथिको डेटाले स्पष्ट रूपमा संकेत गर्दछ कि अध्ययन अन्तर्गत फ्रेमवर्क र पुस्तकालयहरू प्रयोग गर्ने साइटहरूमा जाभास्क्रिप्ट कोडको ठूलो मात्रा हुन्छ। तर निस्सन्देह, त्यो हाम्रो समीकरणको एक भाग मात्र हो।

जाभास्क्रिप्ट कोड ब्राउजरमा आइसकेपछि, यसलाई कार्ययोग्य अवस्थामा ल्याउन आवश्यक छ। विशेष गरी धेरै समस्याहरू ती कार्यहरूको कारणले गर्दा मुख्य ब्राउजर थ्रेडमा कोडको साथ गर्नुपर्दछ। मुख्य थ्रेड प्रयोगकर्ता कार्यहरू प्रशोधन गर्न, शैलीहरू गणना गर्न, पृष्ठ लेआउट निर्माण र प्रदर्शन गर्न जिम्मेवार छ। यदि तपाइँ जाभास्क्रिप्ट कार्यहरु संग मुख्य थ्रेड ओभरवेम गर्नुभयो भने, यो समय मा बाँकी कार्यहरु पूरा गर्ने अवसर हुनेछैन। यसले पृष्ठहरूको काममा ढिलाइ र "ब्रेक" निम्त्याउँछ।

HTTP अभिलेख डेटाबेससँग V8 इन्जिनको मुख्य थ्रेडमा JavaScript कोड प्रशोधन गर्न कति समय लाग्छ भन्ने बारे जानकारी छ। यसको मतलब यो हो कि हामी यो डाटा सङ्कलन गर्न सक्छौं र मुख्य थ्रेडले विभिन्न साइटहरूको 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

मोबाइल उपकरणहरूमा स्क्रिप्ट प्रशोधनसँग सम्बन्धित प्रोसेसर समय

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

डेस्कटप उपकरणहरूमा स्क्रिप्ट प्रशोधनसँग सम्बन्धित प्रोसेसर समय

यहाँ तपाइँ केहि धेरै परिचित देख्न सक्नुहुन्छ।

शुरुवातका लागि, jQuery भएका साइटहरूले अन्य साइटहरू भन्दा मुख्य थ्रेडमा JavaScript प्रशोधनमा उल्लेखनीय रूपमा कम खर्च गर्छन्। १० औं प्रतिशतमा, सबै साइटहरूको तुलनामा, मोबाइलमा jQuery साइटहरूले मुख्य थ्रेडमा JS कोड प्रशोधन गर्न 10% बढी समय खर्च गर्छन्। डेस्कटप jQuery साइटहरूको मामलामा, प्रशोधन समय 61% ले बढ्छ। 37 औं प्रतिशतमा, jQuery साइटहरूले समग्र स्कोरको धेरै नजिक स्कोर गर्दछ। विशेष रूपमा, मोबाइल उपकरणहरूमा jQuery साइटहरूले सबै साइटहरू भन्दा मुख्य थ्रेडमा 90% कम समय र डेस्कटप उपकरणहरूमा 1.3% कम समय खर्च गर्दछ।

हाम्रो मूल्याङ्कनको अर्को छेउमा फ्रेमवर्कहरू छन् जुन मुख्य थ्रेडमा उच्चतम लोड द्वारा विशेषता छन्। यो, फेरि, Angular र प्रतिक्रिया हो। दुई बीचको मात्र फरक यो हो कि Angular साइटहरूले प्रतिक्रिया साइटहरू भन्दा ब्राउजरहरूमा धेरै कोड पठाउँदा, Angular साइटहरूले कोड प्रक्रिया गर्न कम CPU समय लिन्छन्। एकदम थाेरै।

१० औं प्रतिशतमा, डेस्कटप एङ्गुलर साइटहरूले मुख्य थ्रेड प्रशोधन गर्ने JS कोडमा सबै साइटहरू भन्दा २३०% बढी समय खर्च गर्छन्। मोबाइल साइटहरूको लागि, यो संख्या 10% हो। प्रतिक्रिया साइटहरू सबैभन्दा खराब प्रदर्शनकर्ताहरू हुन्। डेस्कटपमा, तिनीहरूले सबै साइटहरू भन्दा 230% बढी समय कोड प्रशोधन गर्छन्, र 313% बढी मोबाइलमा। 248% एक टाइपो होइन। १० औं प्रतिशतमा, प्रतिक्रिया साइटहरूले मुख्य थ्रेड समयको २.७ सेकेन्ड आफ्नो कोड प्रशोधन गर्न खर्च गर्छन्।

यी ठूला संख्याहरूसँग तुलना गर्दा ९० औं प्रतिशत कम्तिमा अलि राम्रो देखिन्छ। सबै साइटहरूको तुलनामा, Angular परियोजनाहरूले मुख्य थ्रेडमा डेस्कटप उपकरणहरूमा 90% बढी समय र मोबाइल उपकरणहरूमा 29% बढी समय खर्च गर्छन्। प्रतिक्रिया साइटहरूको मामलामा, समान तथ्याङ्कहरू क्रमशः 27% र 130% जस्तो देखिन्छ।

90 औं प्रतिशतका लागि प्रतिशत विचलनहरू 10 औं प्रतिशतका लागि समान मानहरू भन्दा राम्रो देखिन्छ। तर यहाँ यो सम्झना लायक छ कि समय संकेत गर्ने संख्याहरू डरलाग्दो देखिन्छ। प्रतिक्रियाको साथ बनाइएको वेबसाइटको लागि मुख्य मोबाइल थ्रेडमा 20.8 सेकेन्ड भनौं। (मलाई लाग्छ कि यस समयमा वास्तवमा के हुन्छ भन्ने कथा छुट्टै लेखको योग्य छ)।

यहाँ एउटा सम्भावित जटिलता छ (धन्यवाद यर्मिया यस सुविधामा मेरो ध्यानाकर्षणको लागि, र यस दृष्टिकोणबाट डेटालाई ध्यानपूर्वक विचार गर्नको लागि)। तथ्य यो हो कि धेरै साइटहरूले धेरै फ्रन्ट-एन्ड उपकरणहरू प्रयोग गर्छन्। विशेष गरी, मैले प्रतिक्रिया वा Vue सँग jQuery प्रयोग गर्ने धेरै साइटहरू देखेको छु, किनकि ती साइटहरू jQuery बाट अन्य फ्रेमवर्क वा पुस्तकालयहरूमा माइग्रेट हुँदैछन्। नतिजाको रूपमा, मैले डाटाबेसलाई फेरि हिट गरें, यस पटक केवल प्रतिक्रिया, 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

प्रतिक्रिया मात्र प्रयोग गर्ने साइटहरू
2443.2
4620.5
10061.4
17074.3
24956.3

साइटहरूले केवल एउटा फ्रेमवर्क वा केवल एउटा पुस्तकालय प्रयोग गर्ने स्थितिमा मोबाइल उपकरणहरूमा लिपिहरू प्रशोधन गर्न सम्बन्धित प्रोसेसर समय

पहिलो, केहि अचम्मको छैन: जब एक साइटले केवल एक फ्रेमवर्क वा एक पुस्तकालय प्रयोग गर्दछ, त्यस्ता साइटको कार्यसम्पादन धेरै पटक सुधार हुन्छ। प्रत्येक उपकरणले 10 औं र 25 औं प्रतिशतमा राम्रो प्रदर्शन गर्दछ। यसले अर्थ राख्छ। एउटा ढाँचा प्रयोग गरेर बनाइएको साइटले दुई वा बढी फ्रेमवर्क वा पुस्तकालयहरू प्रयोग गरेर बनाइएको साइटभन्दा राम्रो प्रदर्शन गर्नुपर्छ।

वास्तवमा, अध्ययन गरिएको प्रत्येक फ्रन्ट-एन्ड उपकरणको प्रदर्शन एक जिज्ञासु अपवाद बाहेक सबै अवस्थामा राम्रो देखिन्छ। मलाई के छक्क पर्यो कि 50th प्रतिशत र माथि, React प्रयोग गर्ने साइटहरूले तिनीहरूले प्रयोग गर्ने एक मात्र पुस्तकालय हुँदा React प्रयोग गर्ने साइटहरूले खराब प्रदर्शन गर्छन्। यो, वैसे, मैले यो डाटा यहाँ प्रस्तुत गरेको कारण थियो।

यो अलिकति अनौठो छ, तर म अझै पनि यो अनौठोपनको लागि व्याख्या खोज्ने प्रयास गर्नेछु।

यदि परियोजनाले प्रतिक्रिया र jQuery दुवै प्रयोग गर्दछ भने, त्यो परियोजना सम्भवतः jQuery बाट प्रतिक्रियामा संक्रमणको माध्यमबाट आधा बाटोमा हुन्छ। सायद यसमा कोडबेस छ जहाँ यी पुस्तकालयहरू मिश्रित छन्। हामीले पहिले नै देखेका छौं कि jQuery साइटहरूले प्रतिक्रिया साइटहरू भन्दा मुख्य थ्रेडमा कम समय बिताउँछन्, यसले हामीलाई बताउन सक्छ कि jQuery मा केही कार्यक्षमता लागू गर्दा साइटलाई अलि राम्रो प्रदर्शन गर्न मद्दत गर्दछ।

तर परियोजना jQuery बाट React मा ट्रान्जिसन र प्रतिक्रिया मा अधिक निर्भर रूपमा, चीजहरू परिवर्तन हुँदैछन्। यदि साइट साँच्चै उच्च गुणस्तरको छ, र साइट विकासकर्ताहरूले प्रतिक्रिया सावधानीपूर्वक प्रयोग गर्छन् भने, त्यस्ता साइटसँग सबै कुरा ठीक हुनेछ। तर औसत प्रतिक्रिया साइटको लागि, प्रतिक्रियाको व्यापक प्रयोगको अर्थ मुख्य थ्रेड भारी लोड अन्तर्गत छ।

मोबाइल र डेस्कटप उपकरणहरू बीचको अन्तर

अर्को दृष्टिकोण जसबाट मैले अनुसन्धान गरिएको डेटामा हेरेँ त्यो अध्ययन गर्नु थियो कि मोबाइल र डेस्कटप उपकरणहरूमा साइटहरूसँग काम गर्ने बीचको अन्तर कति ठूलो छ। यदि हामी जाभास्क्रिप्ट कोडको भोल्युमहरू तुलना गर्ने बारे कुरा गर्छौं भने, यस्तो तुलनाले कुनै पनि भयानक कुरा प्रकट गर्दैन। निस्सन्देह, यो डाउनलोड गर्न योग्य कोड को सानो मात्रा हेर्न राम्रो हुनेछ, तर मोबाइल र डेस्कटप कोड को मात्रा मा धेरै भिन्नता छैन।

तर यदि हामीले कोड प्रशोधन गर्न आवश्यक पर्ने समयको विश्लेषण गर्छौं भने, मोबाइल र डेस्कटप उपकरणहरू बीचको ठूलो खाडल देखिन्छ।

डेस्कटपको तुलनामा मोबाइल उपकरणहरूमा प्रशोधन लिपिहरूसँग सम्बन्धित समय (प्रतिशत) मा वृद्धि

प्रतिशतहरू
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 औं प्रतिशतमा पनि, प्रतिक्रिया साइटहरूले डेस्कटप मुख्य थ्रेडमा भन्दा मोबाइल मुख्य थ्रेडमा 431.5% बढी समय खर्च गर्छन्। jQuery मा सबैभन्दा सानो अन्तर छ, तर यहाँ पनि सम्बन्धित आंकडा 188.2% छ। जब वेबसाइट विकासकर्ताहरूले तिनीहरूको परियोजनाहरू यसरी बनाउँछन् कि तिनीहरूको प्रशोधनलाई अधिक प्रोसेसर समय चाहिन्छ (र यो हुन्छ, र यो केवल समयको साथ खराब हुन्छ), कम-शक्तियुक्त उपकरणहरूको मालिकहरूले यसको लागि तिर्नुपर्छ।

परिणामहरू

राम्रो फ्रेमवर्कले विकासकर्ताहरूलाई वेब परियोजनाहरू (सुरक्षा, पहुँच, कार्यसम्पादनको सन्दर्भमा) निर्माण गर्नको लागि राम्रो आधार दिनुपर्दछ, वा तिनीहरूसँग अन्तर्निहित प्रतिबन्धहरू हुनुपर्दछ जसले ती प्रतिबन्धहरूलाई उल्लङ्घन गर्ने केहि निर्माण गर्न गाह्रो बनाउँदछ।

यो वेब परियोजनाहरूको कार्यसम्पादनमा लागू हुने देखिँदैन (र सम्भवतः तिनीहरूको पहुँच).

यो ध्यान दिन लायक छ कि प्रतिक्रिया वा एङ्गुलर साइटहरूले अरूको तुलनामा कोड तयार गर्न धेरै CPU समय खर्च गर्दछन् यसको मतलब यो होइन कि प्रतिक्रिया साइटहरू चलिरहेको बेला Vue साइटहरू भन्दा बढी CPU गहन हुन्छन्। वास्तवमा, हामीले समीक्षा गरेका डेटाले फ्रेमवर्क र पुस्तकालयहरूको परिचालन कार्यसम्पादनको बारेमा धेरै कम भन्छ। तिनीहरू विकास दृष्टिकोणहरूको बारेमा बढी कुरा गर्छन् कि, होशियार वा होइन, यी फ्रेमवर्कहरूले प्रोग्रामरहरूलाई धक्का दिन सक्छन्। हामी फ्रेमवर्कका लागि कागजातहरू, तिनीहरूको इकोसिस्टमको बारेमा, साझा विकास प्रविधिहरूको बारेमा कुरा गर्दैछौं।

यो पनि केहि उल्लेख गर्न लायक छ जुन हामीले यहाँ विश्लेषण गरेनौं, अर्थात्, साइटको पृष्ठहरू बीच नेभिगेट गर्दा उपकरणले JavaScript कोड कार्यान्वयन गर्न कति समय खर्च गर्दछ। SPA को पक्षमा तर्क यो हो कि एक पटक एकल पृष्ठ अनुप्रयोग ब्राउजरमा लोड भएपछि, प्रयोगकर्ताले सैद्धान्तिक रूपमा साइटका पृष्ठहरू छिटो खोल्न सक्षम हुनेछ। मेरो आफ्नै अनुभवले मलाई बताउँछ कि यो तथ्यबाट टाढा छ। तर हामीसँग यो मुद्दा स्पष्ट गर्न डाटा छैन।

के स्पष्ट छ कि यदि तपाइँ वेबसाइट सिर्जना गर्न फ्रेमवर्क वा पुस्तकालय प्रयोग गर्दै हुनुहुन्छ भने, तपाइँ प्रारम्भिक रूपमा परियोजना लोड गर्ने र यसलाई जानको लागि तयार हुने सन्दर्भमा सम्झौता गर्दै हुनुहुन्छ। यो सबैभन्दा सकारात्मक परिदृश्यहरूमा पनि लागू हुन्छ।

उपयुक्त परिस्थितिहरूमा केही सम्झौताहरू गर्न पूर्ण रूपमा सम्भव छ, तर विकासकर्ताहरूले सचेत रूपमा त्यस्ता सम्झौताहरू गर्न महत्त्वपूर्ण छ।

तर हामीसँग आशावादी हुनुको कारण पनि छ। क्रोम विकासकर्ताहरूले ती उपकरणहरूको कार्यसम्पादन सुधार गर्न मद्दत गर्ने प्रयासमा हामीले समीक्षा गरेका केही फ्रन्ट-एन्ड उपकरणहरूको विकासकर्ताहरूसँग कत्तिको नजिकबाट काम गरिरहेका छन् भनेर हेर्न म उत्साहित छु।

तर, म व्यावहारिक व्यक्ति हुँ। नयाँ वास्तुकलाहरूले कार्यसम्पादन समस्याहरू सिर्जना गर्छन् जतिबेला तिनीहरूले तिनीहरूलाई समाधान गर्छन्। र बगहरू ठीक गर्न समय लाग्छ। जसरी हामीले आशा गर्नु हुँदैन नयाँ नेटवर्क प्रविधिहरू सबै प्रदर्शन समस्याहरू समाधान गर्नेछ, तपाईंले हाम्रो मनपर्ने फ्रेमवर्कको नयाँ संस्करणहरूबाट यो आशा गर्नु हुँदैन।

यदि तपाइँ यस लेखमा छलफल गरिएको फ्रन्ट-एन्ड उपकरणहरू मध्ये एक प्रयोग गर्न चाहनुहुन्छ भने, यसको मतलब यो हो कि तपाइँले यस बीचमा तपाइँको परियोजनाको कार्यसम्पादनलाई हानि नगर्न थप प्रयास गर्नु पर्छ। नयाँ फ्रेमवर्क सुरु गर्नु अघि विचार गर्न यहाँ केहि विचारहरू छन्:

• सामान्य ज्ञान संग आफैलाई परीक्षण गर्नुहोस्। के तपाइँ साँच्चै छानिएको फ्रेमवर्क प्रयोग गर्न आवश्यक छ? शुद्ध जाभास्क्रिप्ट आज धेरै सक्षम छ।
• के त्यहाँ छनोट गरिएको ढाँचाको हल्का विकल्प छ (जस्तै Preact, Svelte वा अरू केहि) जसले तपाईंलाई यस फ्रेमवर्कको 90% क्षमताहरू दिन सक्छ?
• यदि तपाइँ पहिले नै एक फ्रेमवर्क प्रयोग गर्दै हुनुहुन्छ भने, त्यहाँ केहि राम्रो, अधिक रूढ़िवादी, मानक विकल्पहरू प्रस्ताव गर्दछ कि भनेर विचार गर्नुहोस् (उदाहरणका लागि, Vue को सट्टा Nuxt.js, React को सट्टा Next.js, र यस्तै)।
• तपाईको के हुनेछ बजेट जाभास्क्रिप्ट प्रदर्शन?
• कसरी सक्छौ सीमा एक विकास प्रक्रिया यो एकदम आवश्यक भन्दा धेरै जाभास्क्रिप्ट कोड एक परियोजना मा इन्जेक्ट गर्न गाह्रो बनाउन?
• यदि तपाइँ विकासको सहजताको लागि फ्रेमवर्क प्रयोग गर्दै हुनुहुन्छ भने, विचार गर्नुहोस् तपाईलाई चाहिन्छ ग्राहकहरूलाई फ्रेमवर्क कोड पठाउनुहोस्। सायद तपाइँ सर्भरमा सबै समस्याहरू समाधान गर्न सक्नुहुन्छ?

सामान्यतया यी विचारहरू हेर्न लायक छन्, तपाईंले फ्रन्ट-एन्ड विकासको लागि वास्तवमा के छनौट गर्नुभयो। तर तिनीहरू विशेष गरी महत्त्वपूर्ण हुन्छन् जब तपाइँ एक परियोजनामा ​​काम गर्दै हुनुहुन्छ जुन सुरुदेखि नै प्रदर्शनको कमी छ।

प्रिय पाठकहरु! तपाईं आदर्श JavaScript फ्रेमवर्क कसरी देख्नुहुन्छ?

स्रोत: www.habr.com