इंस्टैंट पेज नेविगेशन के लिए, Chrome में पेजों को पहले से रेंडर करना

Barry Pollard

Chrome की टीम ने, आने वाले समय में उपयोगकर्ता के नेविगेट करने की संभावना वाले पेजों को पहले से रेंडर करने की सुविधा को वापस लाया है.

प्री-रेंडर के बारे में खास जानकारी

पहले, Chrome में <link rel="prerender" href="/next-page"> संसाधन के बारे में जानकारी देने की सुविधा काम करती थी. हालांकि, यह सुविधा Chrome के अलावा अन्य ब्राउज़र में काम नहीं करती थी. साथ ही, यह एपीआई बहुत अच्छा नहीं था.

लिंक rel=prerender हिंट का इस्तेमाल करके, पेज को पहले से रेंडर करने की इस सुविधा को बंद कर दिया गया है. इसकी जगह, NoState Prefetch सुविधा का इस्तेमाल किया जा रहा है. यह सुविधा, आने वाले समय में खुलने वाले पेज के लिए ज़रूरी संसाधनों को फ़ेच करती है. हालांकि, यह पेज को पूरी तरह से पहले से रेंडर नहीं करती और न ही JavaScript को लागू करती है. NoState Prefetch, संसाधन लोड करने की प्रोसेस को बेहतर बनाकर पेज की परफ़ॉर्मेंस को बेहतर बनाने में मदद करता है. हालांकि, यह पेज को तुरंत लोड नहीं करेगा, जैसा कि पूरा पेज प्रीरेंडर करने की सुविधा करता है.

Chrome की टीम ने अब Chrome में, पेज को पहले से रेंडर करने की सुविधा को फिर से शामिल कर दिया है. मौजूदा इस्तेमाल से जुड़ी समस्याओं से बचने और आने वाले समय में पेज को पहले से रेंडर करने की सुविधा को बेहतर बनाने के लिए, पेज को पहले से रेंडर करने का यह नया तरीका, <link rel="prerender"...> सिंटैक्स का इस्तेमाल नहीं करेगा. यह सिंटैक्स, NoState Prefetch के लिए पहले से मौजूद है. हालांकि, आने वाले समय में इसे बंद कर दिया जाएगा.

किसी पेज को पहले से रेंडर कैसे किया जाता है?

किसी पेज को चार में से किसी एक तरीके से पहले से रेंडर किया जा सकता है. इन सभी तरीकों का मकसद, नेविगेशन को तेज़ बनाना है:

1. Chrome के पता बार (जिसे "ऑमनीबॉक्स" भी कहा जाता है) में कोई यूआरएल टाइप करने पर, Chrome आपके लिए पेज को अपने-आप प्री-रेंडर कर सकता है. ऐसा तब होता है, जब Chrome को आपके पिछले ब्राउज़िंग इतिहास के आधार पर यह पता चलता है कि आप उस पेज पर जा सकते हैं.
2. बुकमार्क बार का इस्तेमाल करने पर, Chrome किसी बुकमार्क बटन पर कर्सर को कुछ देर तक रोकने पर, पेज को अपने-आप प्री-रेंडर कर सकता है.
3. जब Chrome के पता बार में कोई खोज क्वेरी टाइप की जाती है, तो सर्च इंजन के निर्देश पर Chrome, खोज के नतीजों वाले पेज को अपने-आप प्री-रेंडर कर सकता है.
4. साइटें, अनुमान के नियमों वाले एपीआई का इस्तेमाल करके, प्रोग्राम के ज़रिए Chrome को बता सकती हैं कि किन पेजों को पहले से रेंडर करना है. यह <link rel="prerender"...> की जगह लेता है और साइटों को पेज पर अनुमान के नियमों के आधार पर, पेज को पहले से रेंडर करने की अनुमति देता है. ये पेजों पर स्टैटिक तौर पर मौजूद हो सकते हैं या पेज के मालिक के हिसाब से, JavaScript के ज़रिए डाइनैमिक तौर पर इंजेक्ट किए जा सकते हैं.

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

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

प्री-रेंडरिंग का असर

पेज को पहले से रेंडर करने की सुविधा से, पेज तुरंत लोड हो जाता है. इसकी जानकारी देने वाला वीडियो यहां दिया गया है:

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

भले ही, पेज पूरी तरह से लोड होने से पहले ही चालू हो जाए, लेकिन पेज लोड होने में लगने वाले समय को कम करने से, पेज लोड होने का अनुभव बेहतर हो जाता है. अगर पेज को पहले से रेंडर करने की प्रोसेस जारी है, तब लिंक चालू होने पर, पहले से रेंडर किया गया पेज मेन फ़्रेम पर चला जाएगा और लोड होना जारी रहेगा.

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

अपने आंकड़ों में परफ़ॉर्मेंस पर असर को मेज़र करने के तरीके के बारे में ज़्यादा जानने के लिए, परफ़ॉर्मेंस मेज़र करना सेक्शन देखें.

Chrome के पता बार में दिखने वाले सुझाव देखना

पहले इस्तेमाल के उदाहरण के लिए, chrome://predictors पेज पर यूआरएल के लिए Chrome के सुझाव देखे जा सकते हैं:

हरे रंग की लाइनें, प्री-रेंडरिंग को ट्रिगर करने के लिए काफ़ी भरोसे का संकेत देती हैं. इस उदाहरण में, "s" टाइप करने पर, आपको ज़्यादा कॉन्फ़िडेंस (अंबर) मिलता है. हालांकि, "sh" टाइप करने के बाद, Chrome को यह पता चल जाता है कि आप ज़्यादातर समय https://sheets.google.com पर जाते हैं.

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

