एलसीपी इमेज के सब-पार्ट और आरटीटी की जानकारी अब CrUX में उपलब्ध है

Barry Pollard

Johannes Henkel

पब्लिश करने की तारीख: 11 फ़रवरी, 2025

Chrome उपयोगकर्ता अनुभव रिपोर्ट (CrUX) के फ़रवरी 2025 के रिलीज़ में, कई नई और बदली हुई मेट्रिक शामिल हैं:

• सबसे बड़े कॉन्टेंटफ़ुल पेंट (एलसीपी) इमेज के सबसे छोटे हिस्से और संसाधन के टाइप
• दोतरफ़ा यात्रा के समय (आरटीटी) की जानकारी
• असरदार कनेक्शन टाइप (ईसीटी) डाइमेंशन को हटाना

इनमें से हर रिपोर्ट, CrUX में उपलब्ध ऑरिजिन और यूआरएल की परफ़ॉर्मेंस मेट्रिक के बारे में ज़्यादा जानकारी देती है. इस पोस्ट में हम इस बारे में पूरी जानकारी देंगे.

एलसीपी की गड़बड़ी की जानकारी

हमने Google I/O 2022 में एलसीपी के सब-पार्ट के कॉन्सेप्ट को पहली बार पेश किया था. यह एक असरदार तकनीक है, जिसकी मदद से इमेज एलसीपी वाले पेजों के लिए एलसीपी के समय को छोटे कॉम्पोनेंट में बांटा जा सकता है. इससे यह पक्का किया जा सकता है कि एलसीपी के ज़्यादा समय की सही वजहों को ऑप्टिमाइज़ करने के लिए, आपका समय बर्बाद न हो.

उस बातचीत में HTTP Archive लैब के डेटा का विश्लेषण करने से पता चला कि इमेज डाउनलोड होने में लगने वाला समय, एलसीपी के लोड होने में लगने वाले समय का सबसे छोटा हिस्सा होता है. लैब के कई टूल, इमेज के फ़ॉर्मैट और साइज़ को ऑप्टिमाइज़ करने के लिए सलाह देते हैं. इससे, इमेज को डाउनलोड करने में लगने वाला समय कम होता है और परफ़ॉर्मेंस बेहतर होती है. इन टूल में Google का Lighthouse भी शामिल है. विश्लेषण से पता चला है कि यह सलाह सही है, लेकिन इस पर ज़्यादा ध्यान दिया गया है. साथ ही, ब्राउज़र को इमेज ढूंढने और उसे डाउनलोड करने में लगने वाले समय की समस्या ज़्यादा बड़ी थी.

लैब डेटा का विश्लेषण करना फ़ायदेमंद हो सकता है. हालांकि, असल ज़िंदगी में वेब का इस्तेमाल अलग-अलग तरीके से किया जा सकता है. इसलिए, फ़ील्ड डेटा के लिए इन सब-पार्ट को देखना ज़रूरी है. पिछले साल पब्लिश की गई एक पोस्ट में, फ़ील्ड डेटा की मदद से एलसीपी को ऑप्टिमाइज़ करने के तरीके के बारे में आम तौर पर होने वाली गलतफ़हमी की पुष्टि की गई थी.

एलसीपी इमेज के सब-पार्ट

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

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

यह डेटा, फ़रवरी 2025 से CrUX API और CrUX History API में जोड़ा गया है. ध्यान दें: यह डेटा BigQuery में नहीं जोड़ा गया है. लॉन्च के समय, CrUX History API में दो हफ़्ते का डेटा होता है. यह समय के साथ बढ़कर, 25 हफ़्ते का हो जाएगा. एपीआई, हर सब-पार्ट के 75वें प्रतिशत के तौर पर डेटा उपलब्ध कराते हैं. इसे मिलीसेकंड में दिखाया जाता है.

उदाहरण के लिए, PHONE पेज व्यू के लिए https://web.dev/ की एलसीपी इमेज के सब-पार्ट पाने के लिए, इस curl कमांड का इस्तेमाल किया जा सकता है. इसके लिए, API_KEY को अपनी पसंद के हिसाब से किसी कीवर्ड से बदलें:

curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
  --header 'Content-Type: application/json' \
  --data '{ "formFactor": "PHONE",
            "url": "https://web.dev/",
            "metrics": [
              "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"]}'

इसके बाद, आपको कुछ ऐसा दिखेगा:

{
  "record": {
    "key": {
      "formFactor": "PHONE",
      "url": "https://web.dev/"
    },
    "metrics": {
      "largest_contentful_paint_image_element_render_delay": {
        "percentiles": {
          "p75": 2088
        }
      },
      "largest_contentful_paint_image_resource_load_delay": {
        "percentiles": {
          "p75": 828
        }
      },
      "largest_contentful_paint_image_resource_load_duration": {
        "percentiles": {
          "p75": 417
        }
      },
      "largest_contentful_paint_image_time_to_first_byte": {
        "percentiles": {
          "p75": 2385
        }
      }
    },
    "collectionPeriod": {
      "firstDate": {
        "year": 2025,
        "month": 1,
        "day": 12
      },
      "lastDate": {
        "year": 2025,
        "month": 2,
        "day": 8
      }
    }
  }
}

इस डेटा को शामिल करने के लिए, हमने CrUX विज़ुअलाइज़ेशन टूल को अपडेट किया है. साथ ही, हमें उम्मीद है कि CrUX API का इस्तेमाल करने वाले तीसरे पक्ष के अन्य टूल भी इस अहम डेटा को दिखाएंगे:

CrUX विज़ुअलाइज़ेशन में एलसीपी इमेज के सब-पार्ट.

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

हर सब-पार्ट में ज़्यादा वैल्यू, अलग-अलग समस्याओं का संकेत देती हैं:

• पहले बाइट का समय (टीटीएफ़बी) ज़्यादा होने का मतलब आम तौर पर सर्वर, नेटवर्क या रीडायरेक्ट से जुड़ी समस्याओं से है. इस बारे में टीटीएफ़बी को ऑप्टिमाइज़ करना में बताया गया है.
• संसाधन लोड होने में लगने वाले समय की ज़्यादा वैल्यू का मतलब है कि ब्राउज़र को एलसीपी इमेज का पता देर से चला. उदाहरण के लिए, क्लाइंट-साइड JavaScript से इंजेक्ट की गई ऐसी एलसीपी इमेज जिसे चलने में थोड़ा समय लगता है.
• रिसॉर्स लोड होने में लगने वाला समय ज़्यादा होने पर, आपको इमेज के डाउनलोड साइज़ को कम करना चाहिए.
• एलिमेंट रेंडर होने में लगने वाला ज़्यादा समय तब होता है, जब इमेज उपलब्ध हो (शायद <link rel=preload> के ज़रिए, लेकिन लंबे समय से इस्तेमाल न की गई हो—आम तौर पर, इमेज दिखाने के लिए क्लाइंट-साइड JavaScript की ज़रूरत होती है.

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

हमें उम्मीद है कि इस डेटा को CrUX में ऑरिजिन और यूआरएल, दोनों लेवल पर उपलब्ध कराने से (आवश्यक शर्तों के मुताबिक), साइटों को अपनी एलसीपी मेट्रिक को ऑप्टिमाइज़ करने में आसानी होगी.

एलसीपी रिसॉर्स टाइप

सब-पार्ट को इमेज के एलसीपी के लिए सबसे अच्छी तरह से देखा जाता है. इसलिए, CrUX इस डेटा को सिर्फ़ उन पेजों तक सीमित करता है जिनमें इमेज होती हैं. इसलिए, यह समझना ज़रूरी है कि आपके कितने एलसीपी, टेक्स्ट एलसीपी के बजाय इमेज एलसीपी हैं. जैसे, <h1> हेडिंग और लंबे पैराग्राफ़.

एलसीपी इमेज के सब-पार्ट के अलावा, CrUX API में अब रिसॉर्स का ब्रेकडाउन भी शामिल है. इससे, टेक्स्ट और इमेज के बीच एलसीपी पेज लोड के बंटवारे की जानकारी मिलती है.

उदाहरण के लिए, PHONE पेज व्यू के लिए https://web.dev/ के एलसीपी रिसॉर्स टाइप पाने के लिए, इस curl कमांड का इस्तेमाल किया जा सकता है. इसके लिए, API_KEY को अपनी पसंद के हिसाब से किसी कीवर्ड से बदलें:

curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
  --header 'Content-Type: application/json' \
  --data '{ "formFactor": "PHONE",
            "url": "https://web.dev/",
            "metrics": ["largest_contentful_paint_resource_type"]}'

