मेट्रिक

पब्लिश होने की तारीख: 23 जून, 2022, पिछली बार अपडेट होने की तारीख: 15 सितंबर, 2026

CrUX में मेट्रिक, ब्राउज़र के स्टैंडर्ड वेब प्लैटफ़ॉर्म एपीआई से मिलती हैं. खास तौर पर, BigQuery डेटासेट में इस डेटा को ऑरिजिन-रिज़ॉल्यूशन के हिसाब से एग्रीगेट किया जाता है. जिन साइट के मालिकों को अपनी साइट की परफ़ॉर्मेंस के बारे में ज़्यादा जानकारी (जैसे, यूआरएल-लेवल का रिज़ॉल्यूशन) और अहम जानकारी चाहिए वे इन्हीं एपीआई का इस्तेमाल करके, अपने ऑरिजिन के लिए ज़्यादा जानकारी वाला रीयल यूज़र मेज़रमेंट (आरयूएम) डेटा इकट्ठा कर सकते हैं. ध्यान दें कि सभी एपीआई Chrome में उपलब्ध हैं. हालांकि, ऐसा हो सकता है कि अन्य ब्राउज़र, मेट्रिक के पूरे सेट के साथ काम न करें.

ज़्यादातर मेट्रिक को हिस्टोग्राम एग्रीगेशन के तौर पर दिखाया जाता है. इससे डिस्ट्रिब्यूशन और पर्सेंटाइल वैल्यू का अनुमान लगाने में मदद मिलती है.

कुल लेआउट शिफ़्ट

"लेआउट शिफ़्ट होने में लगने वाला समय (सीएलएस), उपयोगकर्ताओं को ध्यान में रखकर बनाई गई एक अहम मेट्रिक है. इससे विज़ुअल स्टेबिलिटी का आकलन किया जाता है. ऐसा इसलिए, क्योंकि इससे यह पता चलता है कि उपयोगकर्ताओं को कितनी बार लेआउट में अचानक बदलाव का सामना करना पड़ता है. सीएलएस कम होने से यह पक्का करने में मदद मिलती है कि पेज का अनुभव अच्छा है."

web.dev/articles/cls

DOM Content Loaded

"DOMContentLoaded, उस समय के बारे में बताता है जब शुरुआती एचटीएमएल दस्तावेज़ पूरी तरह से लोड हो चुका हो और उसे पार्स कर लिया गया हो. इसके लिए, स्टाइलशीट, इमेज, और सबफ़्रेम के लोड होने का इंतज़ार नहीं करना पड़ता."

MDN

पहला पैंट

"फ़र्स्ट पेंट, नेविगेशन के बाद ब्राउज़र के पहली बार रेंडर होने का समय दिखाता है. इसमें डिफ़ॉल्ट बैकग्राउंड पेंट शामिल नहीं है, लेकिन नॉन-डिफ़ॉल्ट बैकग्राउंड पेंट शामिल है. यह पेज लोड होने का पहला अहम पल होता है, जिस पर डेवलपर ध्यान देते हैं. इस समय, ब्राउज़र पेज को रेंडर करना शुरू कर देता है."

Paint Timing API

फ़र्स्ट कॉन्टेंटफ़ुल पेंट

"फ़र्स्ट कॉन्टेंटफ़ुल पेंट (FCP) से पता चलता है कि ब्राउज़र ने पहली बार किसी टेक्स्ट, इमेज (इसमें बैकग्राउंड इमेज भी शामिल हैं), नॉन-व्हाइट कैनवस या एसवीजी को कब रेंडर किया. इसमें ऐसे टेक्स्ट शामिल हैं जिनमें वेबफ़ॉन्ट इस्तेमाल किए गए हैं और उन्हें अभी तक मंज़ूरी नहीं मिली है. यह वह समय होता है, जब उपयोगकर्ता पेज का कॉन्टेंट देखना शुरू कर सकते हैं."

Paint Timing API

पेज के रिस्पॉन्स में लगने वाला समय