इन अनुमान लगाने वाली टेक्नोलॉजी की मदद से, पता बार में सुझाए गए विकल्प भी दिखाए जाते हैं. इन विकल्पों को आपने देखा होगा:

Chrome, आपकी टाइपिंग और चुने गए विकल्पों के आधार पर, अपने अनुमान को लगातार अपडेट करता रहेगा.

• 50% से ज़्यादा कॉन्फ़िडेंस लेवल (अंबर में दिखाया गया) के लिए, Chrome डोमेन से पहले से कनेक्ट हो जाता है. हालांकि, वह पेज को पहले से रेंडर नहीं करता.
• 80% से ज़्यादा कॉन्फ़िडेंस लेवल (हरे रंग में दिखाया गया) के लिए, Chrome यूआरएल को पहले से रेंडर कर देगा.

Speculation Rules API

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

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["next.html", "next2.html"]
    }
  ]
}
</script>

इसके अलावा, दस्तावेज़ के नियमों (Chrome 121 से उपलब्ध) के हिसाब से भी, दस्तावेज़ में मौजूद लिंक पहले से रेंडर किए जा सकते हैं. ये नियम, href सिलेक्टर (यूआरएल पैटर्न एपीआई पर आधारित) या सीएसएस सिलेक्टर के आधार पर काम करते हैं:

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": {"href_matches": "/wp-admin"}},
        { "not": {"href_matches": "/*\\?*(^|&)add-to-cart=*"}},
        { "not": {"selector_matches": ".do-not-prerender"}},
        { "not": {"selector_matches": "[rel~=nofollow]"}}
      ]
    }
  }]
}
</script>

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

उत्सुकता

eagerness सेटिंग का इस्तेमाल यह बताने के लिए किया जाता है कि अनुमान कब ट्रिगर होने चाहिए. यह सेटिंग, खास तौर पर दस्तावेज़ के नियमों के लिए काम की होती है:

• immediate: इसका इस्तेमाल, अनुमान लगाने के लिए जल्द से जल्द किया जाता है. इसका मतलब है कि अनुमान लगाने के नियमों का पालन होते ही, इसका इस्तेमाल किया जाता है.
• eager: यह immediate सेटिंग की तरह ही काम करती है. हालांकि, आने वाले समय में हम इसे immediate और moderate के बीच में रखना चाहते हैं.
• moderate: अगर किसी लिंक पर कर्सर को 200 मिलीसेकंड तक रखा जाता है, तो यह अनुमान लगाता है. अगर pointerdown इवेंट पहले होता है, तो यह उस पर अनुमान लगाता है. साथ ही, मोबाइल पर जहां hover इवेंट नहीं होता है वहां भी यह अनुमान लगाता है.
• conservative: इससे पॉइंटर या टच डाउन का अनुमान लगाया जाता है.

list नियमों के लिए डिफ़ॉल्ट eagerness immediate है. moderate और conservative विकल्पों का इस्तेमाल करके, list नियमों को उन यूआरएल तक सीमित किया जा सकता है जिनसे उपयोगकर्ता किसी खास सूची के साथ इंटरैक्ट करता है. हालांकि, कई मामलों में where शर्त वाले document नियम ज़्यादा सही हो सकते हैं.

document नियमों के लिए डिफ़ॉल्ट eagerness conservative है. किसी दस्तावेज़ में कई यूआरएल हो सकते हैं. इसलिए, document नियमों के लिए immediate या eager का इस्तेमाल सावधानी से करना चाहिए. इसके बाद, Chrome की सीमाएं सेक्शन भी देखें.

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

moderate विकल्प एक मध्यम विकल्प है. कई साइटों को, अनुमान लगाने के इस नियम से फ़ायदा मिल सकता है. यह नियम, लिंक पर कर्सर को 200 मिलीसेकंड तक रखने या pointerdown इवेंट पर, लिंक को पहले से रेंडर कर देगा. यह अनुमान लगाने के नियमों को लागू करने का एक बुनियादी, लेकिन असरदार तरीका है:

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "href_matches": "/*"
    },
    "eagerness": "moderate"
  }]
}
</script>

प्रीफ़ेच

अनुमान लगाने के नियमों का इस्तेमाल, पेजों को पूरी तरह से प्री-रेंडर किए बिना, सिर्फ़ प्रीफ़ेच करने के लिए भी किया जा सकता है. आम तौर पर, यह प्री-रेंडरिंग की सुविधा इस्तेमाल करने का पहला अच्छा कदम हो सकता है:

<script type="speculationrules">
{
  "prefetch": [
    {
      "urls": ["next.html", "next2.html"]
    }
  ]
}
</script>

Chrome की सीमाएं

Chrome में, अनुमान लगाने के नियमों वाले एपीआई का ज़्यादा इस्तेमाल होने से रोकने के लिए पाबंदियां हैं:

moderate और conservative सेटिंग, पहले आओ पहले पाओ (एफ़आईएफ़ओ) के तरीके से काम करती हैं. ये सेटिंग, उपयोगकर्ता के इंटरैक्शन पर निर्भर करती हैं. तय सीमा तक पहुंचने के बाद, किसी नए अनुमान की वजह से सबसे पुराने अनुमान को रद्द कर दिया जाएगा और मेमोरी को बचाने के लिए, नए अनुमान से बदल दिया जाएगा. रद्द किए गए अनुमान को फिर से ट्रिगर किया जा सकता है. उदाहरण के लिए, उस लिंक पर फिर से कर्सर घुमाकर. इससे, उस यूआरएल के लिए फिर से अनुमान लगाया जाएगा और सबसे पुराना अनुमान हटा दिया जाएगा. इस मामले में, पिछले अनुमान से उस यूआरएल के लिए, एचटीटीपी कैश मेमोरी में कैश मेमोरी में सेव किए जा सकने वाले सभी संसाधनों को कैश मेमोरी में सेव कर दिया जाएगा. इसलिए, अनुमान लगाने में लगने वाले समय की लागत कम हो जाएगी. इसलिए, इसकी सीमा दो पर सेट की गई है. स्टैटिक सूची के नियम, उपयोगकर्ता की कार्रवाई से ट्रिगर नहीं होते. इसलिए, इनकी सीमा ज़्यादा होती है, क्योंकि ब्राउज़र यह नहीं जान सकता कि किन नियमों की ज़रूरत है और कब ज़रूरत है.

immediate और eager की सीमाएं भी डाइनैमिक होती हैं. इसलिए, list यूआरएल स्क्रिप्ट एलिमेंट को हटाने से, हटाए गए अनुमान रद्द हो जाएंगे और कैपेसिटी बढ़ जाएगी.

Chrome, कुछ स्थितियों में अनुमान का इस्तेमाल होने से भी रोकेगा. इन स्थितियों में ये शामिल हैं:

• Save-Data.
• एनर्जी सेवर मोड चालू होने पर और बैटरी कम होने पर.
• मेमोरी की सीमाएं.
• "पेजों को पहले से लोड करें" सेटिंग बंद होने पर. यह सेटिंग, uBlock Origin जैसे Chrome एक्सटेंशन से भी साफ़ तौर पर बंद की जाती है.
• बैकग्राउंड टैब में खोले गए पेज.

Chrome, पहले से रेंडर किए गए पेजों पर क्रॉस-ऑरिजिन iframes को तब तक रेंडर नहीं करता, जब तक कि उन्हें चालू नहीं किया जाता.

इन सभी शर्तों का मकसद, उपयोगकर्ताओं को नुकसान पहुंचाने वाली अटकलों के असर को कम करना है.

किसी पेज पर, अनुमान लगाने के नियमों को शामिल करने का तरीका

अनुमान के नियमों को पेज के एचटीएमएल में स्टैटिक तौर पर शामिल किया जा सकता है या JavaScript की मदद से पेज में डाइनैमिक तौर पर डाला जा सकता है:

• अनुमान लगाने के लिए स्टैटिक तौर पर शामिल किए गए नियम: उदाहरण के लिए, अगर ज़्यादातर उपयोगकर्ताओं के लिए नया लेख अक्सर अगला नेविगेशन होता है, तो कोई समाचार मीडिया साइट या ब्लॉग, नया लेख पहले से रेंडर कर सकता है. इसके अलावा, moderate या conservative वाले दस्तावेज़ के नियमों का इस्तेमाल करके, अनुमान लगाया जा सकता है कि उपयोगकर्ता लिंक के साथ कैसे इंटरैक्ट करते हैं.
• डाइनैमिक तौर पर डाले गए अनुमान के नियम: यह ऐप्लिकेशन लॉजिक, उपयोगकर्ता के हिसाब से या अन्य अनुमान लगाने के तरीकों के आधार पर हो सकता है.

जिन लोगों को किसी लिंक पर कर्सर घुमाने या उस पर क्लिक करने जैसी कार्रवाइयों के आधार पर डाइनैमिक इंसर्शन का इस्तेमाल करना है उन्हें दस्तावेज़ के नियमों को देखना चाहिए. ऐसा इसलिए, क्योंकि इन नियमों की मदद से ब्राउज़र, इस्तेमाल के कई उदाहरणों को हैंडल कर सकता है. ऐसा पहले भी कई लाइब्रेरी ने <link rel=prefetch> के साथ किया है.

मुख्य फ़्रेम में, <head> या <body> में से किसी एक में, अनुमान के नियम जोड़े जा सकते हैं. सबफ़्रेम में अनुमान लगाने के नियमों का इस्तेमाल नहीं किया जाता. साथ ही, पहले से रेंडर किए गए पेजों में अनुमान लगाने के नियमों का इस्तेमाल, पेज के चालू होने के बाद ही किया जाता है.

Speculation-Rules एचटीटीपी हेडर

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

Speculation-Rules एचटीटीपी हेडर, दस्तावेज़ के साथ दिखाया जाता है. साथ ही, यह अनुमान लगाने के नियमों वाली JSON फ़ाइल की जगह पर ले जाता है:

Speculation-Rules: "/speculationrules.json"

इस संसाधन के लिए, सही MIME टाइप का इस्तेमाल करना ज़रूरी है. अगर यह क्रॉस-ऑरिजिन संसाधन है, तो CORS जांच पास करना ज़रूरी है.

Content-Type: application/speculationrules+json
Access-Control-Allow-Origin: *

अगर आपको रिलेटिव यूआरएल का इस्तेमाल करना है, तो अपने अनुमान के नियमों में "relative_to": "document" कुंजी शामिल करें. ऐसा न करने पर, रिलेटिव यूआरएल, अनुमान लगाने के नियमों की JSON फ़ाइल के यूआरएल के हिसाब से होंगे. यह सुविधा खास तौर पर तब काम आ सकती है, जब आपको एक ही ऑरिजिन वाले कुछ या सभी लिंक चुनने हों.