इसके बाद, आपको कुछ ऐसा दिखेगा:

{
  "record": {
    "key": {
      "formFactor": "PHONE",
      "url": "https://web.dev/"
    },
    "metrics": {
      "largest_contentful_paint_resource_type": {
        "fractions": {
          "image": 0.0155,
          "text": 0.9845
        }
      }
    },
    "collectionPeriod": {
      "firstDate": {
        "year": 2025,
        "month": 1,
        "day": 12
      },
      "lastDate": {
        "year": 2025,
        "month": 2,
        "day": 8
      }
    }
  }
}

इस डेटा को दिखाने के लिए, CrUX विज़ुअलाइज़ेशन को भी अपडेट किया गया है:

CrUX विज़ुअलाइज़ेशन में LCP संसाधन टाइप

उदाहरण के लिए, web.dev के होम पेज के लिए, हम देख सकते हैं कि 98.5% एलसीपी, असल में टेक्स्ट एलसीपी थे. इसलिए, इस पेज के लिए एलसीपी इमेज के सब-पार्ट कम काम के हैं. ऐसे में, हम ओरिजनल टीटीएफ़बी और एफ़सीपी मेट्रिक का इस्तेमाल, गड़बड़ी के बारे में बेहतर जानकारी देने वाले ब्रेकडाउन के तौर पर कर सकते हैं.

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

एलसीपी संसाधन टाइप, एलसीपी को समझने और बेहतर बनाने के लिए एक और काम का डाइग्नोस्टिक्स टूल है. खास तौर पर, यह जानने के लिए कि एलसीपी इमेज के सब-पार्ट कितने काम के हैं.

आरटीटी की गड़बड़ी की जानकारी

हमने आरटीटी मेट्रिक को भी बड़ा किया है. इसे पहली बार अगस्त 2024 में लॉन्च किया गया था.

आरटीटी के तीन ग्रुप

हमने CrUX API में तीन ग्रुप वाले बाइन जोड़े हैं, जो आरटीटी डेंसिटी के तीन ग्रुप दिखाते हैं:

नेटवर्क लेटेंसी	शुरू करें	बंद करें
कम	0 मिलीसेकंड	75 मिलीसेकंड से कम
सामान्य	75 मिलीसेकंड	275 मिलीसेकंड से कम
ज़्यादा	275 मिलीसेकंड	∞

ये बाइन, ईसीटी की पिछली कैटगरी से ज़्यादा जानकारी देने वाले हैं. पिछली कैटगरी में, 270 मिलीसेकंड से कम समय के सभी ट्रांज़िशन को 4g कैटगरी में रखा जाता था. इन कैटगरी के लॉन्च होने के बाद, नेटवर्किंग टेक्नोलॉजी में काफ़ी बदलाव हुए हैं. इस वजह से, ज़्यादातर साइटों को उस कैटगरी में ज़्यादातर ट्रैफ़िक मिला. इससे, कैटगरी को बांटने की यह सुविधा कम काम की हो गई.

अहम जानकारी: राउंड ट्रिप टाइम, उपयोगकर्ताओं की हाल ही की इंटरनेट गतिविधि के आधार पर, आपकी साइट से उनकी नेटवर्क कनेक्टिविटी का मेज़र होता है, न कि साइट का.

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

ये बाइन CrUX API में उपलब्ध हैं. उदाहरण के लिए, PHONE पेज व्यू के लिए web.dev (API_KEY को अपनी पसंद के कीवर्ड से बदलें):

curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
  --header 'Content-Type: application/json' \
  --data '{ "formFactor": "PHONE",
            "url": "https://web.dev/",
            "metrics": ["round_trip_time"]}'

इससे इस तरह का नतीजा मिलता है:

{
  "record": {
    "key": {
      "formFactor": "PHONE",
      "url": "https://web.dev/"
    },
    "metrics": {
      "round_trip_time": {
        "histogram": [
          {
            "start": 0,
            "end": 75,
            "density": 0.1524
          },
          {
            "start": 75,
            "end": 275,
            "density": 0.6641
          },
          {
            "start": 275,
            "density": 0.1835
          }
        ],
        "percentiles": {
          "p75": 230
        }
      }
    },
    "collectionPeriod": {
      "firstDate": {
        "year": 2025,
        "month": 1,
        "day": 12
      },
      "lastDate": {
        "year": 2025,
        "month": 2,
        "day": 8
      }
    }
  }
}

डिस्ट्रिब्यूशन चुनने पर, CrUX विज़ुअलाइज़ेशन में बीन दिखते हैं:

CrUX विज़ुअलाइज़ेशन में आरटीटी डेटा.

BigQuery में आरटीटी

हमने CrUX API में RTT मेट्रिक को बड़ा करके, ट्राइ-बिन को शामिल किया है. साथ ही, हमने हर महीने के BigQuery डेटासेट में भी यह डेटा उपलब्ध कराया है. इसमें रॉ टेबल में 25 मिलीसेकंड की बकेट में पूरा हिस्टोग्राम और मटीरियलाइज़ की गई टेबल में ट्राइ-बिन और p75 वैल्यू शामिल हैं.

इससे, CrUX API में उपलब्ध तीन-बिन के अलावा, डेटा के डिस्ट्रिब्यूशन को बेहतर तरीके से समझा जा सकता है. इससे हमें ईसीटी का ब्रेकडाउन फिर से बनाने में भी मदद मिलती है. इस ब्रेकडाउन को इस महीने से CrUX से हटा दिया गया है. इस बारे में हम आगे ज़्यादा जानकारी देंगे. साथ ही, 4g के लिए, 270 मिलीसेकंड के थ्रेशोल्ड के बजाय 275 मिलीसेकंड का थ्रेशोल्ड इस्तेमाल किया जाएगा. ईसीटी ब्रेकडाउन (अब आरटीटी डेटा से सोर्स किया गया) CrUX BigQuery की मेटालाइज़ की गई टेबल में उपलब्ध रहेगा, ताकि CrUX डैशबोर्ड जैसे टूल इस ब्रेकडाउन को दिखाना जारी रख सकें.

BigQuery डेटासेट में, देश के हिसाब से डेटा भी शामिल होता है. यह डेटा, ISO 3166-1 के मुताबिक होता है. इससे ज़्यादा बेहतर तरीके से विश्लेषण किया जा सकता है. इससे यह समझने में मदद मिलती है कि कुछ उपयोगकर्ताओं के लिए परफ़ॉर्मेंस मेट्रिक खराब क्यों हैं. उदाहरण के लिए, https://www.google.com का डेटा देखकर, हम Google फ़ोन इस्तेमाल करने वाले लोगों का डेटा देख सकते हैं:

SELECT
  `chrome-ux-report`.experimental.GET_COUNTRY(country_code) AS geo,
  least(500, p75_rtt) AS capped_p75_rtt,
  p75_rtt
FROM
  `chrome-ux-report.materialized.country_summary`
WHERE
  origin = 'https://www.google.com' AND
  yyyymm = 202501 AND
  device = 'phone'
ORDER BY
  p75_rtt DESC,
  country_code

इसके बाद, हम जियो मैप पर डेटा को विज़ुअलाइज़ करते हैं:

https://www.google.com
के लिए, देश के हिसाब से फ़ोन आरटीटी का 75वां पर्सेंटाइल(इंटरैक्टिव चार्ट के साथ सोर्स डेटा).