"पेज के रिस्पॉन्स में लगने वाला समय (आईएनपी) एक फ़ील्ड मेट्रिक है. इससे रिस्पॉन्स में लगने वाले समय का आकलन किया जाता है. आईएनपी, पूरे पेज की लाइफ़साइकल के दौरान हुए सभी इंटरैक्शन के इंतज़ार के समय को लॉग करता है. इन इंटरैक्शन की सबसे ज़्यादा वैल्यू या कई इंटरैक्शन वाले पेजों के लिए सबसे ज़्यादा वैल्यू के आस-पास की वैल्यू को, पेज के आईएनपी के तौर पर रिकॉर्ड किया जाता है. कम आईएनपी से यह पक्का होता है कि पेज हमेशा भरोसेमंद तरीके से काम करेगा."

web.dev/articles/inp

पेज के रिस्पॉन्स में लगने वाले समय (आईएनपी) को CrUX डेटासेट में फ़रवरी 2022 में जोड़ा गया था. इस नई मेट्रिक से, अलग-अलग इवेंट की एंड-टू-एंड लेटेन्सी का पता चलता है. साथ ही, इससे पेज के लोड होने में लगने वाले कुल समय के बारे में ज़्यादा जानकारी मिलती है.

सबसे बड़ा कॉन्टेंटफ़ुल पेंट

"सबसे बड़े एलिमेंट को रेंडर करने में लगने वाला समय (एलसीपी), उपयोगकर्ताओं को ध्यान में रखकर बनाई गई एक अहम मेट्रिक है. इसका इस्तेमाल पेज लोड होने का अनुमानित समय मापने के लिए किया जाता है. ऐसा इसलिए, क्योंकि यह मेट्रिक, पेज लोड होने की टाइमलाइन में उस समय के बारे में बताती है जब पेज का मुख्य कॉन्टेंट लोड होने की संभावना होती है. एलसीपी कम होने से, उपयोगकर्ता को यह भरोसा मिलता है कि पेज काम का है."

web.dev/articles/lcp

सबसे बड़े एलिमेंट को रेंडर करने में लगने वाले समय के संसाधन का टाइप

"एलसीपी, व्यूपोर्ट में दिखने वाले सबसे बड़ी इमेज, टेक्स्ट ब्लॉक या वीडियो के रेंडर होने में लगने वाले समय की जानकारी देता है. यह इस बात से तय होता है कि उपयोगकर्ता ने पहली बार पेज पर कब नेविगेट किया था."

web.dev/articles/lcp - What elements are considered for LCP

टेक्स्ट और इमेज (इसमें वीडियो के पहले फ़्रेम की इमेज भी शामिल है) को लोड करने की प्रोसेस और ऑप्टिमाइज़ करने के तरीके अक्सर अलग-अलग होते हैं. एलसीपी रिसॉर्स टाइप के अनुपात को समझने से, आपको एलसीपी मेट्रिक और ऑप्टिमाइज़ेशन पाथ को बेहतर तरीके से समझने में मदद मिलती है.

ज़्यादा जानकारी के लिए, एलसीपी रिसॉर्स टाइप लॉन्च करने से जुड़ी ब्लॉग पोस्ट पढ़ें.

सबसे बड़े कॉन्टेंटफ़ुल पेंट वाली इमेज के उप-भाग

"अगर PageSpeed Insights आपको यह नहीं बताता कि इस मेट्रिक को कैसे बेहतर बनाया जाए, तो एलसीपी के लिए ऑप्टिमाइज़ करना एक मुश्किल काम हो सकता है. मुश्किल टास्क के लिए, उन्हें मैनेज किए जा सकने वाले छोटे-छोटे टास्क में बांटना बेहतर होता है. साथ ही, हर टास्क को अलग-अलग पूरा करना चाहिए."

web.dev/articles/optimize-lcp - एलसीपी को सब-पार्ट में बांटना

एलसीपी इमेज को सबसे अहम सब-पार्ट में बांटने से, हर पार्ट को ऑप्टिमाइज़ करने के लिए खास सुझावों और सबसे सही तरीकों का इस्तेमाल किया जा सकता है.

एलसीपी इमेज के सब-पार्ट, चार अलग-अलग मेट्रिक में दिए जाते हैं:

• largest_contentful_paint_image_time_to_first_byte
• largest_contentful_paint_image_resource_load_delay
• largest_contentful_paint_image_resource_load_duration
• largest_contentful_paint_image_element_render_delay