अनुमान लगाने के नियम और एसपीए

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

अनुमान के नियमों का इस्तेमाल करके, पिछले पेज से ऐप्लिकेशन को पहले से रेंडर किया जा सकता है. इससे, कुछ एसपीए के शुरुआती लोड की कुछ अतिरिक्त लागतों को कम करने में मदद मिल सकती है. हालांकि, ऐप्लिकेशन में रास्ते में हुए बदलावों को पहले से रेंडर नहीं किया जा सकता.

अनुमान लगाने के नियमों को डीबग करना

इस नए एपीआई को देखने और डीबग करने में मदद करने वाली Chrome DevTools की नई सुविधाओं के बारे में जानने के लिए, अनुमान के नियमों को डीबग करने के बारे में खास पोस्ट देखें.

अनुमान लगाने के कई नियम

एक ही पेज पर, अनुमान से जुड़े कई नियम भी जोड़े जा सकते हैं. ये नियम, मौजूदा नियमों में जुड़ जाते हैं. इसलिए, नीचे दिए गए अलग-अलग तरीकों से, one.html और two.html, दोनों के लिए प्री-रेंडरिंग की जाती है:

यूआरएल की सूची:

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html", "two.html"]
    }
  ]
}
</script>

कई speculationrules स्क्रिप्ट:

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html"]
    }
  ]
}
</script>
<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["two.html"]
    }
  ]
}
</script>

speculationrules के एक सेट में कई सूचियां

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html"]
    },
    {
      "urls": ["two.html"]
    }
  ]
}
</script>

No-Vary-Search सहायता

किसी पेज को पहले से लोड करने या पहले से रेंडर करने पर, हो सकता है कि कुछ यूआरएल पैरामीटर (तकनीकी तौर पर इन्हें सर्च पैरामीटर कहा जाता है) सर्वर से डिलीवर किए गए पेज के लिए ज़रूरी न हों. इनका इस्तेमाल सिर्फ़ क्लाइंट साइड JavaScript करता है.

उदाहरण के लिए, Google Analytics, कैंपेन मेज़रमेंट के लिए यूटीएम पैरामीटर का इस्तेमाल करता है. हालांकि, आम तौर पर इससे सर्वर से अलग-अलग पेज डिलीवर नहीं होते. इसका मतलब है कि page1.html?utm_content=123 और page1.html?utm_content=456, सर्वर से एक ही पेज डिलीवर करेंगे. इसलिए, उसी पेज का फिर से इस्तेमाल कैश मेमोरी से किया जा सकता है.

इसी तरह, ऐप्लिकेशन ऐसे अन्य यूआरएल पैरामीटर का इस्तेमाल कर सकते हैं जिन्हें सिर्फ़ क्लाइंट साइड पर मैनेज किया जाता है.

No-Vary-Search प्रोसेस की मदद से, सर्वर ऐसे पैरामीटर तय कर सकता है जिनसे डिलीवर किए गए संसाधन में कोई फ़र्क़ नहीं पड़ता. इसलिए, ब्राउज़र किसी दस्तावेज़ के उन वर्शन का फिर से इस्तेमाल कर सकता है जिन्हें पहले कैश मेमोरी में सेव किया गया था और जो सिर्फ़ इन पैरामीटर में अलग-अलग हैं. यह सुविधा, नेविगेशन के अनुमान को पहले से लोड करने के लिए, Chrome और Chromium पर आधारित ब्राउज़र में काम करती है. हालांकि, हम पहले से रेंडर करने के लिए भी इस सुविधा को उपलब्ध कराने की कोशिश कर रहे हैं.

अनुमान के नियमों में expects_no_vary_search का इस्तेमाल किया जा सकता है. इससे यह पता चलता है कि No-Vary-Search एचटीटीपी हेडर कहां दिखेगा. ऐसा करने से, अनचाहे डाउनलोड से भी बचा जा सकता है.

<script type="speculationrules">
{
  "prefetch": [{
    "urls": ["/products*"],
    "expects_no_vary_search": "params=(\"id\")"
  }]
}
</script>

<a href="/products?id=123">Product 123</a>
<a href="/products?id=124">Product 124</a>

इस उदाहरण में, प्रॉडक्ट आईडी 123 और 124, दोनों के लिए /products शुरुआती पेज का एचटीएमएल एक ही है. हालांकि, id सर्च पैरामीटर का इस्तेमाल करके प्रॉडक्ट डेटा फ़ेच करने के लिए, JavaScript का इस्तेमाल करके क्लाइंट-साइड रेंडरिंग के आधार पर, पेज का कॉन्टेंट अलग-अलग होता है. इसलिए, हम उस यूआरएल को पहले से लोड कर लेते हैं. इससे, हमें No-Vary-Search एचटीटीपी हेडर मिलता है, जिसमें यह जानकारी होती है कि पेज का इस्तेमाल किसी भी id सर्च पैरामीटर के लिए किया जा सकता है.

