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

Barry Pollard

Johannes Henkel

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

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

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

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

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

CrUX नीचे टेबल में दिए गए नेविगेशन के प्रकारों को अलग करता है:

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

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

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

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

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

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

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

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

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

एपीआई में नेविगेशन टाइप देखने के लिए, अनुरोध में 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 दिन, अलग से 7 दिन) के लिए इतिहास उपलब्ध है. पूरी तरह से भर जाने के बाद, यह सभी 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 के बीच एक मज़बूत सांख्यिकीय सहसंबंध (ρ=0.87)—नीचे दिए गए प्लॉट में दिखाया है—और back_forward_cache और good_lcp_density के बीच एक मध्यम सहसंबंध (ρ=0.29) है.

bfcache के इस्तेमाल के लिए इंस्टैंट पेज लोड का सहसंबंध

इस विश्लेषण के लिए 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

device	navigation_types_back_forward
phone	0.0663
desktop	0.0179
tablet	0.0009

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

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

device	back_forward_cache_hit_rate
phone	0.6239
desktop	0.6805
tablet	0.7353

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

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

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

CrUX डैशबोर्ड में मौजूद नेविगेशन टाइप

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

नतीजा

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

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

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