इस कार्ड से पता चलता है कि दुनिया के ज़्यादातर हिस्सों (खास तौर पर "पश्चिमी देशों") में आरटीटी बहुत अच्छा है. हालांकि, सहारा के दक्षिणी अफ़्रीका, मध्य पूर्व के कुछ हिस्सों, और एशिया के कुछ हिस्सों में आरटीटी ज़्यादा है. असल में, ग्राफ़ में आरटीटी को 500 मिलीसेकंड तक सीमित किया गया है, क्योंकि पूरे डेटा का इस्तेमाल करने से कलर में बदलाव होता है. खास तौर पर, इरिट्रिया के लिए 75वें पर्सेंटाइल में 3,850 मिलीसेकंड का डेटा है!

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

साइटें, आरटीटी को सीधे तौर पर बेहतर नहीं बना सकतीं. हालांकि, साइट पर आने वाले लोगों के लिए यह डेटा उपलब्ध कराने से, दुनिया भर में आपकी साइट के उपयोगकर्ताओं को बेहतर तरीके से समझा जा सकता है. इससे आने वाले समय में, विश्लेषण के कई अवसर भी मिलेंगे. हमें उम्मीद है कि रिसर्चर को इस डेटासेट से दिलचस्प जानकारी मिलेगी.

ईसीटी डाइमेंशन को हटाना

फ़रवरी 2025 की रिलीज़ में आखिरी बदलाव यह है कि BigQuery से असरदार कनेक्शन टाइप (ईसीटी) डाइमेंशन को हटा दिया जाएगा. हमने सितंबर 2024 से एपीआई से आरटीटी को हटा दिया था, जब हमने इसके बदले आरटीटी मेट्रिक को लॉन्च किया था.

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

एक अहम अंतर यह है कि ECT एक CrUX डाइमेंशन था. इसका मतलब है कि अन्य मेट्रिक को ECT के हिसाब से सेगमेंट किया जा सकता था. आरटीटी, डाइमेंशन के बजाय CrUX मेट्रिक है. इसलिए, उदाहरण के लिए, आरटीटी के हिसाब से एलसीपी नहीं देखा जा सकता. हालांकि, अन्य डाइमेंशन (डिवाइस टाइप और देश) के हिसाब से आरटीटी देखे जा सकते हैं.

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

डाइमेंशन की संख्या कम करने से, डेटा का सेगमेंट कम हो जाता है. इसलिए, इन ज़रूरी शर्तों को पूरा करने वाले ऑरिजिन की संख्या बढ़ जाती है. जनवरी में, हमने 68.1% ऑरिजिन के लिए आईएनपी की रिपोर्ट दी थी. वहीं, दिसंबर के डेटासेट के लिए, हमने सिर्फ़ 64.5% ऑरिजिन के लिए आईएनपी की रिपोर्ट दी थी. यह सुविधा, इस रिलीज़ में नेविगेशन टाइप, एलसीपी के सब-पार्ट, और रिसॉर्स टाइप पर भी लागू होती है. ईसीटी डाइमेंशन हटाने से, इन सभी को फ़ायदा मिलता है. CrUX API में, ज़्यादा कवरेज की सुविधा फ़रवरी की शुरुआत से लागू हो गई है.

ईसीटी कॉलम, पिछले डेटासेट के साथ एक जैसा रखने के लिए BigQuery में बने रहेंगे. साथ ही, मेटालाइज़ किए गए व्यू में ईसीटी डेटा उपलब्ध रहेगा. हालांकि, यह डेटा आरटीटी की जानकारी के आधार पर होगा. इसमें आरटीटी p75 और ट्राई-बिन के साथ-साथ 3g और 4g के लिए पांच मिलीसेकंड का अंतर होगा.

नतीजा

सार्वजनिक CrUX डेटासेट में ज़्यादा मेट्रिक जोड़ने से, साइट के मालिकों और रिसर्चर को ज़्यादा जानकारी मिलती है. इससे, परफ़ॉर्मेंस से जुड़ी समस्याओं का पता लगाने और उन्हें ठीक करने में मदद मिलती है.

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

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