परफ़ॉर्मेंस ट्रबलशूटिंग और डायग्नोस्टिक्स: परफ़ॉर्मेंस की समस्याएँ पहचानना और ठीक करना

परफ़ॉर्मेंस गिर जाती है। जो पेज दो सेकंड में लोड होता था, वह अब चार सेकंड में लोड होता है। कुछ बदला है।

ट्रबलशूटिंग इनके जवाब देती है: क्या बदला। परफ़ॉर्मेंस क्यों गिरी।

असली वजहें: नए फ़ीचर ने बड़ा JavaScript बंडल जोड़ा। डेटाबेस क्वेरी धीमी हो गई। थर्ड-पार्टी स्क्रिप्ट जुड़ी। इमेज का साइज़ बढ़ा। सर्वर पर लोड ज़्यादा हो गया।

व्यवस्थित ट्रबलशूटिंग असली वजह खोजती है। व्यवस्थित फ़िक्सिंग असली वजह हटाती है।

ट्रबलशूटिंग का तरीका

पहला कदम: लक्षण पहचानें। LCP दो से बढ़कर चार सेकंड हो गया। CLS 0.05 से बढ़कर 0.2 हो गया। INP सौ से बढ़कर चार सौ मिलीसेकंड हो गया।

दूसरा कदम: टाइमलाइन। गिरावट कब शुरू हुई। पिछले हफ़्ते। कल। पिछले घंटे। टाइमलाइन से खोज का दायरा छोटा होता है।

तीसरा कदम: बदलावों से जोड़ें। कौन-सा कोड बदला। कौन-से फ़ीचर रिलीज़ हुए। इन्फ़्रास्ट्रक्चर में क्या बदला। इस जोड़ से वजह पता चलती है।

चौथा कदम: वजह अलग करें। परफ़ॉर्मेंस गिरी। अनुमान: नया JavaScript बंडल। टेस्ट: नया बंडल बंद करके LCP मापें। LCP वापस दो सेकंड पर आ जाता है। अनुमान सही निकला।

पाँचवाँ कदम: ठीक करें या रोलबैक करें। वजह ठीक करें (बंडल ऑप्टिमाइज़ करें) या रोलबैक करें (बदलाव वापस लें)। फ़ैसला समस्या की गंभीरता पर निर्भर करता है।

असली उदाहरण: ई-कॉमर्स साइट की परफ़ॉर्मेंस में गिरावट

लक्षण: LCP दो सेकंड से बढ़कर 3.5 सेकंड हो गया। मॉनिटरिंग अलर्ट से पता चला।

टाइमलाइन: गिरावट मंगलवार सुबह हुई। टीम ने सोमवार रात नया रिकमेंडेशन इंजन रिलीज़ किया था।

जोड़: इस संयोग से लगता है कि गिरावट रिकमेंडेशन इंजन की वजह से हुई।

अलग करने का टेस्ट: रिकमेंडेशन इंजन बंद करें। LCP वापस दो सेकंड पर आ जाता है। रिकमेंडेशन इंजन ही वजह निकला।

जाँच: रिकमेंडेशन इंजन सुझावों के लिए प्रोडक्ट इमेज लोड करता है। इमेज ऑप्टिमाइज़ नहीं हैं (असली साइज़, कोई कंप्रेशन नहीं)। पचास प्रोडक्ट इमेज लोड करने से पेज में दो मेगाबाइट जुड़ जाते हैं।

फ़िक्स: रिकमेंडेशन इंजन की इमेज ऑप्टिमाइज़ करें। इमेज कंप्रेस करें, फ़ोल्ड के नीचे की इमेज के लिए लेज़ी लोडिंग इस्तेमाल करें। इमेज का साइज़ घटकर पाँच सौ किलोबाइट हो गया। LCP सुधरकर 2.2 सेकंड हो गया।

रोलआउट: रिकमेंडेशन इंजन वापस लें, ऑप्टिमाइज़ किया हुआ वर्शन डिप्लॉय करें। LCP वापस 2.2 सेकंड पर आ जाता है।

परफ़ॉर्मेंस की आम समस्याएँ और हल

समस्या एक: बड़ा JavaScript बंडल

• लक्षण: LCP धीमा, INP धीमा
• वजह: नया फ़ीचर कोड जोड़ता है, बंडल बड़ा हो जाता है
• हल: फ़ीचर का कोड स्प्लिट करें, फ़ीचर लेज़ी लोड करें
• अपेक्षित सुधार: LCP 0.5 सेकंड बेहतर होता है

समस्या दो: धीमी डेटाबेस क्वेरी

• लक्षण: TTFB धीमा
• वजह: डेटाबेस क्वेरी धीमी हो जाती है (इंडेक्स नहीं है, क्वेरी में कई टेबल जुड़ी हैं)
• हल: डेटाबेस इंडेक्स जोड़ें, क्वेरी ऑप्टिमाइज़ करें, नतीजे कैश करें
• अपेक्षित सुधार: TTFB दो सौ मिलीसेकंड बेहतर होता है

समस्या तीन: बिना ऑप्टिमाइज़ की इमेज

