वेबपेज की परफ़ॉर्मेंस पर कई बातों का असर पड़ता है. वेब और नेटवर्क टेक्नोलॉजी में अंतर की वजह से, लाइटहाउस परफ़ॉर्मेंस स्कोर में बदलाव होता है. भले ही, पेज में कोई बदलाव न हुआ हो.
बदलाव के सोर्स
परफ़ॉर्मेंस मेज़रमेंट में बदलाव, असर के अलग-अलग लेवल वाले कई चैनलों से मिलता है. नीचे एक टेबल दी गई है, जिसमें मेट्रिक में हुए उतार-चढ़ाव के कई सामान्य सोर्स, नतीजों पर उनका सामान्य असर, और अलग-अलग एनवायरमेंट में होने की कितनी संभावना है.
| सोर्स | असर | सामान्य असली उपयोगकर्ता | PageSpeed Insights | नियंत्रित लैब |
|---|---|---|---|---|
| पेज नॉन-डेटर्मिनिज़्म | ज़्यादा | शायद | शायद | शायद |
| लोकल नेटवर्क वैरिएबिलिटी | ज़्यादा | शायद | असामान्य | असामान्य |
| टियर-1 नेटवर्क में हुए बदलाव | मीडियम | संभावित | संभावित | संभावित |
| वेब सर्वर वैरिएबिलिटी | खराब | शायद | शायद | शायद |
| क्लाइंट हार्डवेयर वैरिएबिलिटी | ज़्यादा | शायद | असामान्य | असामान्य |
| क्लाइंट के संसाधन का विवाद | ज़्यादा | शायद | संभावित | असामान्य |
| ब्राउज़र का पता न लगाने का तरीका | मीडियम | कुछ | कुछ | कुछ |
यहां वैरियंस के सोर्स और लाइटहाउस रनटाइम और एनवायरमेंट के कॉम्बिनेशन पर होने वाले असर के बारे में ज़्यादा जानकारी दी गई है. इनमें से किसी भी तरीके में, लागू की गई थ्रॉटलिंग और सिम्युलेटेड थ्रॉटलिंग का इस्तेमाल किया जा सकता है. हालांकि, आम तौर पर असली उपयोगकर्ता, सिम्युलेटेड थ्रॉटलिंग का इस्तेमाल करते हैं.
पेज अनिश्चितता
पेज में ऐसा लॉजिक हो सकता है जो तय नहीं हो सकता.इससे उपयोगकर्ता के पेज देखने का तरीका बदल जाता है. जैसे, A/B टेस्ट, जो लोड होने वाले लेआउट और एसेट या कैंपेन की प्रोग्रेस के आधार पर अलग विज्ञापन अनुभव को बदलता है. यह वैरिएंस का एक जान-बूझकर और न हटाया जा सकने वाला सोर्स है. अगर पेज इस तरह से बदलता है जिससे परफ़ॉर्मेंस पर बुरा असर पड़ता है, तो Lighthouse को इस मामले की पहचान करनी चाहिए. साइट के मालिक को बस यह पक्का करना होगा कि पेज के एक जैसे वर्शन की अलग-अलग बार जांच की जा रही है.
लोकल नेटवर्क वैरिएबिलिटी
लोकल नेटवर्क में पैकेट लॉस, वैरिएबल ट्रैफ़िक की प्राथमिकता, और लास्ट-मील नेटवर्क के कंजेशन की वजह से, पहले से ही डेटा में फ़र्क़ होता है. सस्ते राऊटर और सीमित बैंडविड्थ वाले डिवाइसों का इस्तेमाल करने वाले लोगों में इस समस्या का सबसे ज़्यादा खतरा होता है. लागू की गई थ्रॉटलिंग से इन इफ़ेक्ट को कुछ हद तक कम किया जाता है. ऐसा, अनुरोध के लिए इंतज़ार का समय और ज़्यादा से ज़्यादा डेटा लागू करके किया जाता है. इससे, बार-बार की जाने वाली कोशिशों को मास्क किया जा सकता है. सिम्युलेटेड थ्रॉटल की सुविधा, नेटवर्क गतिविधि को फिर से चलाकर, इन इफ़ेक्ट को कम करती है.
टियर-1 नेटवर्क में उतार-चढ़ाव
आम तौर पर, नेटवर्क इंटरकनेक्ट काफ़ी स्थिर होते हैं और इनका असर कम होता है. हालांकि, क्रॉस-जियो अनुरोधों में, टीयर-1 नेटवर्क होने की वजह से, चीन की किसी साइट की परफ़ॉर्मेंस को मेज़र करने में, टीयर 1 नेटवर्क होने में काफ़ी समय लग सकता है. लागू की गई थ्रॉटलिंग से, नेटवर्क थ्रॉटलिंग की मदद से इन इफ़ेक्ट को कुछ हद तक मास्क किया जाता है. सिम्युलेटेड थ्रॉटल की सुविधा, नेटवर्क गतिविधि को फिर से चलाकर, इन इफ़ेक्ट को कम करती है.
वेब सर्वर वैरिएबिलिटी
वेब सर्वर की लोड अलग-अलग होती है और वे हमेशा समान देरी से जवाब नहीं देते. शेयर किए गए होस्टिंग इन्फ़्रास्ट्रक्चर वाली कम ट्रैफ़िक वाली साइटों में, आम तौर पर इस बात का ज़्यादा खतरा होता है. लागू की गई थ्रॉटल की सुविधा, नेटवर्क थ्रॉटलिंग के दौरान इन इफ़ेक्ट को कुछ हद तक छिपा देती है. ऐसा करने के लिए, अनुरोध के इंतज़ार का कम से कम समय लागू किया जाता है. सिम्युलेटेड थ्रॉटलिंग पर इसका असर ज़्यादा हो सकता है. हालांकि, नेटवर्क में हुए दूसरे बदलाव की तुलना में, आम तौर पर इसका असर कम होता है.
क्लाइंट हार्डवेयर वैरिएबिलिटी
जिस हार्डवेयर पर वेब पेज लोड हो रहा है उसकी परफ़ॉर्मेंस पर काफ़ी ज़्यादा असर पड़ सकता है. लागू की गई थ्रॉटलिंग से, इस समस्या को कम नहीं किया जा सकता. सिम्युलेटेड थ्रॉटलिंग से इस समस्या को कुछ हद तक कम किया जा सकता है. इसके लिए, सिम्युलेशन के दौरान सीपीयू टास्क के सैद्धांतिक तौर पर एक्ज़ीक्यूशन के समय की सीमा तय की जाती है.
क्लाइंट रिसॉर्स का विवाद
लाइटहाउस के चलने के दौरान, उसी मशीन पर चल रहे दूसरे ऐप्लिकेशन से सीपीयू, मेमोरी, और नेटवर्क संसाधनों पर विवाद हो सकता है. मैलवेयर, ब्राउज़र एक्सटेंशन, और एंटी-वायरस सॉफ़्टवेयर का वेब परफ़ॉर्मेंस पर खास तौर पर गहरा असर पड़ता है. कई टेनेंट सर्वर एनवायरमेंट (जैसे कि Travis, AWS वगैरह) को भी इन समस्याओं का सामना करना पड़ सकता है. एक बार में Lighthouse के कई इंस्टेंस चलाने से, आम तौर पर इस समस्या की वजह से नतीजे बिगड़ जाते हैं. यह समस्या लागू किए जाने पर, थ्रॉटलिंग पर ज़्यादा असर पड़ सकता है. सिम्युलेटेड थ्रॉटल की सुविधा, नेटवर्क गतिविधि को फिर से चलाए जाने और सीपीयू एक्ज़ीक्यूशन की सीमा तय करके, इस समस्या को कुछ हद तक कम करती है.
ब्राउज़र का समय तय नहीं है
ब्राउज़र के काम करने के तरीके में पहले से बदलाव होता है. इसका असर वेबपेजों के लोड होने के तरीके पर पड़ता है. लागू की गई थ्रॉटलिंग के लिए इससे बचा नहीं जा सकता, क्योंकि दिन के आखिर में वे सिर्फ़ ब्राउज़र में देखी गई जानकारी की रिपोर्ट कर रहे होते हैं. सिम्युलेटेड थ्रॉटलिंग, अपने-आप एक्ज़ीक्यूशन को सिम्युलेट करके इस इफ़ेक्ट को कुछ हद तक कम कर सकता है. इसके लिए, ब्राउज़र से टास्क के चलने में लगने वाले समय का फिर से इस्तेमाल किया जाता है.
थ्रॉटलिंग की रणनीतियों का असर
नीचे एक टेबल दी गई है, जिसमें मेट्रिक में हुए उतार-चढ़ाव के कई सामान्य सोर्स दिए गए हैं. साथ ही, इसमें यह भी बताया गया है कि नतीजों पर इनका सामान्य तौर पर क्या असर पड़ता है. साथ ही, इसमें यह भी बताया गया है कि Lighthouse थ्रॉटलिंग की अलग-अलग रणनीतियां, अपने असर को किस हद तक कम कर सकती हैं. हमारे थ्रॉटलिंग दस्तावेज़ में, थ्रॉटलिंग की अलग-अलग रणनीतियों के बारे में ज़्यादा जानें.
| सोर्स | असर | सिम्युलेटेड थ्रॉटलिंग | लागू की गई थ्रॉटलिंग | कोई थ्रॉटलिंग नहीं |
|---|---|---|---|---|
| पेज नॉन-डेटर्मिनिज़्म | ज़्यादा | कोई छूट नहीं | कोई छूट नहीं | कोई छूट नहीं |
| लोकल नेटवर्क वैरिएबिलिटी | ज़्यादा | कम किया गया | आंशिक रूप से कम किया गया | कोई छूट नहीं |
| टियर-1 नेटवर्क में हुए बदलाव | मीडियम | कम किया गया | आंशिक रूप से कम किया गया | कोई छूट नहीं |
| वेब सर्वर वैरिएबिलिटी | खराब | कोई छूट नहीं | आंशिक रूप से कम किया गया | कोई छूट नहीं |
| क्लाइंट हार्डवेयर वैरिएबिलिटी | ज़्यादा | आंशिक रूप से कम किया गया | कोई छूट नहीं | कोई छूट नहीं |
| क्लाइंट के संसाधन का विवाद | ज़्यादा | आंशिक रूप से कम किया गया | कोई छूट नहीं | कोई छूट नहीं |
| ब्राउज़र का पता न लगाने का तरीका | मीडियम | आंशिक रूप से कम किया गया | कोई छूट नहीं | कोई छूट नहीं |
वैरिएंस से निपटने के लिए रणनीतियां
बाहरी फ़ैक्टर को अलग करें
- जितना हो सके, अपने पेज को तीसरे पक्ष के असर से अलग रखें. किसी और की बदलती असफलताओं के लिए दोषी ठहराना कभी मज़ेदार नहीं होता.
- टेस्टिंग के दौरान, अपने कोड की नॉन-डेटर्मिनिज़म को अलग रखें. अगर आपको कोई ऐनिमेशन दिख रहा है, जो बिना किसी क्रम के दिख रहा है, तो हो सकता है कि आपकी परफ़ॉर्मेंस के आंकड़े अनियमित हों!
- अपने टेस्ट सर्वर को, जितना हो सके उतने नेटवर्क के उतार-चढ़ाव से अलग रखें. स्थिरता को लेकर कोई समस्या होने पर, localhost या समान नेटवर्क पर किसी मशीन का इस्तेमाल करें.
- अपने क्लाइंट एनवायरमेंट को एंटी-वायरस सॉफ़्टवेयर और ब्राउज़र एक्सटेंशन जैसे बाहरी फ़ैक्टर से अलग करें. जब भी संभव हो, टेस्ट के लिए किसी खास डिवाइस का इस्तेमाल करें.
अगर आपकी मशीन में सीमित संसाधन हैं या स्वच्छ वातावरण बनाना मुश्किल हो गया है, तो जांच करने के लिए PageSpeed Insights या WebPageTest जैसे होस्ट किए गए लैब एनवायरमेंट का इस्तेमाल करें. लगातार इंटिग्रेशन की स्थितियों में, जहां तक हो सके समर्पित सर्वर का इस्तेमाल करें. फ़्री सीआई एनवायरमेंट और "बर्स्ट होने वाले" इंस्टेंस में आम तौर पर उतार-चढ़ाव होता है.
लाइटहाउस को कई बार चलाएं
मानसिक या प्रोग्राम के हिसाब से, अपने-आप होने वाली गड़बड़ियों की मेट्रिक बनाते समय, एग्रीगेट वैल्यू का इस्तेमाल करें. जैसे- मीडियन, 90वां पर्सेंटाइल या यहां तक कि एक टेस्ट के बजाय, मिनट की वैल्यू का भी इस्तेमाल करें.
पांच रन का मीडियन लाइटहाउस स्कोर, एक रन के मुकाबले दोगुना है. साथ ही, pwmetric जैसे टूल आपके लिए अपने-आप Lighthouse चला सकते हैं. टेस्टिंग न करने की तुलना में, सबसे कम वैल्यू का इस्तेमाल करना भी एक बड़ा सुधार है. इसे लागू करना बहुत आसान है. Lighthouse को तब तक पांच बार तक चलाएं, जब तक इसे टेस्ट नहीं किया जाता!