अविश्वसनीय रूप से तेज़ वेब अनुप्रयोगों पर शोध के लिए प्रदर्शन मेट्रिक्स

एक कहावत है: "आप क्या माप नहीं सकते, आप सुधार नहीं सकते।" लेख के लेखक, जिसका अनुवाद आज हम प्रकाशित कर रहे हैं, सुपरहुमन के लिए काम करता है। उनका कहना है कि यह कंपनी दुनिया का सबसे तेज ईमेल क्लाइंट विकसित कर रही है। यहां हम इस बारे में बात करेंगे कि "तेज़" क्या है, और अविश्वसनीय रूप से तेज़ वेब अनुप्रयोगों के प्रदर्शन को मापने के लिए उपकरण कैसे बनाएं।

अनुप्रयोग गति मापन

अपने विकास को बेहतर बनाने के प्रयास में, हमने इसकी गति को मापने में बहुत समय बिताया। और, जैसा कि यह निकला, प्रदर्शन मीट्रिक संकेतक हैं जो समझने और लागू करने के लिए आश्चर्यजनक रूप से कठिन हैं।

एक ओर, ऐसे मेट्रिक्स को डिजाइन करना मुश्किल है जो सिस्टम के साथ काम करते समय उपयोगकर्ता द्वारा अनुभव की जाने वाली संवेदनाओं का सटीक वर्णन करता है। दूसरी ओर, मीट्रिक बनाना इतना आसान नहीं है जो इतना सटीक हो कि उनका विश्लेषण आपको सूचित निर्णय लेने की अनुमति दे। परिणामस्वरूप, कई विकास दल अपनी परियोजनाओं के प्रदर्शन पर एकत्रित आंकड़ों पर भरोसा नहीं कर सकते हैं।

भले ही डेवलपर्स के पास विश्वसनीय और सटीक मैट्रिक्स हों, उनका उपयोग करना आसान नहीं है। शब्द "फास्ट" को कैसे परिभाषित करें? गति और स्थिरता के बीच संतुलन कैसे खोजें? प्रदर्शन में गिरावट का जल्द पता लगाना या सिस्टम पर अनुकूलन के प्रभाव का मूल्यांकन करना कैसे सीखें?

यहां हम वेब एप्लिकेशन प्रदर्शन विश्लेषण टूल के विकास के बारे में कुछ विचार साझा करना चाहते हैं।

1. सही "घड़ी" का उपयोग

जावास्क्रिप्ट में टाइमस्टैम्प को पुनः प्राप्त करने के लिए दो तंत्र हैं: performance.now() अज्ञात performance.now() और new Date() ।

वे कैसे भिन्न हैं? निम्नलिखित दो अंतर हमारे लिए मूलभूत हैं:

• performance.now() । performance.now() विधि अधिक सटीक है। new Date() निर्माण की सटीकता, 1 एमएस है, जबकि performance.now() की सटीकता। performance.now() पहले से ही (100 Date है (हाँ, यह माइक्रोसेकंड के बारे में है!)।
• performance.now() द्वारा लौटाए गए मान .now performance.now() विधि हमेशा एक स्थिर दर से बढ़ती है और सिस्टम समय से स्वतंत्र होती है। यह विधि केवल सिस्टम समय पर ध्यान दिए बिना समय अंतराल को मापती है। और new Date() सिस्टम का समय प्रभावित होता है। यदि आप सिस्टम क्लॉक को पुनर्व्यवस्थित करते हैं, तो यह भी बदल जाएगा कि कौन सी new Date () वापस आती है, और यह प्रदर्शन निगरानी डेटा को बर्बाद कर देगा।

हालाँकि performance.now() विधि द्वारा दर्शाई गई "घड़ियाँ" समय अंतराल को मापने के लिए स्पष्ट रूप से बेहतर हैं, वे आदर्श भी नहीं हैं। दोनों performance.now() और new Date() एक ही समस्या से ग्रस्त हैं, जो इस घटना में खुद को प्रकट करता है कि सिस्टम नींद की स्थिति में है: माप में वह समय शामिल है जब मशीन भी सक्रिय नहीं थी।

2. आवेदन गतिविधि की जाँच करना

यदि आप किसी वेब एप्लिकेशन के प्रदर्शन को मापते हैं, तो उसके टैब से कुछ अन्य पर स्विच करें - यह डेटा संग्रह प्रक्रिया को बाधित करेगा। क्यों? तथ्य यह है कि ब्राउज़र पृष्ठभूमि टैब में स्थित अनुप्रयोगों को प्रतिबंधित करता है।

ऐसी दो स्थितियाँ हैं जिनमें मैट्रिक्स विकृत हो सकता है। नतीजतन, आवेदन वास्तव में यह है की तुलना में बहुत धीमी लग रही होगी।

1. कंप्यूटर स्लीप मोड में चला जाता है।
2. एप्लिकेशन ब्राउज़र की पृष्ठभूमि टैब में चलता है।

इन दोनों स्थितियों की घटना असामान्य नहीं है। सौभाग्य से, हमारे पास उन्हें हल करने के लिए दो विकल्प हैं।

सबसे पहले, हम केवल विकृत मीट्रिक को अनदेखा कर सकते हैं, माप परिणामों को त्याग सकते हैं जो कुछ उचित मूल्यों से बहुत अधिक भिन्न होते हैं। उदाहरण के लिए, एक बटन दबाए जाने पर कोड को केवल 15 मिनट के लिए निष्पादित नहीं किया जा सकता है! ऊपर वर्णित दो समस्याओं से निपटने के लिए शायद केवल यही एक चीज है जिसकी आपको आवश्यकता है।

दूसरी बात, आप document.hidden प्रॉपर्टी और विजुअलचेंज इवेंट का उपयोग कर सकते हैं। visibilitychange परिवर्तन घटना तब उठाया जाता है जब उपयोगकर्ता ब्याज की ब्राउज़र टैब से दूसरे टैब पर स्विच करता है या हमारे लिए रुचि के टैब पर लौटता है। जब कंप्यूटर कंप्यूटर काम करना शुरू कर देता है, तो स्लीप मोड से बाहर निकलता है, तो इसे कहा जाता है। दूसरे शब्दों में, यह वही है जो हमें चाहिए। इसके अलावा, जब तक टैब बैकग्राउंड में होता है, document.hidden प्रॉपर्टी true होती true ।

यहां document.hidden का उपयोग करने के लिए एक सरल उदाहरण प्रदर्शित किया गया है। संपत्ति और visibilitychange घटना।

 let lastVisibilityChange = 0 window.addEventListener('visibilitychange', () => {  lastVisibilityChange = performance.now() }) //    ,      , //  ,   ,     if (metric.start < lastVisibilityChange || document.hidden) return 

जैसा कि आप देख सकते हैं, हम कुछ डेटा को छोड़ देते हैं, लेकिन यह अच्छा है। तथ्य यह है कि यह कार्यक्रम के उन समय से संबंधित डेटा है जब यह सिस्टम के संसाधनों का पूरी तरह से उपयोग नहीं कर सकता है।

अब हमने उन संकेतकों के बारे में बात की जो हमें रुचि नहीं देते हैं। लेकिन कई स्थितियां हैं, जिसमें एकत्र किए गए डेटा हमारे लिए बहुत दिलचस्प हैं। आइए देखें कि इस डेटा को कैसे इकट्ठा किया जाए।

3. उस संकेतक की खोज करें जो आपको उस घटना को शुरू करने के समय को सर्वोत्तम रूप से पकड़ने की अनुमति देता है

जावास्क्रिप्ट की सबसे विवादास्पद विशेषताओं में से एक यह है कि इस भाषा के लिए ईवेंट लूप एकल-थ्रेडेड है। समय के एक निश्चित बिंदु पर, कोड का केवल एक टुकड़ा निष्पादित करने में सक्षम है, जिसके निष्पादन को बाधित नहीं किया जा सकता है।

यदि उपयोगकर्ता एक निश्चित कोड निष्पादित करते समय बटन दबाता है, तो प्रोग्राम को इस बारे में पता नहीं चलेगा जब तक कि इस कोड का निष्पादन पूरा नहीं हो जाता। उदाहरण के लिए, यदि एप्लिकेशन ने निरंतर चक्र में 1000 एमएस खर्च किए, और उपयोगकर्ता ने चक्र की शुरुआत के बाद Escape बटन 100 एमएस दबाया, तो इवेंट को अन्य 900 एमएस के लिए लॉग इन नहीं किया जाएगा।

यह मेट्रिक्स को बुरी तरह से विकृत कर सकता है। अगर हमें मापने में सटीकता की आवश्यकता है कि उपयोगकर्ता प्रोग्राम के साथ काम करने में कैसा विश्वास करता है, तो यह एक बड़ी समस्या है!

सौभाग्य से, इस समस्या को हल करना इतना मुश्किल नहीं है। यदि हम वर्तमान घटना के बारे में बात कर रहे हैं, तो हम performance.now() का उपयोग करने के बजाय कर सकते हैं। performance.now() (जिस समय हमने घटना को देखा था), window.event.timeStamp (उस समय जब घटना बनाई गई थी) का उपयोग करें।

घटना का टाइमस्टैम्प मुख्य ब्राउज़र प्रक्रिया द्वारा सेट किया गया है। चूँकि जब जेएस ईवेंट लूप बंद होता है, तो यह प्रक्रिया अवरुद्ध नहीं होती है, event.timeStamp हमें इस बारे में अधिक मूल्यवान जानकारी देता है कि इवेंट वास्तव में कब हुआ था।

यह ध्यान दिया जाना चाहिए कि यह तंत्र आदर्श नहीं है। इसलिए, जब भौतिक बटन दबाया जाता है और जिस क्षण में क्रोम में संबंधित घटना आती है, उस समय का 9-15 एमएस बेहिसाब समय बीत जाता है ( यहां एक उत्कृष्ट लेख है जिससे आप जान सकते हैं कि ऐसा क्यों होता है)।

हालाँकि, भले ही हम इवेंट को Chrome तक पहुंचने में लगने वाले समय को माप सकें, हमें इस समय को अपने मैट्रिक्स में शामिल नहीं करना चाहिए। क्यों? तथ्य यह है कि हम इस तरह के अनुकूलन को कोड में शामिल नहीं कर सकते हैं जो इस तरह की देरी को काफी प्रभावित कर सकता है। हम उन्हें किसी भी तरह से सुधार नहीं सकते।

नतीजतन, अगर हम घटना की शुरुआत के लिए टाइमस्टैम्प को खोजने के बारे में बात करते हैं, तो event.timeStamp संकेतक यहां सबसे पर्याप्त दिखता है।

जब घटना समाप्त हो जाती है तो सबसे अच्छा अनुमान क्या है?

4. अनुरोध में टाइमर बंद करें।

एक और परिणाम जावास्क्रिप्ट में ईवेंट लूप डिवाइस की सुविधाओं से आता है: कुछ कोड जो आपके कोड से संबंधित नहीं है, इसके बाद निष्पादित किया जा सकता है, लेकिन इससे पहले कि ब्राउज़र स्क्रीन पर पृष्ठ का एक अद्यतन संस्करण प्रदर्शित करता है।

उदाहरण के लिए, रिएक्ट पर विचार करें। अपना कोड निष्पादित करने के बाद, प्रतिक्रिया DOM को अपडेट करता है। यदि आप केवल अपने कोड में समय को मापते हैं, तो इसका मतलब है कि आपने रिएक्ट कोड को निष्पादित करने में लगने वाले समय को नहीं मापा है।

इस अतिरिक्त समय को मापने के लिए, हम टाइमर बंद करने के लिए requestAnimationFrame() का उपयोग करते हैं। यह केवल तब किया जाता है जब ब्राउज़र अगले फ्रेम को आउटपुट करने के लिए तैयार होता है।

 requestAnimationFrame(() => { metric.finish(performance.now()) }) 

यहाँ फ्रेम का जीवन चक्र है (आरेख इस अद्भुत सामग्री से requestAnimationFrame पर लिया गया है।


जीवन चक्र

जैसा कि आप इस आंकड़े में देख सकते हैं, requestAnimationFrame() पूरा होने से ठीक पहले फ्रेम के प्रदर्शित होने के बाद requestAnimationFrame() कहा जाता है। यदि हम यहां टाइमर को बंद कर देते हैं, तो इसका मतलब है कि हम पूरी तरह से सुनिश्चित हो सकते हैं कि स्क्रीन को रिफ्रेश करने के लिए समय लेने वाली हर चीज को समय अंतराल पर एकत्रित आंकड़ों में शामिल किया गया है।

अब तक बहुत अच्छा है, लेकिन अब स्थिति जटिल हो रही है ...

5. पेज लेआउट और इसके विज़ुअलाइज़ेशन बनाने के लिए आवश्यक समय की अनदेखी करना।

पिछले आरेख, एक फ्रेम के जीवन चक्र को दर्शाता है, जो हमारे सामने आई एक और समस्या को दिखाता है। फ़्रेम के जीवन चक्र के अंत में, लेआउट ब्लॉक (पृष्ठ लेआउट बनाते हुए) और पेंट (एक पृष्ठ प्रदर्शित करना) हैं। यदि आप इन कार्यों को पूरा करने के लिए आवश्यक समय को ध्यान में नहीं रखते हैं, तो हमारे द्वारा मापा गया समय स्क्रीन पर दिखाई देने वाले कुछ अपडेट किए गए डेटा की तुलना में कम समय होगा।

सौभाग्य से, requestAnimationFrame ने अपनी आस्तीन पर एक और इक्का है। जब requestAnimationFrame द्वारा पारित फ़ंक्शन requestAnimationFrame कहा जाता है, तो इस फ़ंक्शन को एक टाइम स्टैम्प दिया जाता है, जो वर्तमान फ्रेम के गठन के प्रारंभ समय का संकेत देता है (अर्थात, हमारे आरेख के बहुत बाएं हिस्से में स्थित है)। यह टाइमस्टैम्प आमतौर पर पिछले फ्रेम के अंत समय के बहुत करीब है।

नतीजतन, उपरोक्त दोष को event.timeStamp के क्षण से समाप्त किए गए कुल समय को मापने के द्वारा ठीक किया जा सकता है। अगली फ्रेम के गठन की शुरुआत के समय से लेकर। नेस्टेड requestAnimationFrame ध्यान दें

 requestAnimationFrame(() => {  requestAnimationFrame((timestamp) => { metric.finish(timestamp) }) }) 

यद्यपि ऊपर जो दिखाया गया है वह समस्या के एक उत्कृष्ट समाधान की तरह दिखता है, अंत में, हमने इस डिजाइन का उपयोग नहीं करने का फैसला किया। तथ्य यह है कि, हालांकि यह तकनीक अधिक विश्वसनीय डेटा प्राप्त करना संभव बनाती है, ऐसे डेटा की सटीकता कम हो जाती है। क्रोम में फ़्रेम 16 एमएस की आवृत्ति के साथ बनते हैं। इसका मतलब है कि हमारे लिए उपलब्ध उच्चतम सटीकता। 16 एमएस है। और अगर ब्राउज़र अतिभारित है और फ़्रेम को छोड़ देता है, तो सटीकता और भी कम हो जाएगी, और यह गिरावट अप्रत्याशित होगी।

यदि आप इस समाधान को लागू करते हैं, तो अपने कोड के प्रदर्शन में एक गंभीर सुधार, जैसे कि एक कार्य को तेज करना जो पहले 32 एमएस, 15 एमएस तक किया गया था, प्रदर्शन माप परिणामों को प्रभावित नहीं कर सकता है।

पृष्ठ लेआउट और इसके आउटपुट को बनाने में लगने वाले समय को ध्यान में नहीं रखते हुए, हमें अपने नियंत्रण में आने वाले कोड के लिए अधिक सटीक मेट्रिक्स (time 100 μs) मिलते हैं। नतीजतन, हम इस कोड में किए गए किसी भी सुधार की एक संख्यात्मक अभिव्यक्ति प्राप्त कर सकते हैं।

हमने एक समान विचार भी खोजा:

 requestAnimationFrame(() => {  setTimeout(() => { metric.finish(performance.now()) } }) 

इसमें रेंडरिंग समय शामिल होगा, लेकिन संकेतक की सटीकता। 16 एमएस तक सीमित नहीं होगी। हालांकि, हमने इस दृष्टिकोण का उपयोग नहीं करने का फैसला किया। यदि सिस्टम एक लंबी इनपुट घटना का सामना करता है, तो जो setTimeout प्रेषित होता है उसे कॉल करने में काफी देरी हो सकती है और उपयोगकर्ता इंटरफ़ेस अपडेट होने के बाद निष्पादित किया जा सकता है।

6. "लक्ष्य से नीचे रहने वाली घटनाओं का प्रतिशत" का स्पष्टीकरण

हम एक परियोजना विकसित कर रहे हैं और उच्च प्रदर्शन पर ध्यान केंद्रित कर इसे दो तरीकों से अनुकूलित करने की कोशिश कर रहे हैं:

1. स्पीड। सबसे तेज कार्य का निष्पादन समय यथासंभव 0 एमएस के करीब होना चाहिए।
2. एकरूपता। सबसे धीमे कार्य का निष्पादन समय जितना संभव हो उतना तेज़ कार्य के निष्पादन समय के करीब होना चाहिए।

इस तथ्य के कारण कि ये संकेतक समय के साथ बदलते हैं, उन्हें कल्पना करना मुश्किल है और चर्चा करना आसान नहीं है। क्या ऐसे संकेतकों के विज़ुअलाइज़ेशन की एक प्रणाली बनाना संभव है जो हमें गति और एकरूपता दोनों को अनुकूलित करने के लिए प्रेरित करेगा?

देरी के 90 वें प्रतिशत को मापने के लिए एक विशिष्ट दृष्टिकोण है। यह दृष्टिकोण आपको वाई अक्ष के साथ एक रेखा ग्राफ खींचने की अनुमति देता है जिसमें मिलीसेकंड में समय बचाया जाता है। यह ग्राफ़ आपको यह देखने की अनुमति देता है कि 90% घटनाएं लाइन ग्राफ़ से नीचे हैं, अर्थात, वे उस समय की तुलना में तेज़ी से निष्पादित करते हैं जो लाइन ग्राफ़ इंगित करता है।

यह ज्ञात है कि 100 एमएस "तेज" और "धीमी" के रूप में माना जाता है के बीच की सीमा है।

लेकिन हम इस बारे में क्या पता लगाएंगे कि उपयोगकर्ता काम से कैसा महसूस करते हैं अगर हम जानते हैं कि देरी का 90 वां प्रतिशत 103 एमएस है? विशेष रूप से ज्यादा नहीं। कौन से संकेतक उपयोगकर्ताओं को प्रयोज्य प्रदान करेंगे? यह सुनिश्चित करने का कोई तरीका नहीं है।

लेकिन क्या होगा अगर हम जानते हैं कि देरी का 90 वां प्रतिशत 93 एमएस है? एक भावना है कि 93 103 से बेहतर है, लेकिन हम इन संकेतकों के बारे में अधिक कुछ नहीं कह सकते हैं, साथ ही साथ वे परियोजना की उपयोगकर्ता धारणा के संदर्भ में क्या कहते हैं। फिर, इस सवाल का कोई सटीक जवाब नहीं है।

हमने इस समस्या का हल ढूंढ लिया है। यह उन घटनाओं के प्रतिशत को मापने में शामिल है जिनके निष्पादन का समय 100 एमएस से अधिक नहीं है। इस दृष्टिकोण के तीन बड़े फायदे हैं:

• मीट्रिक उपयोगकर्ता उन्मुख है। वह बता सकती है कि हमारा आवेदन कितने प्रतिशत तेज है, और कितने प्रतिशत उपयोगकर्ता इसे उपवास मानते हैं।
• यह मीट्रिक हमें सटीकता को माप वापस करने की अनुमति देता है जो इस तथ्य के कारण खो गया था कि हमने फ्रेम के बहुत अंत में कार्यों को पूरा करने के लिए उठाए गए समय को नहीं मापा था (हमने इस बारे में खंड संख्या 5 में बात की थी)। इस तथ्य के कारण कि हम एक लक्ष्य संकेतक निर्धारित करते हैं जो कई फ़्रेमों में फिट बैठता है, इस संकेतक के करीब माप परिणाम या तो इससे कम या अधिक हो जाते हैं।
• यह मीट्रिक गणना करना आसान है। यह उन घटनाओं की संख्या की गणना करने के लिए पर्याप्त है जिनके निष्पादन का समय लक्ष्य संकेतक के नीचे है, और उसके बाद - उन्हें घटनाओं की कुल संख्या से विभाजित करें। प्रतिशत अधिक कठिन हैं। प्रभावी सन्निकटन हैं, लेकिन सब कुछ सही करने के लिए, आपको प्रत्येक आयाम को ध्यान में रखना होगा।

इस दृष्टिकोण में केवल एक माइनस है: यदि संकेतक लक्ष्य से बदतर हैं, तो उनके सुधार को नोटिस करना आसान नहीं होगा।

7. संकेतकों के विश्लेषण में कई दहलीज मूल्यों का उपयोग

प्रदर्शन अनुकूलन के परिणाम की कल्पना करने के लिए, हमने अपने सिस्टम में कई अतिरिक्त थ्रेशोल्ड मान पेश किए हैं - 100 एमएस से ऊपर और नीचे।

हमने देरी को इस तरह से समूहीकृत किया:

• कम से कम 50 एमएस (तेज)।
• 50 से 100 एमएस (अच्छा)।
• 100 से 1000 एमएस (धीमी)।
• 1000 से अधिक एमएस (बहुत धीमी गति से)।

"बहुत धीमे" परिणाम हमें यह देखने की अनुमति देते हैं कि हमने कहीं बहुत याद किया है। इसलिए, हम उन्हें उज्ज्वल लाल रंग में उजागर करते हैं।

50 एमएस में जो फिट बैठता है वह परिवर्तनों के प्रति बहुत संवेदनशील है। यहां, प्रदर्शन सुधार अक्सर लंबे समय तक दिखाई देते हैं, इससे पहले कि उन्हें 100 एमएस से मेल खाने वाले समूह में देखा जा सके।

उदाहरण के लिए, निम्न ग्राफ़ सुपरहुमन में थ्रेड देखने के प्रदर्शन को दर्शाता है।


धागा देखें

यह प्रदर्शन में गिरावट की अवधि दिखाता है, और फिर - सुधार के परिणाम। यदि आप केवल 100 ms (नीले स्तंभों के ऊपरी भाग) के अनुरूप संकेतक देखते हैं, तो प्रदर्शन ड्रॉप का आकलन करना मुश्किल है। जब परिणाम 50 ms (हरे रंग के स्तंभों के ऊपरी भाग) में फिट होते हैं, तो प्रदर्शन की समस्याएं पहले से ही बहुत अधिक स्पष्ट रूप से दिखाई देती हैं।

यदि हम प्रदर्शन मेट्रिक्स के अध्ययन के लिए पारंपरिक दृष्टिकोण का उपयोग करते हैं, तो हमने शायद ऐसी समस्या पर ध्यान नहीं दिया होगा जिसका सिस्टम पिछले प्रभाव में दिखाया गया है। लेकिन जिस तरह से हम माप लेते हैं और जिस तरह से हम अपने मैट्रिक्स की कल्पना करते हैं, उसके लिए धन्यवाद, हम एक समस्या को बहुत जल्दी खोजने और हल करने में सक्षम थे।

परिणाम

यह पता चला कि प्रदर्शन मेट्रिक्स के साथ काम करने के लिए सही दृष्टिकोण खोजना आश्चर्यजनक रूप से कठिन था। हम एक कार्यप्रणाली विकसित करने में कामयाब रहे जो हमें वेब अनुप्रयोगों के प्रदर्शन को मापने के लिए उच्च-गुणवत्ता वाले उपकरण बनाने की अनुमति देती है। अर्थात्, हम निम्नलिखित के बारे में बात कर रहे हैं:

1. किसी ईवेंट का प्रारंभ समय event.timeStamp का उपयोग करके मापा जाता है।
2. requestAnimationFrame() करने के लिए पारित कॉलबैक में performance.now() समाप्ति का समय performance.now() का उपयोग करके घटना अंत समय मापा जाता है।
3. सब कुछ जो एप्लिकेशन के साथ होता है जबकि यह निष्क्रिय ब्राउज़र टैब पर होता है उसे नजरअंदाज कर दिया जाता है।
4. डेटा को एक संकेतक का उपयोग करके एकत्र किया जाता है, जिसे "लक्ष्य से नीचे की घटनाओं का प्रतिशत" के रूप में वर्णित किया जा सकता है।
5. डेटा को कई स्तरों के थ्रेशोल्ड वैल्यूज़ के साथ देखा जाता है।

यह तकनीक आपको विश्वसनीय और सटीक मैट्रिक्स बनाने के लिए उपकरण देती है। आप ऐसे ग्राफ़ बना सकते हैं जो प्रदर्शन में स्पष्ट रूप से गिरावट दिखाते हैं, आप अनुकूलन के परिणामों की कल्पना कर सकते हैं। और सबसे महत्वपूर्ण बात - आपके पास त्वरित परियोजनाओं को और भी तेज करने का अवसर है।

प्रिय पाठकों! आप अपने वेब एप्लिकेशन के प्रदर्शन का विश्लेषण कैसे करते हैं?