नेविगेशन के टाइप अब CrUX में उपलब्ध हैं

Barry Pollard

Johannes Henkel

मार्च 2024 के डेटासेट से, Chrome के लिए उपयोगकर्ता अनुभव से जुड़ी रिपोर्ट (CrUX) में navigation_types मेट्रिक शामिल की गई है. इससे क्वेरी किए गए डाइमेंशन के लिए, पेज लोड के नेविगेशन टाइप के बारे में एग्रीगेट किए गए आंकड़े मिलते हैं.

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

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

navigation_types मेट्रिक, रोज़ के CrUX API, CrUX History API (शुरुआत में तीन हफ़्तों का इतिहास उपलब्ध है और अगले छह महीनों में हर हफ़्ते इसे फ़ुल कवरेज में बढ़ाया जा सकता है), नए CrUX BigQuery डेटासेट, और CrUX डैशबोर्ड में उपलब्ध है. इतिहास का इस्तेमाल करने से, साइट के मालिक समय के साथ नेविगेशन टाइप के इस्तेमाल में हुए बदलावों को देख सकते हैं. इससे सुधारों को ट्रैक किया जा सकता है (उदाहरण के लिए, bfcache ब्लॉकेज हटाना). इसकी मदद से, मेट्रिक में हुए बदलावों को आसानी से समझा जा सकता है, भले ही साइटों में कोई बदलाव न किया गया हो.

CrUX में किस तरह के नेविगेशन उपलब्ध हैं?

CrUX, इस टेबल में इन नेविगेशन टाइप को अलग करता है:

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

CrUX में नेविगेशन के टाइप की सीमाएं

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

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

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

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

CrUX API में नेविगेशन के टाइप

एपीआई में नेविगेशन टाइप देखने के लिए, अनुरोध में navigation_types मेट्रिक शामिल करें या कोई मेट्रिक सेट न करें, ताकि सभी मेट्रिक शामिल हो सकें:

export API_KEY="[YOUR_API_KEY]"
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=$API_KEY" \
  --header 'Content-Type: application/json' \
  --data '{"origin": "https://example.com", metrics: ["navigation_types"]}'

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

{
  "record": {
    "key": {  "origin": "https://example.com" },
    "metrics": {
      "navigation_types": {
        "fractions": {
          "navigate": 0.5335,
          "navigate_cache": 0.2646,
          "reload": 0.0885,
          "restore": 0.0023,
          "back_forward": 0.0403,
          "back_forward_cache": 0.0677,
          "prerender": 0.0031
        }
      }
    },
    "collectionPeriod": {
      "firstDate": { "year": 2024, "month": 3, "day": 6 },
      "lastDate": { "year": 2024, "month": 4, "day": 2 }
    }
  }
}

इसके जवाब में, CrUX, navigation_types मेट्रिक को एक ऑब्जेक्ट के तौर पर रिपोर्ट करता है. इसमें हर तरह के नेविगेशन के लिए, पेज लोड के कुछ हिस्से शामिल होते हैं. किसी कुंजी के लिए हर अंश, 0.0 (पेज लोड का 0% हिस्सा) से 1.0 (100% पेज लोड को दिखाता है) के बीच का मान होता है.

इस जवाब से पता चलता है कि 6 मार्च, 2024 से शुरू होने वाली, डेटा इकट्ठा करने की अवधि के दौरान, 2 अप्रैल, 2024 तक से लेकर 6.77% नेविगेशन (पेज लोड) ब्राउज़र के बीएफ़कैश मेमोरी में सेव हुए थे. इसी तरह, कुछ दूसरे अंश पेज लोड करने के ऑप्टिमाइज़ेशन के अवसरों की पहचान करने में मदद कर सकते हैं. ध्यान दें कि किसी भी कुंजी के लिए (जिसमें यूआरएल या ऑरिजिन और डिवाइस का नाप या आकार शामिल है), navigation_types फ़्रैक्शन को करीब-करीब 1.0 जोड़ दिया जाएगा.

CrUX History API में नेविगेशन के टाइप

CrUX History API की मदद से, एक फ़्रैक्शन में ज़्यादा से ज़्यादा 25 डेटा पॉइंट के साथ नेविगेशन टाइप के लिए टाइम सीरीज़ उपलब्ध कराई जा सकती है. इससे समय के साथ इन फ़्रैक्शन को विज़ुअलाइज़ किया जा सकता है. अपने अनुरोध को CrUX API से CrUX History API में बदलने के लिए, इसे queryRecord के बजाय, queryHistoryRecord एंडपॉइंट से चलाएं. उदाहरण के लिए, हमारे CrUX इतिहास के Colab में, navigation_types मेट्रिक को स्टैक किए गए बार के तौर पर दिखाया गया है:

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

