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

Barry Pollard

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

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

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

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

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

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

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

1. Chrome के पता बार (जिसे "ऑमनीबॉक्स" भी कहा जाता है) में कोई यूआरएल टाइप करने पर, Chrome आपके लिए पेज को अपने-आप प्री-रेंडर कर सकता है. ऐसा तब होता है, जब Chrome को आपके पिछले ब्राउज़िंग इतिहास के आधार पर यह पता चलता है कि आप उस पेज पर जा सकते हैं.
2. जब बुकमार्क बार का इस्तेमाल किया जाता है, तो Chrome पॉइंटर को किसी एक बुकमार्क बटन के ऊपर दबाकर रखने पर, 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 यूआरएल को प्रीरेंडर करेगा.

अनुमान लगाने के नियम एपीआई

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

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, कैंपेन मेज़रमेंट के लिए UTM पैरामीटर का इस्तेमाल करता है. हालांकि, आम तौर पर इससे सर्वर से अलग-अलग पेज डिलीवर नहीं होते. इसका मतलब है कि 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 इंसर्शन का इस्तेमाल करके, अनुमान लगाने के नियम एपीआई की प्रीरेंडरिंग का डेमो देखा जा सकता है.

innerHTML का इस्तेमाल करके, <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');

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

धन्यवाद

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