उप-हिस्से सिर्फ़ इमेज के लिए शामिल किए जाते हैं. इसमें वीडियो के पहले फ़्रेम की इमेज शामिल नहीं होती हैं, क्योंकि ये थोड़ी ज़्यादा जटिल होती हैं. ऐसा इसलिए, क्योंकि हम डाउनलोड होने में लगने वाले पूरे समय का पता नहीं लगा सकते. ध्यान दें कि वीडियो के पहले फ़्रेम, एलसीपी रिसॉर्स टाइप मेट्रिक में शामिल होते हैं. इसमें यह जटिलता काम की नहीं होती.

टेक्स्ट के सब-पार्ट भी शामिल नहीं किए जाते, क्योंकि वे कम काम के होते हैं और उनसे इमेज एलसीपी के नंबर खराब हो जाते हैं. जिन साइटों पर ज़्यादातर टेक्स्ट एलसीपी होते हैं उनके लिए, कुल TTFB और कुल FCP मेट्रिक का ब्रेकडाउन काम का होता है. हालांकि, ध्यान दें कि ये सभी एलसीपी के लिए होती हैं, न कि सिर्फ़ टेक्स्ट एलसीपी के लिए.

ज़्यादा जानकारी के लिए, एलसीपी इमेज के सब-पार्ट लॉन्च करने से जुड़ी ब्लॉग पोस्ट पढ़ें.

नेविगेशन के टाइप

नेविगेशन टाइप मेट्रिक से, पेज व्यू के प्रतिशत का ब्रेकडाउन मिलता है. इससे इन नेविगेशन के बारे में पता चलता है:

टाइप	ब्यौरा
navigate	पेज लोड होने की ऐसी गतिविधि जो किसी अन्य कैटगरी में नहीं आती.
navigate_cache	ऐसा पेज लोड जिसके लिए मुख्य रिसॉर्स (मुख्य एचटीएमएल दस्तावेज़) को एचटीटीपी कैश मेमोरी से दिखाया गया हो. साइटें अक्सर सब-संसाधनों के लिए कैश मेमोरी का इस्तेमाल करती हैं. हालांकि, मुख्य एचटीएमएल दस्तावेज़ को अक्सर बहुत कम समय के लिए कैश मेमोरी में सेव किया जाता है. ऐसा होने पर, परफ़ॉर्मेंस में काफ़ी सुधार हो सकता है. ऐसा इसलिए, क्योंकि इसे स्थानीय तौर पर और सीडीएन पर कैश मेमोरी में सेव किया जा सकता है.
reload	उपयोगकर्ता ने पेज को फिर से लोड किया हो. ऐसा, 'फिर से लोड करें' बटन दबाकर, पता बार में Enter दबाकर या टैब बंद करने की कार्रवाई को पहले जैसा करके किया जा सकता है. पेज को बार-बार रीलोड करने से, सर्वर को फिर से पुष्टि करने का अनुरोध भेजा जाता है. इससे यह पता चलता है कि मुख्य पेज में कोई बदलाव हुआ है या नहीं. पेज को फिर से लोड करने का प्रतिशत ज़्यादा होने का मतलब है कि उपयोगकर्ता को परेशानी हो रही है.
restore	ब्राउज़र को फिर से शुरू करने के बाद पेज को फिर से लोड किया गया था. इसके अलावा, ऐसा भी हो सकता है कि मेमोरी की वजह से हटाए गए किसी टैब को फिर से लोड किया गया हो. Android पर Chrome के लिए, इन्हें 'फिर से लोड करें' के तौर पर रिपोर्ट किया जाता है.
back_forward	इतिहास नेविगेशन. इसका मतलब है कि पेज को हाल ही में देखा गया था और फिर वापस लाया गया था. सही तरीके से कैश मेमोरी का इस्तेमाल करने पर, ये पेज तेज़ी से लोड होते हैं. हालांकि, इसके लिए पेज को प्रोसेस करना और JavaScript को एक्ज़ीक्यूट करना ज़रूरी होता है. bfcache इन दोनों से बचता है.
back_forward_cache	बैक/फ़ॉरवर्ड कैश मेमोरी से नेविगेशन का इतिहास दिखाया गया. bfcache का फ़ायदा पाने के लिए, अपने पेजों को ऑप्टिमाइज़ करें. इसके लिए, bfcache को ब्लॉक करने वाले एलिमेंट हटाएं. इससे पेजों को तेज़ी से लोड किया जा सकेगा. इसलिए, साइटों को
prerender	पेज को प्रीरेंडर किया गया था. इससे, बीएफ़कैश की तरह ही, पेज तुरंत लोड हो सकता है.