• लक्षण: LCP धीमा, बैंडविड्थ ज़्यादा
• वजह: इमेज बड़ी हैं (बिना कंप्रेस, गलत फ़ॉर्मैट)
• हल: इमेज कंप्रेस करें, WebP में बदलें, रेस्पॉन्सिव इमेज इस्तेमाल करें
• अपेक्षित सुधार: LCP एक सेकंड बेहतर होता है

समस्या चार: थर्ड-पार्टी स्क्रिप्ट

• लक्षण: LCP धीमा, पेज जवाब देना बंद कर देता है
• वजह: थर्ड-पार्टी एनालिटिक्स, ट्रैकिंग और विज्ञापन पेज को धीमा कर देते हैं
• हल: थर्ड-पार्टी स्क्रिप्ट लेज़ी लोड करें, web worker इस्तेमाल करें, एसिंक्रोनस लोड करें
• अपेक्षित सुधार: LCP 0.5 सेकंड और INP सौ मिलीसेकंड बेहतर होता है

समस्या पाँच: विज्ञापन या एम्बेड से CLS

• लक्षण: पढ़ते समय लेआउट खिसकता है
• वजह: विज्ञापन लोड होकर जगह घेरते हैं, कंटेंट खिसक जाता है
• हल: विज्ञापनों के लिए जगह रिज़र्व करें, फ़ोल्ड के नीचे के विज्ञापन लेज़ी लोड करें
• अपेक्षित सुधार: CLS 0.2 से सुधरकर 0.05 हो जाता है

जल्दी पकड़ने के लिए मॉनिटरिंग

गिरावट पर अलर्ट: अगर LCP 2.5 सेकंड से ऊपर जाए, तो टीम को अलर्ट करें।

रिग्रेशन पर अलर्ट: अगर LCP शुरुआती वैल्यू से 0.5 सेकंड से ज़्यादा बढ़े, तो टीम को अलर्ट करें।

बिज़नेस असर पर अलर्ट: अगर साइन-अप पूरा होना एक प्रतिशत घटे, तो टीम को अलर्ट करें (यह परफ़ॉर्मेंस की समस्या का संकेत हो सकता है)।

असली उदाहरण: एक SaaS कंपनी के अलर्ट

• अलर्ट एक: अगर LCP 2.5 सेकंड से ऊपर जाए
• अलर्ट दो: अगर परफ़ॉर्मेंस रिग्रेशन मिले (एक दिन में LCP पचास प्रतिशत बढ़े)
• अलर्ट तीन: अगर पाँच प्रतिशत से ज़्यादा यूज़र्स के लिए Core Web Vitals अच्छे से सुधार-ज़रूरी में चले जाएँ
• अलर्ट चार: अगर साइन-अप पूरा होना लक्ष्य से नीचे जाए (यह चेकआउट पेज की परफ़ॉर्मेंस की समस्या का संकेत हो सकता है)

अलर्ट आने पर: इंजीनियरिंग टीम एक घंटे के भीतर जाँच करती है। असली वजह पहचानी जाती है। फ़िक्स उसी दिन डिप्लॉय होता है।

असली उदाहरण: पेमेंट प्रोसेसिंग की परफ़ॉर्मेंस समस्या

लक्षण: चेकआउट छोड़ने की दर पंद्रह प्रतिशत से बढ़कर पच्चीस प्रतिशत हो गई। यह गुरुवार से शुरू हुई।

जाँच: चेकआउट पेज की परफ़ॉर्मेंस गिरी। पेमेंट प्रोसेसिंग बटन का इंटरैक्शन टाइम दो सौ मिलीसेकंड से बढ़कर एक सेकंड हो गया।

टाइमलाइन: पेमेंट प्रोसेसर ने गुरुवार सुबह इन्फ़्रास्ट्रक्चर में बदलाव किया।

असली वजह: पेमेंट प्रोसेसर कैलिफ़ोर्निया से यूरोप चला गया। यूज़र से पेमेंट प्रोसेसर तक नेटवर्क लेटेंसी दो सौ मिलीसेकंड बढ़ गई। कुल पेमेंट प्रोसेसिंग टाइम एक सेकंड हो गया।

हल: यूज़र के पास का CDN एज लोकेशन इस्तेमाल करें। पेमेंट रिक्वेस्ट को लोकल CDN एज से भेजें। CDN एज उसे यूरोप के पेमेंट प्रोसेसर तक पहुँचाता है। नेटवर्क लेटेंसी घटती है। पेमेंट प्रोसेसिंग टाइम वापस दो सौ मिलीसेकंड हो जाता है।

नतीजा: चेकआउट छोड़ने की दर वापस पंद्रह प्रतिशत पर आ जाती है।

बिज़नेस असर: महीने के पाँच हज़ार चेकआउट पर पंद्रह प्रतिशत छोड़ने की दर का मतलब सात सौ पचास नाकाम कन्वर्ज़न। सौ डॉलर की ऑर्डर वैल्यू पर यह हर महीने पचहत्तर हज़ार डॉलर का नुकसान है। लेटेंसी की समस्या ठीक करने से कंपनी के हर महीने पचहत्तर हज़ार डॉलर बचे।

अक्सर पूछे जाने वाले सवाल