हालांकि, अगर उपयोगकर्ता प्रीफ़ेच पूरा होने से पहले किसी भी लिंक पर क्लिक करता है, तो हो सकता है कि ब्राउज़र को /products पेज न मिला हो. इस मामले में, ब्राउज़र को नहीं पता कि इसमें No-Vary-Search एचटीटीपी हेडर शामिल होगा या नहीं. इसके बाद, ब्राउज़र के पास यह चुनने का विकल्प होता है कि उसे लिंक को फिर से फ़ेच करना है या प्रीफ़ेच की प्रोसेस पूरी होने का इंतज़ार करना है, ताकि यह देखा जा सके कि उसमें No-Vary-Search एचटीटीपी हेडर है या नहीं. expects_no_vary_search सेटिंग की मदद से, ब्राउज़र को यह पता चलता है कि पेज के रिस्पॉन्स में No-Vary-Search एचटीटीपी हेडर हो सकता है. साथ ही, यह भी पता चलता है कि प्रीफ़ेच की प्रोसेस पूरी होने का इंतज़ार करना है या नहीं.

अनुमान लगाने के नियमों से जुड़ी पाबंदियां और आने वाले समय में होने वाले सुधार

अनुमान लगाने से जुड़े नियम, एक ही टैब में खोले गए पेजों पर लागू होते हैं. हालांकि, हम इस पाबंदी को कम करने पर काम कर रहे हैं.

डिफ़ॉल्ट रूप से, अनुमान लगाने की सुविधा, एक ही ऑरिजिन वाले पेजों तक सीमित होती है. एक ही साइट के क्रॉस-ऑरिजिन पेजों के बारे में अनुमान लगाना. उदाहरण के लिए, https://a.example.com https://b.example.com पर किसी पेज को प्रीरेंडर कर सकता है. इसका इस्तेमाल करने के लिए, अनुमानित पेज (इस उदाहरण में https://b.example.com) को Supports-Loading-Mode: credentialed-prerender एचटीटीपी हेडर शामिल करके ऑप्ट-इन करना होगा. ऐसा न करने पर, Chrome अनुमान को रद्द कर देगा.

आने वाले वर्शन में, एक ही साइट के नहीं, क्रॉस-ऑरिजिन पेजों के लिए भी पेज को पहले से रेंडर करने की अनुमति दी जा सकती है. हालांकि, ऐसा तब तक ही किया जा सकता है, जब तक पहले से रेंडर किए गए पेज के लिए कुकी मौजूद न हों और पहले से रेंडर किया गया पेज, मिलते-जुलते Supports-Loading-Mode: uncredentialed-prerender एचटीटीपी हेडर के साथ ऑप्ट-इन करता हो.

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

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

<script type="speculationrules">
  {
    "prerender": [
      {
        "where": { "href_matches": "/*" },
        "eagerness": "moderate"
      }
    ],
    "prefetch": [
      {
        "where": { "not": { "href_matches": "/*" } },
        "eagerness": "moderate"
      }
    ]
  }
</script>

सुरक्षा के लिए, डिफ़ॉल्ट रूप से क्रॉस-ऑरिजिन लिंक के लिए क्रॉस-ऑरिजिन अनुमान लगाने से रोकने की पाबंदी ज़रूरी है. यह क्रॉस-ऑरिजिन डेस्टिनेशन के लिए, <link rel="prefetch"> के मुकाबले बेहतर है. यह कुकी भी नहीं भेजेगा, लेकिन फिर भी प्रीफ़ेच करने की कोशिश करेगा. इससे, प्रीफ़ेच करने की कोशिश बेकार हो जाएगी और उसे फिर से भेजना पड़ेगा. इसके अलावा, पेज गलत तरीके से लोड हो सकता है.

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

Speculation Rules API के साथ काम करने की सुविधा का पता लगाना

स्टैंडर्ड एचटीएमएल जांच की मदद से, अनुमान लगाने से जुड़े नियमों के एपीआई के साथ काम करने की सुविधा का पता लगाया जा सकता है:

if (HTMLScriptElement.supports && HTMLScriptElement.supports('speculationrules')) {
  console.log('Your browser supports the Speculation Rules API.');
}

JavaScript की मदद से, अनुमान लगाने के नियम डाइनैमिक तौर पर जोड़ना

JavaScript का इस्तेमाल करके, prerender अनुमान से जुड़ा नियम जोड़ने का उदाहरण:

if (HTMLScriptElement.supports &&
    HTMLScriptElement.supports('speculationrules')) {
  const specScript = document.createElement('script');
  specScript.type = 'speculationrules';
  specRules = {
    prerender: [
      {
        urls: ['/next.html'],
      },
    ],
  };
  specScript.textContent = JSON.stringify(specRules);
  console.log('added speculation rules to: next.html');
  document.body.append(specScript);
}

पहले से रेंडर किए गए पेज का डेमो पर, JavaScript इंसर्शन का इस्तेमाल करके, Speculation Rules API की पहले से रेंडर करने की सुविधा का डेमो देखा जा सकता है.

innerHTML का इस्तेमाल करके, सीधे तौर पर DOM में <script type = "speculationrules"> एलिमेंट डालने पर, सुरक्षा से जुड़ी वजहों से अनुमान लगाने के नियम रजिस्टर नहीं होंगे. इसे पहले दिखाए गए तरीके से जोड़ा जाना चाहिए. हालांकि, innerHTML का इस्तेमाल करके डाइनैमिक तौर पर डाले गए कॉन्टेंट में नए लिंक शामिल होने पर, पेज पर मौजूद मौजूदा नियमों के हिसाब से कॉन्टेंट को चुना जाएगा.

इसी तरह, <script type = "speculationrules"> एलिमेंट जोड़ने के लिए, Chrome DevTools में एलिमेंट पैनल में सीधे बदलाव करने से, अनुमान लगाने के नियम रजिस्टर नहीं होते. इसके बजाय, नियमों को शामिल करने के लिए, डीओएम में इसे डाइनैमिक तौर पर जोड़ने वाली स्क्रिप्ट को Console से चलाना होगा.

