नेविगेशन के टाइप अब 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 notRestoredReasons API से यह पता चल सकता है कि किसी पेज को bfcache से लोड क्यों नहीं किया जा सका.

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% नेविगेशन (पेज लोड) ब्राउज़र के bfcache से दिखाए गए थे. इसी तरह, कुछ दूसरे अंश पेज लोड करने के ऑप्टिमाइज़ेशन के अवसरों की पहचान करने में मदद कर सकते हैं. ध्यान दें कि किसी भी की (जिसमें यूआरएल या ऑरिजिन और फ़ॉर्म फ़ैक्टर का कॉम्बिनेशन शामिल है) के लिए, navigation_types फ़्रैक्शन का कुल योग करीब 1.0 होगा.

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

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

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

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 की ज़्यादा जानकारी वाली टेबल से, नेविगेशन_types के 10k सबसे लोकप्रिय ऑरिजिन के फ़्रैक्शन को एक्सट्रैक्ट करता है:

• हम यहां 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 की मदद से, पेज लोड का कितना हिस्सा पहले से ही दिखाया जा रहा है. इसे 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 रेट ज़्यादा होने की वजह, bfcache के कम इस्तेमाल से नहीं है. बल्कि, यह इस बात से पता चलता है कि उपयोगकर्ता फ़ोन पर, पेज पर आगे और पीछे कैसे नेविगेट करते हैं.

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

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

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

नतीजा

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

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

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