अपनी वेबसाइट का ऑडिट करने, उसे बेहतर बनाने, और उस पर असरदार तरीके से नज़र रखने के लिए, Google के टूल को एक साथ इस्तेमाल करें.
पब्लिश होने की तारीख: 28 मई, 2020
Core Web Vitals, मेट्रिक का एक सेट है. इसमें पेज के लोड होने, उपयोगकर्ता के इनपुट पर रिस्पॉन्स करने, और लेआउट की स्थिरता जैसी ज़रूरी शर्तों के आधार पर, उपयोगकर्ता अनुभव का आकलन किया जाता है.
इस गाइड में, आपकी वेबसाइट के लिए Core Web Vitals को बेहतर बनाने के वर्कफ़्लो के बारे में बताया जाएगा. हालांकि, यह वर्कफ़्लो कहां से शुरू होगा, यह इस बात पर निर्भर करता है कि फ़ील्ड डेटा इकट्ठा किया जा रहा है या नहीं. यह इस बात पर निर्भर करता है कि उपयोगकर्ता अनुभव से जुड़ी समस्याओं का पता लगाने और उन्हें ठीक करने के लिए, आपको Google के कौनसे टूल काम के लगते हैं.
Core Web Vitals को फ़ील्ड में सबसे अच्छी तरह से मेज़र किया जाता है
Core Web Vitals को खास तौर पर यह मेज़र करने के लिए डिज़ाइन किया गया है कि उपयोगकर्ताओं को आपकी वेबसाइट पर कैसा अनुभव मिलता है. ये उपयोगकर्ता पर आधारित मेट्रिक होती हैं. Lighthouse जैसे लैब-आधारित टूल, डाइग्नोस्टिक टूल होते हैं. इनसे परफ़ॉर्मेंस से जुड़ी संभावित समस्याओं और सबसे सही तरीकों को हाइलाइट किया जाता है. लैब-आधारित टूल, पहले से तय की गई कुछ शर्तों के तहत चलाए जाते हैं. ऐसा हो सकता है कि ये टूल, Core Web Vitals के उन असल मेज़रमेंट को न दिखाएं जो आपके उपयोगकर्ताओं को मिलते हैं.
उदाहरण के लिए, Lighthouse एक लैब-आधारित टूल है. यह सिम्युलेट किए गए डेस्कटॉप या मोबाइल एनवायरमेंट में, सिम्युलेट किए गए थ्रॉटलिंग के साथ टेस्ट चलाता है. परफ़ॉर्मेंस से जुड़ी समस्याओं का पता लगाने के लिए, धीमे नेटवर्क और डिवाइस की स्थितियों के ऐसे सिम्युलेशन मददगार होते हैं. हालांकि, ये नेटवर्क की स्थितियों और डिवाइस की क्षमताओं की बड़ी रेंज का सिर्फ़ एक हिस्सा होते हैं. इसलिए, हो सकता है कि ये आपकी साइटों पर उपयोगकर्ताओं को मिलने वाले अनुभव को न दिखाएं.
Lighthouse जैसे लैब-आधारित टूल भी आम तौर पर, किसी वेब पेज को "कोल्ड लोड" करते हैं. ऐसा इसलिए, क्योंकि वे उस पेज पर पहली बार आने वाले विज़िटर की तरह काम करते हैं. आम तौर पर, यह सबसे धीमी गति से लोड होता है. हालांकि, असल ज़िंदगी में, अगर विज़िटर पहले भी साइट पर आ चुके हैं या साइट पर ब्राउज़ कर रहे हैं, तो हो सकता है कि उनके पास कुछ एसेट कैश मेमोरी में सेव हों. नए विज़िटर और टूल को भी साइट का अनुभव अलग तरह से मिल सकता है. ऐसा कुकी बैनर या अन्य कॉन्टेंट की वजह से हो सकता है.
संक्षेप में, लैब-आधारित टूल, परफ़ॉर्मेंस से जुड़ी संभावित समस्याओं का संकेत दे सकते हैं. साथ ही, डीबग करने और दोहराने में आपकी मदद कर सकते हैं. हालांकि, हो सकता है कि वे यह न दिखाएं कि आपकी वेबसाइट पर आने वाले कितने लोग असल में आपकी वेबसाइट का अनुभव करते हैं. असल दुनिया में परफ़ॉर्मेंस को मेज़र करने के लिए, फ़ील्ड डेटा का इस्तेमाल करें. साथ ही, परफ़ॉर्मेंस को बेहतर बनाने के तरीके जानने के लिए, Lighthouse जैसे लैब-आधारित टूल का इस्तेमाल करें. Lighthouse का इस्तेमाल कब करना चाहिए सेक्शन भी देखें.
Google, Chrome के लिए उपयोगकर्ता अनुभव से जुड़ी रिपोर्ट (CrUX) की मदद से, Core Web Vitals को मेज़र करता है. यह एक सार्वजनिक डेटासेट है, जिसे Chrome के असली उपयोगकर्ताओं से इकट्ठा किया जाता है. यह Google और तीसरे पक्ष के कई टूल का मुख्य हिस्सा है. ये टूल, किसी साइट के Core Web Vitals की रिपोर्ट देते हैं.
हालांकि, CrUX की कुछ सीमाएं हैं. यह अक्सर आपको बता सकता है कि समस्या कब हुई, लेकिन इसके पास अक्सर यह बताने के लिए ज़रूरत के मुताबिक डेटा नहीं होता कि समस्या क्यों हुई.
अगर हो सके, तो अपना फ़ील्ड डेटा खुद इकट्ठा करें
वेबसाइट की परफ़ॉर्मेंस को बेहतर बनाने के लिए, सबसे अच्छा डेटासेट वह होता है जिसे आपने बनाया हो. इसकी शुरुआत, आपकी वेबसाइट पर आने वाले लोगों से फ़ील्ड डेटा इकट्ठा करने से होती है. सहमति लेने का तरीका, आपके संगठन के साइज़ पर निर्भर करता है. साथ ही, इस बात पर भी निर्भर करता है कि आपको तीसरे पक्ष के समाधान के लिए पैसे चुकाने हैं या खुद का समाधान बनाना है.
पैसे चुकाकर इस्तेमाल किए जाने वाले समाधान, Core Web Vitals और अन्य परफ़ॉर्मेंस मेट्रिक को ज़रूर मेज़र करेंगे. साथ ही, आम तौर पर ये समाधान, नतीजे के तौर पर मिलने वाले डेटा को गहराई से समझने के लिए कई तरह के टूल उपलब्ध कराते हैं. जिन बड़े संगठनों के पास काफ़ी संसाधन होते हैं वे इस तरीके को प्राथमिकता दे सकते हैं.
हालांकि, हो सकता है कि आप किसी बड़े संगठन का हिस्सा न हों या आपके पास तीसरे पक्ष के समाधान का खर्च उठाने के लिए ज़रूरी संसाधन न हों. ऐसे मामलों में, Google की web-vitals लाइब्रेरी की मदद से, सभी वेब वाइटल इकट्ठा किए जा सकते हैं. हालांकि, उस डेटा को रिपोर्ट करने, सेव करने, और उसका विश्लेषण करने की ज़िम्मेदारी आपकी होगी.
अगर पहले से ही Google Analytics का इस्तेमाल किया जा रहा है, लेकिन आपने अब तक फ़ील्ड डेटा इकट्ठा करना शुरू नहीं किया है, तो आपके पास web-vitals लाइब्रेरी का इस्तेमाल करके, फ़ील्ड में इकट्ठा किए गए Web Vitals को Google Analytics में भेजने का विकल्प है. साथ ही, डेटा की रिपोर्ट करने के लिए, GA4 के BigQuery Export का इस्तेमाल किया जा सकता है.
Google के टूल के बारे में जानकारी
भले ही, आपने अपना फ़ील्ड डेटा इकट्ठा किया हो या नहीं, Google के कई ऐसे टूल हैं जो Core Web Vitals का विश्लेषण करने में मददगार साबित हो सकते हैं. वर्कफ़्लो बनाने से पहले, हर टूल के बारे में खास जानकारी पाने से आपको यह समझने में मदद मिल सकती है कि कौनसे टूल आपके लिए सबसे सही हो सकते हैं और कौनसे नहीं.
Chrome के लिए उपयोगकर्ता अनुभव से जुड़ी रिपोर्ट (CrUX)
जैसा कि पहले बताया गया है, CrUX एक सार्वजनिक डेटासेट है. इसमें लाखों वेबसाइटों से, Google Chrome के असल उपयोगकर्ताओं के एक सेगमेंट से इकट्ठा किया गया फ़ील्ड डेटा शामिल होता है. इसमें Core Web Vitals मेट्रिक और अन्य मेट्रिक शामिल होती हैं. ये मेट्रिक उन वेबसाइटों के लिए होती हैं जिन पर ज़रूरत के मुताबिक ट्रैफ़िक आता है.
CrUX, ओरिजिन लेवल पर हर महीने BigQuery डेटासेट के तौर पर उपलब्ध होता है. इसके अलावा, यह यूआरएल या ओरिजिन लेवल पर रोज़ाना एपीआई के तौर पर भी उपलब्ध होता है. हालांकि, इसके लिए ज़रूरी है कि CrUX डेटासेट में यूआरएल या ओरिजिन के लिए ज़रूरत के मुताबिक सैंपल मौजूद हों. CrUX डेटा, CrUX के अलग-अलग टूल के ज़रिए उपलब्ध होता है. इससे प्रोग्राम के हिसाब से ऐक्सेस और विज़ुअल टूल, दोनों का इस्तेमाल किया जा सकता है.
CrUX का इस्तेमाल कब करना चाहिए
अगर आपके पास अपना फ़ील्ड डेटा है, तब भी CrUX आपके काम का है. भले ही, CrUX में Chrome के उपयोगकर्ताओं का एक सबसेट शामिल होता है, लेकिन अपनी वेबसाइट के फ़ील्ड डेटा की तुलना करके यह देखा जा सकता है कि वह CrUX डेटा के साथ कैसे अलाइन होता है. दोनों के अपने फ़ायदे और नुकसान हैं. इस वजह से, दोनों के नतीजों में अंतर हो सकता है. अगर आपकी वेबसाइट के लिए कोई भी फ़ील्ड डेटा इकट्ठा नहीं किया जाता है, तो CrUX खास तौर पर अहम जानकारी देने के लिए काफ़ी मददगार होता है. हालांकि, इसके लिए ज़रूरी है कि आपकी वेबसाइट का डेटासेट मौजूद हो.
CrUX का इस्तेमाल सीधे तौर पर किया जा सकता है. इसके अलावा, किसी दूसरे टूल का इस्तेमाल भी किया जा सकता है. इनमें नीचे दिए गए टूल भी शामिल हैं. BigQuery या एपीआई का इस्तेमाल करके, CrUX डेटासेट का सीधे तौर पर इस्तेमाल करना, ऐसे डेटा को दिखाने के लिए मददगार होता है जो अन्य टूल में नहीं दिखता. उदाहरण के लिए, देश के लेवल का डेटा अक्सर अन्य टूल पर उपलब्ध नहीं होता या CrUX में अतिरिक्त मेट्रिक देखने के लिए, जो अक्सर अन्य टूल में नहीं दिखती हैं.
CrUX का इस्तेमाल कब नहीं करना चाहिए
CrUX में सिर्फ़ Chrome उपयोगकर्ताओं का डेटा शामिल होता है. इसमें भी Chrome उपयोगकर्ताओं के सिर्फ़ एक सबसेट का डेटा शामिल होता है. आरयूएम के पूरे समाधान में, Chrome और अन्य ब्राउज़र पर ज़्यादा अनुभव शामिल हो सकते हैं. इन ब्राउज़र पर, Web Vitals मेट्रिक काम करती हैं.
जिन वेबसाइटों को ज़रूरत के मुताबिक ट्रैफ़िक नहीं मिलता उन्हें CrUX डेटासेट में शामिल नहीं किया जाता. अगर आपके साथ ऐसा होता है, तो आपको खुद ही फ़ील्ड डेटा इकट्ठा करना होगा. इससे आपको यह समझने में मदद मिलेगी कि आपकी वेबसाइट, फ़ील्ड में कैसा परफ़ॉर्म करती है. ऐसा इसलिए, क्योंकि CrUX का विकल्प उपलब्ध नहीं होगा. इसके अलावा, आपको लैब डेटा पर निर्भर रहना होगा. हालांकि, इसकी कुछ सीमाएं हैं. जैसे, हो सकता है कि यह डेटा, पहले बताए गए तरीके से काम न करे.
CrUX से मिलने वाला डेटा, पिछले 28 दिनों का रोलिंग औसत होता है. इसलिए, डेवलपमेंट के दौरान यह एक सही टूल नहीं है. ऐसा इसलिए, क्योंकि CrUX डेटासेट में सुधार दिखने में काफ़ी समय लगेगा.
आखिर में, सार्वजनिक डेटासेट के तौर पर, CrUX में यह तय होता है कि वह कितनी जानकारी उपलब्ध करा सकता है और इस डेटा के लिए क्वेरी कैसे की जा सकती है. आरयूएम डेटा कैप्चर करने से, आपको ज़्यादा जानकारी इकट्ठा करने में मदद मिलती है. जैसे, एलसीपी एलिमेंट. साथ ही, समस्याओं की पहचान करने के लिए, डेटा को ज़्यादा सेगमेंट में बांटा जा सकता है. क्या लॉग इन किए हुए उपयोगकर्ताओं को, लॉग आउट किए हुए उपयोगकर्ताओं की तुलना में, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली रिपोर्ट बेहतर या खराब मिलती है? क्या धीमे एलसीपी वाले उपयोगकर्ताओं के पास कोई खास एलसीपी एलिमेंट है? किन इंटरैक्शन की वजह से एफ़आईडी और आईएनपी की वैल्यू ज़्यादा हो रही हैं?
PageSpeed Insights (PSI)
PSI एक ऐसा टूल है जो किसी पेज के लिए, CrUX से फ़ील्ड डेटा और Lighthouse से लैब डेटा दिखाता है. ज़्यादा जानकारी के लिए, उन सेक्शन को देखें.
पीएसआई का इस्तेमाल कब करना चाहिए
PSI, मोबाइल और डेस्कटॉप, दोनों तरह के उपयोगकर्ताओं के लिए, पेज लेवल या ऑरिजिन-लेवल पर CrUX की परफ़ॉर्मेंस का आकलन करने के लिए बेहतरीन टूल है. यह किसी पेज या साइट के लिए, Core Web Vitals की शुरुआती खास जानकारी पाने का एक अच्छा विकल्प है. इसकी मदद से, प्रतिस्पर्धियों जैसी अन्य साइटों के लिए, Core Web Vitals का डेटा भी देखा जा सकता है.
PSI, Lighthouse का डेटा भी उपलब्ध कराता है. इससे आपको Core Web Vitals को बेहतर बनाने के लिए काम के सुझाव मिलते हैं. हालांकि, ऐसा तब होता है, जब मेट्रिक अलाइन हों. अगर ये दोनों अलाइन नहीं हैं, तो हो सकता है कि Lighthouse के सुझाव आपके काम के न हों.
Lighthouse को सर्वर से चलाया जाता है. इसलिए, DevTools से Lighthouse चलाने की तुलना में, यह ज़्यादा बेहतर बेसलाइन बना सकता है.
कब पीएसआई का इस्तेमाल नहीं करना चाहिए
पीएसआई सिर्फ़ सार्वजनिक यूआरएल के लिए उपलब्ध है. इसका इस्तेमाल ऐसी डेवलपमेंट साइटों पर नहीं किया जा सकता जिन्हें सार्वजनिक तौर पर ऐक्सेस नहीं किया जा सकता.
CrUX डेटा सिर्फ़ तब उपलब्ध होता है, जब साइटें ज़रूरी शर्तें पूरी करती हों. इनमें साइट की लोकप्रियता से जुड़ी थ्रेशोल्ड भी शामिल हैं. अगर किसी पेज या ऑरिजिन के लिए CrUX डेटा उपलब्ध नहीं है, तो PSI का इस्तेमाल करना ज़्यादा फ़ायदेमंद नहीं होता. इसकी वजह यह है कि ऐसे मामलों में, यह सिर्फ़ Lighthouse लैब डेटा दिखा सकता है.
इसी तरह, अगर आपके पास टेस्ट किए जा रहे यूआरएल के बजाय, सिर्फ़ ऑरिजिन-लेवल का CrUX डेटा है, तो ऑरिजिन-लेवल के फ़ील्ड डेटा को पेज-लेवल के लैब डाइग्नोस्टिक्स से जोड़ने की इसकी क्षमता भी सीमित हो जाती है. साइट की परफ़ॉर्मेंस की खास जानकारी के तौर पर, ऑरिजिन-लेवल का फ़ील्ड डेटा होना अब भी बहुत काम की जानकारी है. साथ ही, Lighthouse ऑडिट से मदद मिल सकती है. हालांकि, इस मामले में ज़्यादा सावधानी बरतनी चाहिए.
आखिर में, अगर CrUX में पेज-लेवल का डेटा उपलब्ध है, लेकिन वह Lighthouse लैब के डेटा से अलग है, तो हो सकता है कि Lighthouse के सुझावों की वैल्यू सीमित हो. ऐसा खास तौर पर, पेज लोड होने के बाद सीएलएस से जुड़ी समस्याओं और इंटरैक्टिविटी से जुड़े Core Web Vitals (एफ़आईडी और आईएनपी) के लिए हो सकता है. इनमें लैब पर आधारित ऑडिट कम काम के होते हैं.
Search Console
Search Console आपकी साइट के खोज ट्रैफ़िक और परफ़ॉर्मेंस को मेज़र करता है. इसमें Core Web Vitals भी शामिल है. यह सिर्फ़ उन साइट मालिकों के लिए उपलब्ध है जिन्होंने साइट के मालिकाना हक की पुष्टि की है.
Search Console की एक अहम सुविधा यह है कि यह एक जैसे पेजों (उदाहरण के लिए, एक ही टेंप्लेट का इस्तेमाल करने वाले पेज) को एक ग्रुप में रखता है. इससे उन सभी पेजों का आकलन एक साथ किया जा सकता है. Search Console में, Core Web Vitals रिपोर्ट भी शामिल होती है. यह रिपोर्ट, CrUX के फ़ील्ड डेटा पर आधारित होती है.
Search Console का इस्तेमाल कब करना चाहिए
Search Console, डेवलपर और बिना डेवलपर की भूमिका वाले लोगों, दोनों के लिए सही है. इसकी मदद से, खोज और पेज की परफ़ॉर्मेंस का आकलन उन तरीकों से किया जा सकता है जो Google के अन्य टूल में नहीं किए जा सकते. यह CrUX डेटा को दिखाता है और एक जैसे पेजों को ग्रुप में बांटता है. इससे यह अहम जानकारी मिलती है कि परफ़ॉर्मेंस में सुधार होने से, पेजों की सभी कैटगरी पर क्या असर पड़ता है.
Search Console का इस्तेमाल कब नहीं करना चाहिए
Search Console उन प्रोजेक्ट के लिए सही नहीं हो सकता जो तीसरे पक्ष के अलग-अलग टूल इस्तेमाल करते हैं. ये टूल, पेजों को उनकी समानता के आधार पर ग्रुप करते हैं. इसके अलावा, अगर कोई वेबसाइट CrUX डेटासेट में मौजूद नहीं है, तो भी Search Console सही नहीं हो सकता.
पेज ग्रुपिंग की सुविधा से कभी-कभी भ्रम भी हो सकता है. ऐसा तब होता है, जब किसी ग्रुप में मौजूद उदाहरण के तौर पर दिए गए पेजों की विशेषताएं, ग्रुप के बाकी पेजों से अलग हों. उदाहरण के लिए, अगर ग्रुप के सभी पेज, Core Web Vitals की किसी खास मेट्रिक के लिए तय की गई शर्तों को पूरा नहीं करते हैं, लेकिन उदाहरण के तौर पर दिए गए सभी पेज, Core Web Vitals की उसी मेट्रिक के लिए तय की गई शर्तों को पूरा करते हैं. ऐसा तब हो सकता है, जब किसी ग्रुप में लॉन्ग टेल या कम विज़िट किए गए पेज शामिल हों. ऐसे पेजों को लोड होने में ज़्यादा समय लग सकता है, क्योंकि उन्हें कैश मेमोरी में सेव किए जाने की संभावना कम होती है. जब लॉन्ग टेल में इन पेजों की संख्या काफ़ी ज़्यादा होती है, तो ये ग्रुप के पास होने की कुल दर पर असर डाल सकते हैं.
लाइटहाउस
Lighthouse एक लैब टूल है. यह पेज की परफ़ॉर्मेंस को बेहतर बनाने के लिए खास सुझाव देता है. Lighthouse यूज़र फ़्लो की मदद से, डेवलपर इंटरैक्शन फ़्लो के लिए स्क्रिप्ट भी लिख सकते हैं. इससे पेज लोड होने के अलावा, अन्य परफ़ॉर्मेंस की जांच की जा सकती है.
Lighthouse-CI इससे जुड़ा एक टूल है. यह प्रोजेक्ट बिल्ड और डिप्लॉय के दौरान Lighthouse को चलाता है, ताकि परफ़ॉर्मेंस रिग्रेशन टेस्टिंग में मदद मिल सके. यह पुल रिक्वेस्ट के साथ-साथ Lighthouse रिपोर्ट दिखाता है. साथ ही, समय के साथ परफ़ॉर्मेंस मेट्रिक को ट्रैक करता है.
Lighthouse का इस्तेमाल कब करना चाहिए
Lighthouse, लोकल और स्टेजिंग, दोनों एनवायरमेंट में डेवलपमेंट के दौरान परफ़ॉर्मेंस को बेहतर बनाने के अवसर ढूंढने के लिए बेहतरीन टूल है. Lighthouse CI, स्टेजिंग और प्रोडक्शन एनवायरमेंट में बिल्ड और डिप्लॉय करने के चरणों में भी मददगार है. इन चरणों में, परफ़ॉर्मेंस रिग्रेशन टेस्टिंग की ज़रूरत होती है, ताकि उपयोगकर्ताओं को बेहतर अनुभव मिल सके.
Lighthouse का इस्तेमाल कब नहीं करना चाहिए
Lighthouse (या Lighthouse CI) फ़ील्ड डेटा का विकल्प नहीं है. लाइटहाउस, मुख्य रूप से गड़बड़ी का पता लगाने वाला टूल है. यह पहले से तय पेज लोड के आधार पर, संभावित समस्याओं और सबसे सही तरीकों की सूची दिखाता है. यह ज़रूरी नहीं है कि इससे मिलने वाले सुझाव, आपके उपयोगकर्ताओं को मिलने वाली परफ़ॉर्मेंस से हमेशा मेल खाएं.
PageSpeed Insights जैसे टूल की मदद से, Lighthouse का इस्तेमाल प्रोडक्शन साइटों की जांच करने के लिए किया जा सकता है. हालांकि, Lighthouse का इस्तेमाल डेवलपमेंट और लगातार इंटिग्रेशन वाले एनवायरमेंट में किया जाना चाहिए, ताकि परफ़ॉर्मेंस से जुड़ी समस्याओं को प्रोडक्शन में पहुंचने से पहले ही ठीक किया जा सके.
Lighthouse से मिलने वाले ऑडिट, Chrome DevTools के परफ़ॉर्मेंस पैनल में "अहम जानकारी" के ज़रिए भी उपलब्ध होते हैं. इससे पेज की परफ़ॉर्मेंस का ज़्यादा बारीकी से विश्लेषण किया जा सकता है.
Chrome DevTools में परफ़ॉर्मेंस पैनल
Chrome DevTools, ब्राउज़र में मौजूद डेवलपमेंट टूल का एक कलेक्शन है. इसमें परफ़ॉर्मेंस पैनल भी शामिल है. परफ़ॉर्मेंस पैनल, लैब टूल है. इसमें दो "मोड" होते हैं:
परफ़ॉर्मेंस पैनल को पहली बार खोलने पर, लाइव मेट्रिक स्क्रीन पर Core Web Vitals की मौजूदा मेट्रिक दिखती है. साथ ही, CrUX से फ़ील्ड डेटा इंपोर्ट करने का विकल्प भी मिलता है. यह परफ़ॉर्मेंस की समस्याओं के "लाइव" व्यू के तौर पर काम आता है. ऐसा इसलिए, क्योंकि पेज के साथ इंटरैक्ट करने पर, परफ़ॉर्मेंस से जुड़ी समस्याओं का पता लगाया जा सकता है. खास तौर पर, पेज लोड होने के बाद आने वाली समस्याओं का पता लगाया जा सकता है. ये समस्याएं, सीएलएस और आईएनपी मेट्रिक की मदद से देखी जा सकती हैं.
दूसरा, परफ़ॉर्मेंस पैनल की मदद से डेवलपर, पेज लोड होने के दौरान या रिकॉर्ड की गई समयावधि के दौरान, पेज की सभी गतिविधियों की प्रोफ़ाइल (या ट्रेस) कैप्चर कर सकते हैं. इस व्यू में, नेटवर्क, रेंडरिंग, पेंटिंग, और स्क्रिप्टिंग गतिविधि जैसे डाइमेंशन के साथ-साथ, पेज के Core Web Vitals के बारे में अहम जानकारी मिलती है. इसमें Lighthouse की तरह ही अहम जानकारी भी शामिल होती है.
परफ़ॉर्मेंस पैनल का इस्तेमाल कब करना चाहिए
डेवलपर को परफ़ॉर्मेंस पैनल का इस्तेमाल करना चाहिए, ताकि वे किसी पेज की परफ़ॉर्मेंस के बारे में ज़्यादा जानकारी पा सकें.
लाइव मेट्रिक व्यू का इस्तेमाल करके, पेज की मौजूदा परफ़ॉर्मेंस को तुरंत समझा जा सकता है. साथ ही, पेज के साथ इंटरैक्ट करते समय संभावित समस्याओं का पता लगाया जा सकता है.
ट्रेस व्यू, आईएनपी पर असर डालने वाली रिस्पॉन्सिवनेस से जुड़ी समस्याओं को डीबग करने के लिए खास तौर पर मददगार है. जब किसी खराब इंटरैक्शन की पहचान हो जाती है और उसे दोहराया जा सकता है, तो परफ़ॉर्मेंस पैनल से ब्राउज़र में होने वाली गतिविधियों के बारे में काफ़ी डेटा मिल सकता है. इससे समस्या को समझने में मदद मिलती है. जैसे, मुख्य थ्रेड को ब्लॉक करना, JavaScript कॉल स्टैक, और रेंडरिंग का काम.
परफ़ॉर्मेंस पैनल का इस्तेमाल कब नहीं करना चाहिए
परफ़ॉर्मेंस पैनल एक डेवलपर टूल है. यह मुख्य रूप से लैब डेटा उपलब्ध कराता है. हालांकि, इसमें CrUX से मिला कुछ फ़ील्ड डेटा भी शामिल होता है. यह फ़ील्ड डेटा का विकल्प नहीं है.
ट्रेस व्यू में डीबग करने की काफ़ी जानकारी होती है. हालांकि, इस वजह से नए डेवलपर या डेवलपर के अलावा अन्य भूमिकाओं में काम करने वाले लोगों के लिए, इसे समझना मुश्किल हो सकता है. हालांकि, पैनल के साथ खुलने वाला लाइव मेट्रिक व्यू, इस समस्या को हल करता है. यह उन लोगों के लिए इस्तेमाल में आसान इंटरफ़ेस उपलब्ध कराता है जिन्हें पूरी जानकारी की ज़रूरत नहीं होती.
अपनी वेबसाइट के Core Web Vitals को बेहतर बनाए रखने के लिए, तीन चरणों वाला वर्कफ़्लो
उपयोगकर्ता अनुभव को बेहतर बनाने के लिए, इस प्रोसेस को एक साइकल की तरह देखना सबसे सही तरीका है. Core Web Vitals और अन्य परफ़ॉर्मेंस मेट्रिक को बेहतर बनाने के लिए, यह तरीका अपनाया जा सकता है:
- वेबसाइट की परफ़ॉर्मेंस का आकलन करना और समस्याओं की पहचान करना.
- डीबग और ऑप्टिमाइज़ करें.
- रिग्रेशन को पकड़ने और रोकने के लिए, लगातार इंटिग्रेशन टूल की मदद से मॉनिटर करें.
पहला चरण: वेबसाइट की परफ़ॉर्मेंस का आकलन करना और उसे बेहतर बनाने के मौके पहचानना
वेबसाइट की परफ़ॉर्मेंस का आकलन करने के लिए, फ़ील्ड डेटा से शुरुआत करना सबसे सही रहता है.
- PageSpeed Insights का इस्तेमाल करके, ऑरिजिन पर Core Web Vitals की मेट्रिक और किसी यूआरएल की खास जानकारी देखी जा सकती है.
- Search Console की मदद से, उन पेजों की पहचान की जा सकती है जिनमें सुधार की ज़रूरत है. इसके लिए, Search Console की पेज ग्रुपिंग सुविधा का इस्तेमाल किया जा सकता है.
- अगर आपके पास आरयूएम डेटा है, तो अक्सर यह उन खास पेजों या ट्रैफ़िक सेगमेंट की पहचान करने का सबसे अच्छा विकल्प होता है जिनमें समस्याएं हैं.
चाहे खुद इकट्ठा किए गए फ़ील्ड डेटा का विश्लेषण किया जाए या CrUX डेटा का, यह पहला चरण बहुत ज़रूरी है. अगर फ़ील्ड डेटा इकट्ठा नहीं किया जा रहा है, तो CrUX डेटा से आपको मदद मिल सकती है. हालांकि, इसके लिए ज़रूरी है कि आपकी वेबसाइट का डेटासेट मौजूद हो.
PageSpeed Insights की मदद से साइट की परफ़ॉर्मेंस का विश्लेषण करना
PageSpeed Insights, CrUX डेटा दिखाता है. इसमें पिछले 28 दिनों के उपयोगकर्ता अनुभव का डेटा, 75वें पर्सेंटाइल पर शामिल होता है. इसका मतलब है कि अगर 75% उपयोगकर्ता अनुभव, किसी मेट्रिक के लिए सेट किए गए थ्रेशोल्ड को पूरा करते हैं, तो अनुभव को "अच्छा" माना जाता है.
अगर आपको किसी खास पेज की परफ़ॉर्मेंस देखनी है, तो उस पेज का इस्तेमाल करें. ऑप्टिमाइज़ेशन की शुरुआत में, साइट की पूरी जानकारी पाने के लिए, होम पेज से शुरुआत की जा सकती है. ऐसा इसलिए, क्योंकि आम तौर पर यह कई साइटों पर सबसे लोकप्रिय पेजों में से एक होता है.
शुरुआत में, PSI के आपके असली उपयोगकर्ताओं को कैसा अनुभव मिल रहा है सेक्शन पर ध्यान दें. आपको डेटा के ज़्यादा से ज़्यादा चार व्यू दिखेंगे: डाले गए यूआरएल और पूरे ऑरिजिन के लिए मोबाइल और डेस्कटॉप. इनकी तुलना करें और देखें कि इनमें क्या अंतर है. आम तौर पर, मोबाइल की परफ़ॉर्मेंस डेस्कटॉप की तुलना में कम होती है. इसकी वजह यह है कि मोबाइल में कम संसाधन होते हैं और यह कम स्टेबल नेटवर्क पर काम करता है. अगर यूआरएल और ऑरिजिन डेटा में काफ़ी अंतर है, तो इसकी वजह जानने की कोशिश करें: होम पेज अक्सर विज़िट किए जाने वाले पहले पेज (यानी कि लैंडिंग पेज) होते हैं. इसलिए, ये ऑरिजिन की तुलना में धीमे हो सकते हैं. ऐसा इसलिए, क्योंकि उपयोगकर्ताओं को ब्राउज़र कैश मेमोरी के प्राइम न होने का पूरा असर झेलना पड़ता है. इसके बाद के पेज तेज़ी से लोड होंगे, क्योंकि शेयर की गई सभी एसेट कैश मेमोरी में सेव हो जाएंगी. इससे ऑरिजिन-लेवल का कुल डेटा कम हो जाएगा.
पीएसआई, तीनों Core Web Vitals (एलसीपी, सीएलएस, और आईएनपी) के साथ-साथ, डाइग्नोस्टिक टीटीएफ़बी और एफ़सीपी मेट्रिक भी दिखाता है. क्या Core Web Vitals में से कोई फ़ेल हो रहा है? अगर हां, तो कितने अंतर से? इससे आपको पता चलेगा कि आपको कहां ज़्यादा ध्यान देना चाहिए.
इन नंबरों के बीच के संबंध को समझें—खास तौर पर एलसीपी के लिए. अगर एलसीपी धीमा है, जैसा कि इस उदाहरण में है, तो टीटीएफ़बी और एफ़सीपी को देखें. ये दोनों इस मेट्रिक के लिए माइलस्टोन हैं. इस उदाहरण में, हमारे पास 1.8 सेकंड का टीटीएफ़बी है. इससे, अच्छे एलसीपी के लिए सुझाई गई 2.5 सेकंड की थ्रेशोल्ड को पूरा करना बहुत मुश्किल हो जाएगा. इससे पता चलता है कि बैकएंड धीमा है (सर्वर से जुड़ी समस्याएं या सीडीएन की कमी), नेटवर्क धीमे हैं या रीडायरेक्ट की वजह से पहले एचटीएमएल बाइट में देरी हो रही है. ज़्यादा जानकारी के लिए, टीटीएफ़बी को ऑप्टिमाइज़ करने की गाइड देखें. इसके बाद, एफ़सीपी को एक और सेकंड लगता है. इससे भी यह पता चलता है कि नेटवर्क की स्पीड धीमी है. इस उदाहरण में, एफ़सीपी के बाद एलसीपी को लोड होने में ज़्यादा समय नहीं लगा. इससे पता चलता है कि पेज लोड होने के बाद, एलसीपी रिसॉर्स को अच्छी तरह से ऑप्टिमाइज़ किया गया है. CrUX अब संसाधन के टाइप और सबपार्ट में, गड़बड़ी की ज़्यादा जानकारी भी दिखाता है. इससे आपको एलसीपी से जुड़ी समस्याओं का पता लगाने में भी मदद मिलती है.
सीएलएस के लिए, CrUX सीएलएस और Lighthouse सीएलएस स्कोर देखें. इससे यह पता चलेगा कि यह सीएलएस लोड होने की समस्या है या लोड होने के बाद की समस्या. Lighthouse, लोड होने की समस्या का पता लगाएगा और उसके बारे में सलाह देगा. हालांकि, वह लोड होने के बाद की समस्या का पता नहीं लगा पाएगा. ज़्यादा जानकारी के लिए, सीएलएस को ऑप्टिमाइज़ करने की गाइड देखें.
रिस्पॉन्सिवनेस के लिए, आईएनपी स्कोर देखें. Lighthouse में टीबीटी ऑडिट देखें. इससे यह पता चलता है कि पेज के शुरुआती लोड के दौरान, बहुत ज़्यादा JavaScript प्रोसेस हो रही है या नहीं. इससे आईएनपी पर असर पड़ सकता है. आईएनपी को बेहतर बनाना मुश्किल हो सकता है. इसलिए, ज़्यादा जानकारी के लिए आईएनपी को ऑप्टिमाइज़ करने की गाइड देखें.
Search Console में, खराब परफ़ॉर्मेंस वाले पेजों की पहचान करना
पीएसआई तब काम आता है, जब आपको किसी खास यूआरएल या पूरी साइट की जांच करनी हो. वहीं, Search Console की मदद से, खास तरह के पेजों को टारगेट किया जा सकता है. यह तरीका तब ज़्यादा काम आता है, जब कई पेजों की थीम या टेक्नोलॉजी एक जैसी हों और Search Console इनकी पहचान कर सके.
Search Console में Core Web Vitals रिपोर्ट में, आपकी वेबसाइट की परफ़ॉर्मेंस की पूरी जानकारी दिखती है. हालांकि, आपके पास उन पेजों की जानकारी को ज़्यादा बारीकी से देखने का विकल्प भी होता है जिन पर ध्यान देने की ज़रूरत है. Search Console की मदद से, ये काम भी किए जा सकते हैं:
- उन पेज ग्रुप की पहचान करें जिनमें सुधार की ज़रूरत है. साथ ही, उन पेज ग्रुप की पहचान करें जो उपयोगकर्ताओं को अच्छा अनुभव देते हैं.
- यूआरएल के हिसाब से परफ़ॉर्मेंस का ज़्यादा सटीक डेटा पाएं. इसे स्टेटस, मेट्रिक, और मिलते-जुलते वेब पेजों के ग्रुप के हिसाब से बांटा जाता है. जैसे, किसी ई-कॉमर्स वेबसाइट पर प्रॉडक्ट की जानकारी वाले पेज.
- मोबाइल और डेस्कटॉप, दोनों के लिए उपयोगकर्ता अनुभव की क्वालिटी की हर कैटगरी में यूआरएल को बकेट करने वाली ज़्यादा जानकारी वाली रिपोर्ट पाएं.
कुछ खास पेजों की पहचान करने के बाद, पीएसआई का इस्तेमाल करके उन पेजों की समस्याओं के बारे में ज़्यादा जानकारी इकट्ठा की जा सकती है. इसके बारे में पहले बताया जा चुका है.
दूसरा चरण: डीबग और ऑप्टिमाइज़ करना
पहले चरण में, आपको उन पेजों की पहचान करनी चाहिए जिनकी परफ़ॉर्मेंस को बेहतर बनाने की ज़रूरत है. साथ ही, आपको यह भी तय करना चाहिए कि आपको Core Web Vitals की किन मेट्रिक को बेहतर बनाना है. समस्या की असल वजह का पता लगाने के लिए, Google के टूल का इस्तेमाल करके ज़्यादा जानकारी हासिल की जा सकती है.
- पेज के लिए बेहतर दिशा-निर्देश पाने के लिए, Lighthouse ऑडिट देखें
- Core Web Vitals का रीयल टाइम में विश्लेषण करने के लिए, परफ़ॉर्मेंस पैनल के लाइव मेट्रिक व्यू का इस्तेमाल करें.
- परफ़ॉर्मेंस की समस्याओं को डीबग करने और कोड में किए गए बदलावों की जांच करने के लिए, परफ़ॉर्मेंस पैनल ट्रेसिंग का इस्तेमाल करें.
ज़्यादा जानकारी के लिए, ये गाइड देखें:
Lighthouse की मदद से अवसरों का पता लगाना
PageSpeed Insights, आपके लिए Lighthouse को चलाता है. Chrome DevTools से भी Lighthouse को चलाया जा सकता है. इससे, स्थानीय तौर पर गड़बड़ियों को ठीक करने में मदद मिलती है. हालांकि, परफ़ॉर्मेंस पैनल (इसके बारे में आगे बताया गया है) स्थानीय तौर पर परफ़ॉर्मेंस से जुड़ी समस्याओं की पहचान करने और उन्हें ठीक करने के लिए ज़्यादा बेहतर टूल है.
एक अहम बात यह है कि आपको यह पुष्टि करनी होगी कि Lighthouse ऑडिट में वे समस्याएं दिख रही हैं जिन्हें आपको हल करना है. उदाहरण के लिए, एलसीपी का धीमा होना या सीएलएस से जुड़ी समस्याएं. Lighthouse, पेज लोड होने के दौरान ही उपयोगकर्ता अनुभव का आकलन करता है. लैब टूल होने की वजह से, यह आईएनपी के बजाय टीबीटी को शामिल करता है.
जब Lighthouse मेट्रिक से पता चलता है कि आपको उसी समस्या का सामना करना पड़ रहा है जिसे हल करने की कोशिश की जा रही है, तो इसके ऑडिट में मौजूद ज़्यादा जानकारी से समस्याओं की पहचान करने और उनके समाधान सुझाने में मदद मिल सकती है.
ऑडिट को सिर्फ़ उन Core Web Vitals के हिसाब से फ़िल्टर किया जा सकता है जिनमें आपकी दिलचस्पी है. इससे किसी खास मेट्रिक से जुड़ी समस्याओं को ठीक करने पर फ़ोकस किया जा सकता है:
आईएनपी के लिए, टीबीटी ऑडिट का इस्तेमाल करके उन समस्याओं की पहचान करें जो इन मेट्रिक पर असर डाल सकती हैं. हालांकि, ध्यान रखें कि इंटरैक्शन के बिना, Lighthouse की विश्लेषण करने की क्षमता सीमित होती है.
Chrome DevTools की लाइव मेट्रिक स्क्रीन की मदद से, रीयल टाइम में विश्लेषण करना
Chrome DevTools के परफ़ॉर्मेंस पैनल में मौजूद लाइव मेट्रिक स्क्रीन, पेज लोड होने और पेज ब्राउज़ करने के दौरान, रीयल टाइम में Core Web Vitals दिखाती है. इस वजह से, यह आईएनपी के साथ-साथ, लोड होने के बाद होने वाले लेआउट शिफ़्ट को भी कैप्चर कर सकता है. हर मेट्रिक के बारे में ज़्यादा जानकारी भी देखी जा सकती है:
इस व्यू से, परफ़ॉर्मेंस से जुड़ी समस्याओं की पहचान करने में मदद मिलती है. साथ ही, इसमें CrUX से फ़ील्ड की जानकारी भी शामिल की जा सकती है. ज़्यादा जानकारी के लिए, ट्रेस की मदद से ज़्यादा जानकारी देखी जा सकती है.
परफ़ॉर्मेंस पैनल की मदद से ज़्यादा जानकारी पाना
Chrome DevTools में मौजूद परफ़ॉर्मेंस पैनल की मदद से, रिकॉर्ड की गई समयावधि के दौरान पेज के सभी व्यवहार की प्रोफ़ाइल (या ट्रेस) रिकॉर्ड की जा सकती है.
परफ़ॉर्मेंस के बारे में अहम जानकारी, अहम जानकारी वाले साइड पैनल में उपलब्ध होती है. इसमें Core Web Vitals मेट्रिक के साथ-साथ, उपलब्ध होने पर उनकी फ़ील्ड वैल्यू भी दिखती हैं.
लेआउट शिफ़्ट ट्रैक, लेआउट शिफ़्ट को हाइलाइट करता है. इन पर क्लिक करने से, उन एलिमेंट के बारे में ज़्यादा जानकारी मिलती है जो सीएलएस को डीबग करने के लिए शिफ़्ट किए गए हैं.
एलसीपी जैसी मुख्य टाइमिंग, ट्रेस के सबसे नीचे मौजूद टाइमिंग में दिखती हैं. ज़्यादा जानकारी के लिए, इन पर क्लिक करें.
ज़्यादा समय लेने वाले टास्क (इनकी वजह से आईएनपी से जुड़ी समस्याएं हो सकती हैं) को भी फ़्लेम चार्ट में लाल रंग के त्रिकोणों से हाइलाइट किया जाता है.
इन सुविधाओं और परफ़ॉर्मेंस पैनल के अन्य हिस्सों में मौजूद जानकारी से, आपको यह तय करने में मदद मिल सकती है कि समस्याओं को ठीक करने से, किसी पेज के Core Web Vitals पर कोई असर पड़ रहा है या नहीं.
फ़ील्ड में Core Web Vitals को डीबग करना
लैब टूल, Core Web Vitals से जुड़ी उन सभी समस्याओं की वजह का पता नहीं लगा सकते जिनसे आपके उपयोगकर्ताओं पर असर पड़ता है. इसी वजह से, अपना फ़ील्ड डेटा इकट्ठा करना बहुत ज़रूरी है. इसमें उन फ़ैक्टर को ध्यान में रखा जाता है जिन्हें लैब डेटा में शामिल नहीं किया जा सकता.
ज़्यादा जानकारी के लिए, फ़ील्ड में परफ़ॉर्मेंस को डीबग करना लेख पढ़ें.
तीसरा चरण: बदलावों पर नज़र रखना
किसी भी समस्या को ठीक करने के बाद, आपको यह पक्का करना होगा कि उसका असर सही हो और नई समस्याएं आपके Core Web Vitals में रुकावट न डालें. इसके लिए, डेवलपर वर्कफ़्लो के हिस्से के तौर पर परफ़ॉर्मेंस से जुड़ी समस्याओं पर नज़र रखना ज़रूरी है. इससे परफ़ॉर्मेंस से जुड़ी समस्याओं को प्रोडक्शन में रिलीज़ होने से रोका जा सकता है. साथ ही, फ़ील्ड डेटा को नियमित तौर पर मॉनिटर करके यह पक्का किया जा सकता है कि ऐसा ही हो.
लगातार इंटिग्रेशन (सीआई) वाले एनवायरमेंट में, परफ़ॉर्मेंस से जुड़ी ज़रूरी शर्तों पर नज़र रखना
Lighthouse-CI की मदद से, कोड कमिट पर Lighthouse ऑडिट अपने-आप चलाए जा सकते हैं. इससे कोड में परफ़ॉर्मेंस रिग्रेशन को रोका जा सकता है. इससे परफ़ॉर्मेंस की टाइमिंग (जो बदलाव के हिसाब से बदलती रहती है) या सिर्फ़ परफ़ॉर्मेंस ऑडिट की जांच की जा सकती है. यह कोड में गलत तरीकों को रोकने के लिए, लिंटिंग टूल के तौर पर काम करता है.
फ़ील्ड डेटा की मदद से, वेबसाइट की परफ़ॉर्मेंस के ट्रेंड देखना
आपको परफ़ॉर्मेंस से जुड़ी सभी समस्याओं को प्रोडक्शन में जाने से पहले ही पकड़कर ठीक कर लेना चाहिए. हालांकि, आरयूएम का इस्तेमाल करके फ़ील्ड डेटा को मॉनिटर करना ज़रूरी है, ताकि ऐसी किसी भी समस्या का पता लगाया जा सके जो छूट गई हो. इस काम में मदद करने के लिए, कई कमर्शियल आरयूएम प्रॉडक्ट उपलब्ध हैं. web-vitals JavaScript लाइब्रेरी, वेबसाइट के फ़ील्ड डेटा को इकट्ठा करने की प्रोसेस को ऑटोमेट कर सकती है. साथ ही, इस डेटा का इस्तेमाल करके, कस्टम डैशबोर्ड और सूचना देने वाले सिस्टम को बेहतर बनाया जा सकता है.
जिन साइटों के लिए आरयूएम की सुविधा उपलब्ध नहीं है उनके लिए, फ़ील्ड डेटा के बुनियादी रुझान का विश्लेषण करने के लिए, CrUX के अलग-अलग टूल इस्तेमाल किए जा सकते हैं.
नतीजा
उपयोगकर्ताओं को तेज़ और बेहतर अनुभव देने के लिए, परफ़ॉर्मेंस को प्राथमिकता देने वाली सोच और प्रोग्रेस को पक्का करने वाला वर्कफ़्लो अपनाना ज़रूरी है. ऑडिट, डीबग, और मॉनिटर करने के लिए सही टूल और प्रोसेस का इस्तेमाल करके, उपयोगकर्ताओं को बेहतर अनुभव दिया जा सकता है. साथ ही, Core Web Vitals के लिए तय किए गए थ्रेशोल्ड के अंदर रहा जा सकता है.