मेट्रिक

पब्लिश होने की तारीख: 23 जून, 2022, पिछली बार अपडेट किए जाने की तारीख: 13 अक्टूबर, 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 को लागू करना ज़रूरी है. बीएफ़कैश इन दोनों से बचता है.
back_forward_cache इतिहास का ऐसा नेविगेशन जिसे बीएफ़कैश से दिखाया गया था. बीएफ़कैश का फ़ायदा पाने के लिए, अपने पेजों को ऑप्टिमाइज़ करें. इसके लिए, ब्लॉक करने वाली चीज़ों को हटाएं. इससे पेजों को तेज़ी से लोड होने में मदद मिलेगी. इसलिए, साइटों को
prerender पेज को प्रीरेंडर किया गया था. बीएफ़कैश की तरह ही, इससे पेज तुरंत लोड हो सकते हैं.

कुछ मामलों में, पेज लोड होने की प्रोसेस में कई तरह के नेविगेशन टाइप शामिल हो सकते हैं. ऐसे में, CrUX टेबल के उल्टे क्रम (नीचे से ऊपर) में पहले मैच की रिपोर्ट करता है.

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

Onload

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

MDN

राउंड ट्रिप टाइम

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

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

एक्सपेरिमेंट के तौर पर उपलब्ध मेट्रिक

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

सॉफ़्ट नेविगेशन की परफ़ॉर्मेंस की अहम जानकारी देने वाली एक्सपेरिमेंटल मेट्रिक

अक्टूबर 2026 की रिलीज़ में, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली मेट्रिक के एक्सपेरिमेंटल वर्शन पेश किए गए थे. इनमें सॉफ्ट नेविगेशन शामिल हैं:

  • experimental_largest_contentful_paint_with_softnavs
  • experimental_interaction_to_next_paint_with_softnavs
  • experimental_cumulative_layout_shift_with_softnavs

इन मेट्रिक में, पेज के पूरी तरह लोड होने और सॉफ़्ट नेविगेशन, दोनों शामिल हैं.

ज़्यादा जानकारी के लिए, Chrome के लिए उपयोगकर्ता अनुभव से जुड़ी रिपोर्ट में एक्सपेरिमेंट के तौर पर Core Web Vitals मेट्रिक लॉन्च करना लेख पढ़ें.

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

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

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

लोकप्रियता

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

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

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

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

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

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

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

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

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