कुछ मामलों में, पेज लोड होने की प्रोसेस में एक से ज़्यादा तरह के नेविगेशन शामिल हो सकते हैं. ऐसे में, CrUX टेबल में मौजूद पहले मैच की जानकारी, उल्टे क्रम में दिखाता है. यानी, नीचे से ऊपर की ओर.

ज़्यादा जानकारी के लिए, नेविगेशन टाइप से जुड़ी सूचना वाली पोस्ट देखें.

Onload

"पेज और उससे जुड़े रिसॉर्स लोड होने के बाद, लोड इवेंट ट्रिगर होता है."

MDN

दोतरफ़ा यात्रा का समय

यह कुकी, हाल ही के नेटवर्क कनेक्शन के आधार पर नेविगेशन की शुरुआत में, एचटीटीपी (ऐप्लिकेशन लेयर) राउंड ट्रिप टाइम का अनुमान देती है. यह मेट्रिक, Network Information API की rtt प्रॉपर्टी पर आधारित है. यह वही एपीआई है जो पहले इफ़ेक्टिव कनेक्शन टाइप (ईसीटी) डाइमेंशन के लिए ज़िम्मेदार था.

ज़्यादा जानकारी के लिए, एलसीपी रिसॉर्स टाइप लॉन्च करने से जुड़ी ब्लॉग पोस्ट पढ़ें.

एक्सपेरिमेंटल मेट्रिक

एक्सपेरिमेंट के तौर पर उपलब्ध मेट्रिक, BigQuery का इस्तेमाल करके CrUX डेटासेट और CrUX API, दोनों में उपलब्ध होती हैं. हालांकि, सभी मेट्रिक दोनों में उपलब्ध नहीं होती हैं. उपयोगकर्ता के सुझाव/राय/शिकायत के आधार पर, इन मेट्रिक में बदलाव हो सकता है. नए बदलावों के बारे में अप-टू-डेट रहने के लिए, रिलीज़ नोट देखें.

टाइम टू फ़र्स्ट बाइट

CrUX में टीटीएफ़बी सिर्फ़ पूरे पेज के लोड होने पर इकट्ठा किया जाता है. ऐसा अन्य टाइमर (जैसे, LCP) के उलट है. अन्य टाइमर, बैक/फ़ॉरवर्ड कैश मेमोरी (bfcache) नेविगेशन और पहले से रेंडर किए गए पेजों पर भी इकट्ठा किए जाते हैं. इसलिए, टीटीएफ़बी का सैंपल साइज़, अन्य मेट्रिक की तुलना में छोटा हो सकता है. साथ ही, यह ज़रूरी नहीं है कि इसकी तुलना सीधे तौर पर अन्य मेट्रिक से की जाए. CrUX में टीटीएफ़बी में, कोल्ड पेज लोड, कैश मेमोरी में सेव किए गए पेज लोड, और पहले से मौजूद कनेक्शन से पेज लोड (उदाहरण के लिए, इंट्रा-साइट पेज लोड) शामिल होंगे.

टीटीएफ़बी, सर्वर के रिस्पॉन्स टाइम को सीधे तौर पर मेज़र नहीं करता. इसमें इससे पहले के मेज़रमेंट भी शामिल होते हैं. जैसे, रीडायरेक्ट होने में लगने वाला समय. साथ ही, यह इस बात से भी प्रभावित होता है कि रिस्पॉन्स, कैश मेमोरी, सीडीएन या सर्वर से मिला है या नहीं. यह खास तौर पर CrUX जैसे फ़ील्ड डेटा में दिखता है. वहीं, लैब टेस्टिंग पर आम तौर पर इन फ़ैक्टर का कम असर पड़ता है. ऐसा इसलिए, क्योंकि एंड यूआरएल की जांच की जाती है और अक्सर कैश मेमोरी में बदलावों को बार-बार खारिज किया जाता है.