CrUX BigQuery में नेविगेशन के टाइप

CrUX BigQuery टेबल में अब navigation_type रिकॉर्ड शामिल है, जो हर टाइप का है. वहीं, खास जानकारी वाले व्यू में कई navigation_types_* कॉलम हैं—हर तरह के कॉलम के लिए एक कॉलम.

ज़्यादा जानकारी देने वाली टेबल

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

उदाहरण के लिए, हमने back_forward_cache अंश और उसके संबंध को देखा कि कितनी बार पेज तुरंत लोड हो गए (instant_lcp_density को एलसीपी <= 200 मि॰से॰ के तौर पर बताया गया) और अच्छा एलसीपी कितनी बार देखा गया (good_lcp_density को एलसीपी <= 2500 मि॰से॰ के तौर पर परिभाषित किया गया). हमने back_forward_cache और instant_lcp_density (r=0.87) के बीच बहुत अच्छा सह-संबंध देखा, जिसे नीचे दिए गए प्लॉट में दिखाया गया है. साथ ही, back_forward_cache और good_lcp_density (r=0.29) के बीच एक सामान्य संबंध है.

इस विश्लेषण के लिए Colab के बारे में सही जानकारी दी गई है; हम यहां सिर्फ़ उस क्वेरी के बारे में बात करेंगे जो CrUX BigQuery में मौजूद ज़्यादा जानकारी वाली टेबल से, 10 हज़ार सबसे लोकप्रिय ऑरिजिन के लिए नेविगेशन_types फ़्रैक्शन को एक्सट्रैक्ट करता है:

• हम यहां all.202403 टेबल ऐक्सेस करते हैं (FROM-क्लॉज़ देखें). साथ ही, phone के लिए form_factor फ़िल्टर करते हैं. साथ ही, टॉप 10 हज़ार लोकप्रिय ऑरिजिन के लिए, लोकप्रियता की रैंक <= 10,000 वाले ऑरिजिन चुनें (WHERE क्लॉज़ देखें).
• BigQuery में navigation_types मेट्रिक की क्वेरी करते समय, navigation_types भिन्नों के कुल योग से भाग देना ज़रूरी है, क्योंकि वे सिर्फ़ हर ऑरिजिन के हिसाब से जुड़ेंगे, न कि हर ऑरिजिन के हिसाब से.
• सभी ऑरिजिन में navigation_types नहीं होगा. इसलिए, SAVE_DIVIDE का इस्तेमाल करना अच्छा है.