Tag Manager की मदद से, अनुमान लगाने के नियम जोड़ना

Google Tag Manager (GTM) जैसे टैग मैनेजर का इस्तेमाल करके, अनुमान के नियम जोड़ने के लिए, इन्हें JavaScript के ज़रिए डालना ज़रूरी है. ऐसा इसलिए करना ज़रूरी है, क्योंकि GTM में सीधे <script type = "speculationrules"> एलिमेंट जोड़ने पर, पहले बताई गई समस्याएं आ सकती हैं:

ध्यान दें कि इस उदाहरण में var का इस्तेमाल किया गया है, क्योंकि GTM में const काम नहीं करता.

अनुमान लगाने के नियम रद्द करना

अनुमान लगाने से जुड़े नियमों को हटाने पर, पेज को पहले से रेंडर करने की प्रोसेस रद्द हो जाएगी. हालांकि, ऐसा होने तक, पेज को पहले से रेंडर करने की प्रोसेस शुरू करने के लिए संसाधनों का इस्तेमाल हो चुका होगा. इसलिए, अगर पेज को पहले से रेंडर करने की प्रोसेस को रद्द करने की संभावना है, तो हमारा सुझाव है कि पेज को पहले से रेंडर न करें.

अनुमान लगाने से जुड़े नियम और कॉन्टेंट की सुरक्षा के लिए बनी नीति

अनुमान लगाने के नियमों में <script> एलिमेंट का इस्तेमाल किया जाता है. भले ही, इनमें सिर्फ़ JSON शामिल हो, लेकिन अगर साइट इनका इस्तेमाल करती है, तो इन्हें script-src Content-Security-Policy में शामिल करना ज़रूरी है. इसके लिए, हैश या नॉन्स का इस्तेमाल किया जा सकता है.

script-src में एक नया inline-speculation-rules जोड़ा जा सकता है, ताकि हैश या नॉन्स वाली स्क्रिप्ट से इंजेक्ट किए गए <script type="speculationrules"> एलिमेंट काम कर सकें. यह शुरुआती एचटीएमएल में शामिल नियमों के साथ काम नहीं करता. इसलिए, स्ट्रिक्ट सीएसपी का इस्तेमाल करने वाली साइटों के लिए, JavaScript से नियमों को इंजेक्ट करना ज़रूरी है.

पेज को पहले से रेंडर करने की सुविधा का पता लगाना और उसे बंद करना

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

हालांकि, ऐसे मामले हो सकते हैं जब आपको पेजों को पहले से रेंडर नहीं करना हो. उदाहरण के लिए, जब पेजों की स्थिति बदलती है, तो शुरुआती अनुरोध या पेज पर चल रहे JavaScript के आधार पर.

Chrome में पेज को पहले से रेंडर करने की सुविधा को चालू और बंद करना

पेज को पहले से रेंडर करने की सुविधा, सिर्फ़ उन Chrome उपयोगकर्ताओं के लिए चालू होती है जिनके पास chrome://settings/performance/ में "पेज पहले से लोड करें" सेटिंग होती है. इसके अलावा, कम मेमोरी वाले डिवाइसों पर भी पेज को पहले से रेंडर करने की सुविधा बंद रहती है. साथ ही, अगर ऑपरेटिंग सिस्टम, डेटा सेव करने या एनर्जी सेवर मोड में है, तो भी यह सुविधा बंद रहती है. Chrome की सीमाएं सेक्शन देखें.

सर्वर-साइड पर पेज को पहले से रेंडर करने की सुविधा का पता लगाना और उसे बंद करना

पहले से रेंडर किए गए पेजों को Sec-Purpose एचटीटीपी हेडर के साथ भेजा जाएगा:

Sec-Purpose: prefetch;prerender

अनुमान के नियमों वाले एपीआई का इस्तेमाल करके पहले से फ़ेच किए गए पेजों के लिए, यह हेडर सिर्फ़ prefetch पर सेट होगा:

Sec-Purpose: prefetch

अनुमान के अनुरोधों को लॉग करने, अलग कॉन्टेंट दिखाने या पेज को पहले से रेंडर होने से रोकने के लिए, सर्वर इस हेडर के आधार पर जवाब दे सकते हैं. अगर रीडायरेक्ट के बाद, कोई गलत फ़ाइनल रिस्पॉन्स कोड दिखता है, तो इसका मतलब है कि वह 200 से 299 की रेंज में नहीं है. ऐसे में, पेज को पहले से रेंडर नहीं किया जाएगा और पहले से लोड किए गए किसी भी पेज को खारिज कर दिया जाएगा. यह भी ध्यान रखें कि 204 और 205 कोड वाले रिस्पॉन्स, पेज को पहले से रेंडर करने के लिए मान्य नहीं हैं. हालांकि, ये प्रीफ़ेच के लिए मान्य हैं.

अगर आपको किसी पेज को पहले से रेंडर नहीं कराना है, तो 2XX के बजाय कोई दूसरा रिस्पॉन्स कोड (जैसे, 503) दिखाना सबसे सही तरीका है. इससे यह पक्का किया जा सकता है कि पेज पहले से रेंडर न हो. हालांकि, बेहतर अनुभव देने के लिए, हमारा सुझाव है कि आप पेज को पहले से रेंडर करने की अनुमति दें. हालांकि, ऐसी किसी भी कार्रवाई को तब तक रोकें जो पेज को JavaScript का इस्तेमाल करके, असल में देखने के बाद ही होनी चाहिए.

