मार्च 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 का यह मतलब हो सकता है कि 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
मेट्रिक को स्टैक किए गए बार के तौर पर दिखाया गया है:
![स्टैक किया गया बारचार्ट, जिसमें पिछले तीन हफ़्तों के दौरान नेविगेट करने के अलग-अलग तरीकों का इतिहास दिखाया गया है. इसमें से ज़्यादातर नेविगेशन 'नेविगेट' करता है टाइप किया गया है और पिछले तीन हफ़्तों में कोई बड़ा बदलाव नहीं हुआ है.](https://developer.chrome.com/static/blog/crux-navigation-types/image/navigation-types-history-chart.png?authuser=19&hl=hi)
पिछले स्क्रीनशॉट में, इतिहास सिर्फ़ तीन कलेक्शन अवधियों के लिए उपलब्ध है. हर अवधि के लिए 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) के बीच एक सामान्य संबंध है.
![कोरिलेशन चार्ट में, इंस्टैंट पेज लोड होने वाले फ़्रैक्शन और बीएफ़कैश मेमोरी पेज लोड के हिस्से के बीच गहरा संबंध दिखाया गया है](https://developer.chrome.com/static/blog/crux-navigation-types/image/instant-lcp-bfcache-correlation.png?authuser=19&hl=hi)
इस विश्लेषण के लिए 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% पेज लोड होने में फ़ोन पर नेविगेशन टाइप 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
device |
back_forward_cache_hit_rate |
---|---|
phone |
0.6239 |
desktop |
0.6805 |
tablet |
0.7353 |
ऐसा लगता है कि फ़ोन पर back_forward
की दर ज़्यादा होने की वजह, कम कैश मेमोरी का इस्तेमाल नहीं है. हालांकि, इससे यह पता चलता है कि उपयोगकर्ता किस तरह फ़ोन पर आगे और पीछे जाते हैं.
CrUX डैशबोर्ड में नेविगेशन के टाइप
नेविगेशन के टाइप देखने का सबसे आसान तरीका CrUX डैशबोर्ड में है, जिसे इस लिंक से ऑरिजिन के लिए ऐक्सेस किया जा सकता है. जैसा कि आप नीचे दिए गए स्क्रीनशॉट से देख सकते हैं कि शुरुआत में सिर्फ़ एक महीने का डेटा उपलब्ध है, लेकिन समय के साथ-साथ डेटा का इतिहास दिखने लगेगा. इससे आपको हर महीने टाइप के हिसाब से होने वाले बदलावों को देखने में मदद मिलेगी.
![CrUX डैशबोर्ड में, नेविगेशन टाइप के डिस्ट्रिब्यूशन वाली स्क्रीन का स्क्रीनशॉट, जिसमें एक महीने का डेटा दिख रहा है.](https://developer.chrome.com/static/blog/crux-navigation-types/image/crux-dashboard-navigation-types.png?authuser=19&hl=hi)
जैसा कि आपको यह भी दिख सकता है कि हमने डैशबोर्ड के इस पेज में सबसे ऊपर, तेज़ नेविगेशन के उन टाइप को हाइलाइट किया है जिन्हें साइट को ऑप्टिमाइज़ करना चाहिए.
नतीजा
हमें उम्मीद है कि CrUX में दी गई नेविगेशन टाइप की जानकारी आपके लिए काम की होगी. साथ ही, इससे आपको अपनी साइट की परफ़ॉर्मेंस को समझने और उसे ऑप्टिमाइज़ करने में मदद मिलेगी. यह पक्का करके कि एचटीटीपी कैश मेमोरी, बीएफ़कैश, और प्रीरेंडरिंग का बेहतर तरीके से इस्तेमाल किया जा रहा है, साइटें ऐसे पेज लोड के मुकाबले ज़्यादा तेज़ी से पेज लोड कर सकती हैं जिनके लिए सर्वर पर वापस जाने की ज़रूरत होती है.
हमें अलग-अलग CrUX के सभी ऐक्सेस पॉइंट पर डेटा उपलब्ध कराने में भी खुशी हो रही है. इससे उपयोगकर्ता अपनी ज़रूरत के हिसाब से डेटा का इस्तेमाल कर सकेंगे. साथ ही, यह देख पाएंगे कि CrUX API में, यूआरएल के हिसाब से किस तरह का डेटा मौजूद है.
हमें सोशल मीडिया पर या CrUX चर्चा ग्रुप में, CrUX के अलावा इस बदलाव के बारे में सुझाव, शिकायत या राय जानकर खुशी होगी.