WITH tmp AS (
  SELECT
    origin,
    SUM(navigation_types.navigate.fraction) AS navigate,
    SUM(navigation_types.navigate_cache.fraction) AS navigate_cache,
    SUM(navigation_types.reload.fraction) AS reload,
    SUM(navigation_types.restore AS restore,
    SUM(navigation_types.back_forward.fraction) AS back_forward,
    SUM(navigation_types.back_forward_cache.fraction) AS back_forward_cache,
    SUM(navigation_types.prerender.fraction) AS prerender,
    SUM(navigation_types.navigate.fraction
      + navigation_types.navigate_cache.fraction
      + navigation_types.reload.fraction
      + navigation_types.restore.fraction
      + navigation_types.back_forward.fraction
      + navigation_types.back_forward_cache.fraction
      + navigation_types.prerender.fraction) AS total
  FROM
    `chrome-ux-report.all.202403`
  WHERE
    experimental.popularity.rank <= 10000 AND
    form_factor.name = 'phone'
  GROUP BY
    origin
)

SELECT
  origin,
  ROUND(SAFE_DIVIDE(navigate, total), 4) AS navigate,
  ROUND(SAFE_DIVIDE(navigate_cache, total), 4) AS navigate_cache,
  ROUND(SAFE_DIVIDE(reload, total), 4) AS reload,
  ROUND(SAFE_DIVIDE(restore, total), 4) AS restore,
  ROUND(SAFE_DIVIDE(back_forward, total), 4) AS back_forward,
  ROUND(SAFE_DIVIDE(back_forward_cache, total), 4) AS back_forward_cache,
  ROUND(SAFE_DIVIDE(prerender, total), 4) AS prerender
FROM
  tmp

मटीरियलाइज़्ड टेबल

जब जवाब काफ़ी हो, तो मटीरियल के बजाय टेबल पर क्वेरी करना अक्सर ज़्यादा आसान (और सस्ता) होता है. उदाहरण के लिए, नीचे दी गई क्वेरी, chrome-ux-report.materialized.device_summary टेबल से उपलब्ध navigation_types डेटा एक्सट्रैक्ट करती है. इस टेबल को महीने, शुरुआत की जगह, और डिवाइस के टाइप के हिसाब से चुना जाता है.

SELECT
  yyyymm,
  device,
  navigation_types_navigate,
  navigation_types_navigate_cache,
  navigation_types_reload,
  navigation_types_restore,
  navigation_types_back_forward,
  navigation_types_back_forward_cache,
  navigation_types_prerender
FROM
  chrome-ux-report.materialized.device_summary
WHERE
  origin = 'https://example.com' AND
  navigation_types_navigate IS NOT NULL
ORDER BY
  yyyymm DESC,
  device DESC

ध्यान दें कि हर पंक्ति में ये भिन्नों का योग 1.0 नहीं होगा, इसलिए हर भिन्न को उन परिणामों के योग से विभाजित करना होगा, जिनके बारे में क्वेरी की व्याख्या करनी है.

इसकी वजह यह है कि chrome-ux-report.materialized.device_summary में navigation_type फ़्रैक्शन, जैसे कि हिस्टोग्राम डेंसिटी—हर तारीख के हिसाब से ऑरिजिन और डिवाइस के बजाय हर ऑरिजिन और डिवाइस के लिए 1.0 जोड़ना होता है. इसकी मदद से, अलग-अलग डिवाइसों के लिए नेविगेशन टाइप का डिस्ट्रिब्यूशन देखा जा सकता है:

SELECT
  device,
  navigation_types_back_forward
FROM
  chrome-ux-report.materialized.device_summary
WHERE
  origin = 'https://www.google.com' AND
  yyyymm = 202403

क्वेरी के इस नतीजे में, फ़्रैक्शन, ऑरिजिन https://www.google.com के लिए पेज के लोड होने का प्रतिशत दिखाते हैं: इनमें से 6.63% पेज लोड होने में फ़ोन पर नेविगेशन टाइप back_forward, 1.79% डेस्कटॉप, और 0.09% टैबलेट पर नेविगेशन टाइप था.

phone पर काफ़ी ज़्यादा back_forward प्रतिशत यह बताता है कि हम इन पेज लोड को ऑप्टिमाइज़ करने की कोशिश कर सकते हैं, ताकि इन्हें बैक-कैश मेमोरी से दिखाया जा सके.

हालांकि, इस बात पर ध्यान देना भी ज़रूरी है कि bfcache यानी कि bfcache हिट रेट से पेज लोड का कितना हिस्सा पहले से ही दिखाया जा रहा है. इस क्वेरी से पता चलता है कि इस खास ऑरिजिन को पहले से ही अच्छी तरह से ऑप्टिमाइज़ किया गया हो सकता है, क्योंकि इसके > फ़ोन और डेस्कटॉप के लिए हिट रेट 60% है.

SELECT
  device,
  navigation_types_back_forward_cache /
    (navigation_types_back_forward + navigation_types_back_forward_cache)
    AS back_forward_cache_hit_rate
FROM
  chrome-ux-report.materialized.device_summary
WHERE
  origin = 'https://www.google.com' AND
  yyyymm = 202403

ऐसा लगता है कि फ़ोन पर back_forward की दर ज़्यादा होने की वजह, कम कैश मेमोरी का इस्तेमाल नहीं है. हालांकि, इससे यह पता चलता है कि उपयोगकर्ता किस तरह फ़ोन पर आगे और पीछे जाते हैं.

CrUX डैशबोर्ड में नेविगेशन के टाइप

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

जैसा कि आपको यह भी दिख सकता है कि हमने डैशबोर्ड के इस पेज में सबसे ऊपर, तेज़ नेविगेशन के उन टाइप को हाइलाइट किया है जिन्हें साइट को ऑप्टिमाइज़ करना चाहिए.

नतीजा

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

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

हमें सोशल मीडिया पर या CrUX चर्चा ग्रुप में, CrUX के अलावा इस बदलाव के बारे में सुझाव, शिकायत या राय जानकर खुशी होगी.