JavaScript में प्री-रेंडर का पता लगाना

पेज को पहले से रेंडर करने के दौरान, document.prerendering एपीआई true दिखाएगा. पेज इस एट्रिब्यूट का इस्तेमाल करके, पेज के चालू होने तक प्री-रेंडरिंग के दौरान कुछ गतिविधियों को रोक सकते हैं या उनमें देरी कर सकते हैं.

पहले से रेंडर किए गए दस्तावेज़ के चालू होने के बाद, PerformanceNavigationTiming का activationStart भी शून्य से ज़्यादा समय पर सेट हो जाएगा. यह समय, पहले से रेंडर करने की प्रोसेस शुरू होने और दस्तावेज़ के चालू होने के बीच का समय होता है.

आपके पास पहले से रेंडर किए गए और पहले से रेंडर किए जा रहे पेजों की जांच करने के लिए, इस तरह का फ़ंक्शन हो सकता है:

function pagePrerendered() {
  return (
    document.prerendering ||
    self.performance?.getEntriesByType?.('navigation')[0]?.activationStart > 0
  );
}

यह देखने का सबसे आसान तरीका है कि पेज को पहले से रेंडर किया गया है या नहीं. इसके लिए, पेज चालू होने के बाद DevTools खोलें और कंसोल में performance.getEntriesByType('navigation')[0].activationStart टाइप करें. अगर शून्य से ज़्यादा वैल्यू दिखती है, तो इसका मतलब है कि पेज पहले से रेंडर हो चुका है:

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

इन एपीआई का इस्तेमाल करके, फ़्रंटएंड JavaScript, पहले से रेंडर किए गए पेजों का पता लगा सकता है और उन पर सही तरीके से कार्रवाई कर सकता है.

आंकड़ों पर असर

Analytics का इस्तेमाल, वेबसाइट के इस्तेमाल को मेज़र करने के लिए किया जाता है. उदाहरण के लिए, पेज व्यू और इवेंट को मेज़र करने के लिए, Google Analytics का इस्तेमाल किया जाता है. इसके अलावा, असल उपयोगकर्ता निगरानी (आरयूएम) का इस्तेमाल करके, पेजों की परफ़ॉर्मेंस मेट्रिक को मेज़र किया जा सकता है.

पेजों को सिर्फ़ तब पहले से रेंडर किया जाना चाहिए, जब इस बात की संभावना हो कि उपयोगकर्ता पेज को लोड करेगा. इसलिए, Chrome के पता बार में पेज को पहले से रेंडर करने के विकल्प सिर्फ़ तब दिखते हैं, जब पेज खुलने की संभावना 80% से ज़्यादा हो.

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

ऐसा करने के लिए, Promise का इस्तेमाल करें. यह prerenderingchange इवेंट के होने तक इंतज़ार करता है. अगर दस्तावेज़ पहले से रेंडर हो रहा है, तो यह तुरंत रिज़ॉल्व हो जाता है:

// Set up a promise for when the page is activated,
// which is needed for prerendered pages.
const whenActivated = new Promise((resolve) => {
  if (document.prerendering) {
    document.addEventListener('prerenderingchange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenActivated;
  // Initialise your analytics
}

initAnalytics();

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

// Set up a promise for when the page is first made visible
const whenFirstVisible = new Promise((resolve) => {
  if (document.hidden) {
    document.addEventListener('visibilitychange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenFirstVisible;
  // Initialise your analytics
}

initAnalytics();

हालांकि, यह आंकड़ों और मिलते-जुलते इस्तेमाल के उदाहरणों के लिए सही हो सकता है, लेकिन हो सकता है कि अन्य मामलों में आपको उन मामलों के लिए ज़्यादा कॉन्टेंट लोड करना हो. इसलिए, हो सकता है कि आप document.prerendering और prerenderingchange का इस्तेमाल करके, खास तौर पर पेज को पहले से रेंडर करने की सुविधा को टारगेट करना चाहें.

वीडियो को पहले से रेंडर करने के दौरान, अन्य कॉन्टेंट को रोकना

पहले बताए गए उन ही एपीआई का इस्तेमाल, प्री-रेंडरिंग के दौरान दूसरे कॉन्टेंट को रोकने के लिए किया जा सकता है. यह JavaScript के खास हिस्से या पूरी स्क्रिप्ट के ऐसे एलिमेंट हो सकते हैं जिन्हें आपको प्री-रेंडरिंग के दौरान नहीं चलाना है.

उदाहरण के लिए, यह स्क्रिप्ट:

<script src="https://example.com/app/script.js" async></script>

इसे डाइनैमिक तौर पर डाले गए स्क्रिप्ट एलिमेंट में बदला जा सकता है, जो सिर्फ़ पिछले whenActivated फ़ंक्शन के आधार पर डाला जाता है:

async function addScript(scriptUrl) {
  await whenActivated;
  const script = document.createElement('script');
  script.src = 'scriptUrl';
  document.body.appendChild(script);
}

addScript('https://example.com/app/script.js');

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

ऐसा हो सकता है कि पेज को पहले से रेंडर करने की सुविधा का इस्तेमाल करने पर, यह समस्या ज़्यादा बार हो. हालांकि, ये शर्तें पहले बताए गए बैकग्राउंड टैब में लोड किए गए पेजों पर भी लागू होती हैं. इसलिए, whenActivated के बजाय whenFirstVisible फ़ंक्शन का इस्तेमाल किया जा सकता है.

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

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

परफ़ॉर्मेंस का आकलन करना

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

वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली मेट्रिक, Chrome उपयोगकर्ता अनुभव रिपोर्ट की मदद से Chrome से मेज़र की जाती है. इनका मकसद, उपयोगकर्ता अनुभव को मेज़र करना है. इसलिए, इनका आकलन चालू होने के समय के आधार पर किया जाता है. इससे अक्सर एलसीपी 0 सेकंड का हो जाता है. इससे पता चलता है कि यह वेबसाइट की परफ़ॉर्मेंस की मेट्रिक को बेहतर बनाने का एक बेहतरीन तरीका है.

3.1.0 वर्शन से, web-vitals लाइब्रेरी को अपडेट किया गया है, ताकि पहले से रेंडर किए गए नेविगेशन को उसी तरह मैनेज किया जा सके जिस तरह Chrome, मुख्य वेब विटल को मेज़र करता है. अगर पेज को पूरी तरह या कुछ हद तक पहले से रेंडर किया गया था, तो यह वर्शन Metric.navigationType एट्रिब्यूट में मौजूद उन मेट्रिक के लिए, पहले से रेंडर किए गए नेविगेशन को भी फ़्लैग करता है.

पेज को पहले से रेंडर करने की सुविधा को मेज़र करना

किसी पेज को पहले से रेंडर किया गया है या नहीं, यह देखने के लिए PerformanceNavigationTiming की activationStart एंट्री को देखें. यह एंट्री शून्य से ज़्यादा होनी चाहिए. इसके बाद, पेज व्यू को लॉग करते समय, कस्टम डाइमेंशन या इसी तरह के किसी दूसरे फ़ंक्शन का इस्तेमाल करके, इस जानकारी को लॉग किया जा सकता है. उदाहरण के लिए, पहले बताए गए pagePrerendered फ़ंक्शन का इस्तेमाल करके:

// Set Custom Dimension for Prerender status
gtag('set', { 'dimension1': pagePrerendered() });
// Initialise GA - including sending page view by default
gtag('config', 'G-12345678-1');

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

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

हिट रेट मेज़र करना

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

अनुमान लगाने के नियम डालने पर, किसी Analytics इवेंट को ट्रिगर करके इसका आकलन किया जा सकता है. इसके लिए, यह देखना ज़रूरी है कि ब्राउज़र में HTMLScriptElement.supports('speculationrules') का इस्तेमाल करके, पेज को पहले से रेंडर करने की सुविधा काम करती है या नहीं. इससे यह पता चलता है कि पेज को पहले से रेंडर करने का अनुरोध किया गया था. (ध्यान दें कि पेज को पहले से रेंडर करने का अनुरोध करने का मतलब यह नहीं है कि पेज को पहले से रेंडर किया जा रहा है या किया जा चुका है. जैसा कि पहले बताया गया है, पेज को पहले से रेंडर करने का अनुरोध, ब्राउज़र के लिए एक संकेत होता है. यह हो सकता है कि वह उपयोगकर्ता की सेटिंग, मौजूदा मेमोरी के इस्तेमाल या अन्य अनुमानित तरीकों के आधार पर, पेजों को पहले से रेंडर न करे.)

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

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

ध्यान रखें कि कुछ पेज, अनुमान लगाने के आपके नियमों की वजह से ही नहीं, बल्कि पता बार की प्री-रेंडरिंग की वजह से भी प्री-रेंडर हो सकते हैं. अगर आपको इनमें अंतर करना है, तो document.referrer को चुनें. यह पता बार नेविगेशन के लिए खाली रहेगा. इसमें, पहले से रेंडर किए गए पता बार नेविगेशन भी शामिल हैं.

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

एक्सटेंशन पर असर

Chrome एक्सटेंशन: इंस्टैंट नेविगेशन की सुविधा के लिए एपीआई को बेहतर बनाना लेख पढ़ें. इसमें, एक्सटेंशन बनाने वाले लोगों को, पहले से रेंडर किए गए पेजों के लिए कुछ और बातों का ध्यान रखने के बारे में बताया गया है.

सुझाव/राय दें या शिकायत करें

Chrome की टीम, पेज को पहले से रेंडर करने की सुविधा पर काम कर रही है. साथ ही, Chrome 108 रिलीज़ में उपलब्ध कराई गई सुविधाओं को और बेहतर बनाने के लिए, कई प्लान बनाए गए हैं. GitHub repo या समस्या ट्रैकर का इस्तेमाल करके, हमें अपने सुझाव, राय या शिकायत भेजें. साथ ही, इस नए एपीआई के बारे में अपनी केस स्टडी शेयर करें.

इसी विषय से जुड़े कुछ लिंक

• अनुमान लगाने के नियमों के बारे में कोडलैब
• अनुमान लगाने के नियमों को डीबग करना
• NoState Prefetch की सुविधा के बारे में जानकारी
• अनुमान लगाने के नियमों के लिए एपीआई की खास जानकारी
• नेविगेशन से जुड़ी जानकारी का GitHub रिपॉज़िटरी
• Chrome एक्सटेंशन: इंस्टैंट नेविगेशन की सुविधा के साथ काम करने के लिए एपीआई को बेहतर बनाना

आभार

Unsplash पर मार्क-ओलिवियर जोडॉइन की थंबनेल इमेज