लोकप्रियता

लोकप्रियता की रैंक मेट्रिक, CrUX डेटासेट में साइट की लोकप्रियता का एक तुलनात्मक मेज़रमेंट है. इसे ऑरिजिन पर नेविगेशन की कुल संख्या के हिसाब से मेज़र किया जाता है. रैंक, log10 स्केल पर होती है.इसमें आधे चरण होते हैं. जैसे, टॉप 1 हज़ार, टॉप 5 हज़ार, टॉप 10 हज़ार, टॉप 50 हज़ार, टॉप 1 लाख, टॉप 5 लाख, टॉप 10 लाख वगैरह. हर रैंक में पिछली रैंक शामिल नहीं होती.जैसे, टॉप 5 हज़ार में टॉप 1 हज़ार यूआरएल शामिल नहीं होते. इसलिए, टॉप 5 हज़ार में असल में 4 हज़ार यूआरएल होते हैं. डेटासेट के बढ़ने पर, ऊपरी सीमा डाइनैमिक होती है.

लोकप्रियता की जानकारी, बड़े पैमाने पर विश्लेषण करने के लिए दी जाती है. उदाहरण के लिए, सबसे ज़्यादा लोकप्रिय 1,000 ऑरिजिन के लिए, देश के हिसाब से परफ़ॉर्मेंस का पता लगाना.

सूचना की अनुमतियां

यह मेट्रिक उन वेबसाइटों के लिए है जो उपयोगकर्ताओं को सूचनाएं दिखाने की अनुमति मांगती हैं. इससे पता चलता है कि उपयोगकर्ताओं ने प्रॉम्प्ट पर कितनी बार जवाब दिया: स्वीकार किया, अस्वीकार किया, अनदेखा किया या खारिज किया.

विज्ञापन की मेट्रिक

Chrome, साइटों और विज्ञापन देने वाले लोगों या कंपनियों जैसे अन्य लोगों के लिए सार्वजनिक मेट्रिक और टूल उपलब्ध कराता है. इससे उन्हें असली उपयोगकर्ताओं को विज्ञापन दिखाने के अनुभव और उनके असर के बारे में बेहतर तरीके से समझने में मदद मिलती है.

• विज्ञापन की संख्या: इस मेट्रिक से पता चलता है कि कोई सामान्य उपयोगकर्ता, साइट पर एक बार में कितने विज्ञापन देख रहा है.
• विज्ञापन डेंसिटी: इस मेट्रिक से यह पता चलता है कि किसी सामान्य उपयोगकर्ता को कॉन्टेंट और विज्ञापन कितने दिखते हैं.
• विज्ञापन का वज़न: सीपीयू: इस मेट्रिक से पता चलता है कि विज्ञापनों की वजह से सीपीयू का कितना इस्तेमाल हुआ. इससे परफ़ॉर्मेंस पर असर पड़ सकता है.
• विज्ञापन का साइज़: नेटवर्क: इस मेट्रिक से पता चलता है कि विज्ञापनों में नेटवर्क के संसाधनों का कितना इस्तेमाल किया गया है.

हमें उम्मीद है कि ये मेट्रिक, वेब पर विज्ञापन देने वाले लोगों या कंपनियों और विज्ञापन दिखाने के लिए इस्तेमाल की जाने वाली सेवाओं के लिए खास तौर पर मददगार होंगी. हमने विज्ञापन ईकोसिस्टम के कई स्टेकहोल्डर से सुना है कि इन मेट्रिक से, उन्हें विज्ञापन के अवसरों का आकलन करने और विज्ञापन से जुड़े प्रॉडक्ट के बारे में फ़ैसले लेने में मदद मिल सकती है.

ज़्यादा जानकारी के लिए, विज्ञापन मेट्रिक लॉन्च करने से जुड़ी ब्लॉग पोस्ट और विज्ञापन मेज़रमेंट का दस्तावेज़ देखें.