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

Barry Pollard

पब्लिश करने की तारीख: 2 दिसंबर, 2022, पिछली बार अपडेट किए जाने की तारीख: 22 जनवरी, 2026

Browser Support

  • Chrome: 109.
  • Edge: 109.
  • Firefox: not supported.
  • Safari: behind a flag.

Source

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. साइटें, Speculation Rules API का इस्तेमाल कर सकती हैं. इससे वे Chrome को प्रोग्राम के हिसाब से यह बता सकती हैं कि किन पेजों को पहले से रेंडर करना है. यह <link rel="prerender"...> की जगह काम करता है. इससे साइटें, पेज पर अनुमान के आधार पर तय किए गए नियमों के मुताबिक, किसी पेज को पहले से रेंडर कर सकती हैं. ये पेज पर स्टैटिक तौर पर मौजूद हो सकते हैं या पेज के मालिक की ज़रूरत के हिसाब से, JavaScript की मदद से डाइनैमिक तौर पर जोड़े जा सकते हैं.

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

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

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

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

प्रीरेंडरिंग का उदाहरण.

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

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

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

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

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

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

Chrome Predictors पेज की इमेज. इसमें टेक्स्ट के आधार पर, कम (स्लेटी), मीडियम (ऐंबर), और ज़्यादा (हरा) अनुमान दिखाने के लिए फ़िल्टर किया गया है.
Chrome Predictors पेज.

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

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

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

Chrome के पता बार में मौजूद &#39;टाइपअहेड&#39; सुविधा
पता बार में 'टाइपअहेड' सुविधा.

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

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

Speculation Rules API

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

यूआरएल की सूचियां

अनुमान लगाने के नियम, यूआरएल की सूचियों पर आधारित हो सकते हैं:

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

दस्तावेज़ के नियम

where सिंटैक्स का इस्तेमाल करके, अनुमान लगाने के नियमों को "दस्तावेज़ के नियम" के तौर पर भी इस्तेमाल किया जा सकता है. यह 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>

उत्सुकता

Browser Support

  • Chrome: 121.
  • Edge: 121.
  • Firefox: not supported.
  • Safari: behind a flag.

Source

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

  • conservative: इससे पॉइंटर या टच डाउन का अनुमान लगाया जाता है.
  • moderate: डेस्कटॉप पर, अगर किसी लिंक पर 200 मिलीसेकंड तक पॉइंटर को होल्ड किया जाता है, तो यह स्पेकुलेशन करता है. अगर pointerdown इवेंट पहले होता है, तो यह उस पर स्पेकुलेशन करता है. साथ ही, यह मोबाइल पर भी स्पेकुलेशन करता है, जहां hover इवेंट नहीं होता है. मोबाइल पर, हमने अगस्त 2025 से जटिल व्यूपोर्ट ह्यूरिस्टिक्स के आधार पर इस बदलाव को लागू किया है. कॉम्प्लेक्स व्यूपोर्ट ह्यूरिस्टिक, उपयोगकर्ता के स्क्रोल करना बंद करने के 500 मि॰से॰ बाद ट्रिगर होता है. यह उन ऐंकर के लिए होता है जो पिछले पॉइंटर डाउन से वर्टिकल दूरी के 30% के अंदर होते हैं. साथ ही, ऐंकर व्यूपोर्ट में सबसे बड़े ऐंकर के कम से कम 0.5 गुना बड़े होते हैं. जैसा कि इस दस्तावेज़ में बताया गया है.
  • eager: यह immediate की तरह काम करता था, लेकिन Chrome 143 से इसमें बदलाव किया गया है. डेस्कटॉप पर, अगर किसी लिंक पर 10 मिलीसेकंड तक पॉइंटर को दबाकर रखा जाता है, तो यह सुविधा अनुमान लगाती है. मोबाइल पर, हमने जनवरी 2026 से इसे सिंपल व्यूपोर्ट ह्यूरिस्टिक्स के आधार पर तय करना शुरू कर दिया है. व्यूपोर्ट के बारे में सामान्य जानकारी देने वाली ह्युरिस्टिक, ऐंकर के व्यूपोर्ट में आने के 50 मि॰से॰ बाद ट्रिगर होती है.
  • immediate: इसका इस्तेमाल, अनुमान लगाने के नियमों का पालन करने के तुरंत बाद अनुमान लगाने के लिए किया जाता है.

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

document नियमों के लिए डिफ़ॉल्ट eagerness, conservative होता है. किसी दस्तावेज़ में कई यूआरएल हो सकते हैं. इसलिए, document नियमों के लिए immediate का इस्तेमाल सावधानी से करना चाहिए. इसके अलावा, 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 की टीम, Speculation Rules API में prerender_until_script जोड़ने पर भी काम कर रही है. (देखें: implementation bug). यह प्रीफ़ेच और प्रीरेंडर के बीच का एक चरण होगा. इसका इस्तेमाल भी इसी तरह किया जाएगा:

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

NoState prefetch की तरह ही, यह एचटीएमएल दस्तावेज़ और उस एचटीएमएल में उपलब्ध सब-रिसोर्स, दोनों को प्रीफ़ेच करेगा. हालांकि, यह इससे आगे बढ़कर पेज को प्रीरेंडर करना भी शुरू कर देगा. यह तब तक प्रीरेंडर करता रहेगा, जब तक पहली स्क्रिप्ट नहीं मिल जाती.

इसका मतलब है कि जिन पेजों में JavaScript नहीं है या सिर्फ़ फ़ुटर में JavaScript है उन्हें पहले से ही पूरी तरह से रेंडर किया जा सकता है. जिन पेजों में <head> में स्क्रिप्ट मौजूद हैं उन्हें पहले से रेंडर नहीं किया जा सकेगा. हालांकि, उन्हें अब भी सब-रिसोर्स फ़ेच करने की सुविधा का फ़ायदा मिलेगा.

इससे JavaScript के इस्तेमाल से होने वाले अनचाहे साइड इफ़ेक्ट के जोखिम से बचा जा सकेगा. साथ ही, इससे prefetch की तुलना में परफ़ॉर्मेंस में ज़्यादा सुधार होगा.

Chrome की सीमाएं

Chrome ने Speculation Rules API के ज़्यादा इस्तेमाल को रोकने के लिए, कुछ सीमाएं तय की हैं:

उत्सुकता प्रीफ़ेच पहले से रेंडर करना
immediate / eager (मोबाइल) 50 10
eager (डेस्कटॉप) / moderate / conservative 2 (एफ़आईएफ़ओ) 2 (एफ़आईएफ़ओ)
Chrome में स्पेकुलेशन की सीमाएं.

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

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

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

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

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

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

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

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

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

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

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

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

Browser Support

  • Chrome: 121.
  • Edge: 121.
  • Firefox: not supported.
  • Safari: behind a flag.

Source

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

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

Speculation-Rules: "/speculationrules.json"

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

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

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

अनुमान लगाने के नियमों के टैग फ़ील्ड

Browser Support

  • Chrome: 136.
  • Edge: 136.
  • Firefox: not supported.
  • Safari: behind a flag.

Source

इसके अलावा, नियमों के सेट में मौजूद सभी स्पेकुलेशन नियमों के लिए, स्पेकुलेशन नियमों के JSON सिंटैक्स में "टैग" जोड़े जा सकते हैं:

{
  "tag": "my-rules",
  "prefetch": [
    "urls": ["next.html"]
  ],
  "prerender": [
    "urls": ["next2.html"]
  ],
}

इसके अलावा, किसी नियम के लेवल पर भी ऐसा किया जा सकता है:

{
  "prefetch": [
    "urls": ["next.html"],
    "tag": "my-prefetch-rules"
  ],
  "prerender": [
    "urls": ["next2.html"],
    "tag": "my-prerender-rules"
  ],
}

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

Sec-Speculation-Tags: null
Sec-Speculation-Tags: null, "cdn-prefetch"
Sec-Speculation-Tags: "my-prefetch-rules"
Sec-Speculation-Tags: "my-prefetch-rules", "my-rules", "cdn-prefetch"

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

रूल्ससेट टैग भी Chrome DevTools में दिखते हैं.

अनुमान लगाने के नियम target_hint फ़ील्ड

Browser Support

  • Chrome: 138.
  • Edge: 138.
  • Firefox: not supported.
  • Safari: not supported.

Source

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

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

इस सुझाई गई कार्रवाई से, target="_blank" लिंक के लिए प्रीरेंडर स्पेकुलेशन को मैनेज किया जा सकता है:

<a target="_blank" href="next.html">Open this link in a new tab</a>

फ़िलहाल, Chrome में सिर्फ़ "target_hint": "_blank" और "target_hint": "_self" (अगर कोई वैल्यू नहीं दी गई है, तो यह डिफ़ॉल्ट वैल्यू होती है) काम करते हैं. साथ ही, ये सिर्फ़ प्रीरेंडर के लिए काम करते हैं. प्रीफ़ेच के लिए काम नहीं करते.

target_hint की ज़रूरत सिर्फ़ urls अटकलें लगाने से जुड़े नियमों के लिए होती है. दस्तावेज़ से जुड़े नियमों के लिए, target की जानकारी लिंक से ही मिल जाती है.

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

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

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

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

इस नए एपीआई को देखने और डीबग करने में मदद करने वाली 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>

Browser Support

  • Chrome: 127.
  • Edge: 127.
  • Firefox: not supported.
  • Safari: not supported.

Source

किसी पेज को प्रीफ़ेच या प्रीरेंडर करते समय, कुछ यूआरएल पैरामीटर (तकनीकी तौर पर इन्हें खोज के पैरामीटर कहा जाता है) सर्वर से डिलीवर किए गए पेज के लिए ज़रूरी नहीं हो सकते. साथ ही, इनका इस्तेमाल सिर्फ़ क्लाइंट साइड 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 शुरुआती पेज का एचटीएमएल एक जैसा है. हालांकि, पेज का कॉन्टेंट आखिर में अलग-अलग होता है. ऐसा इसलिए होता है, क्योंकि क्लाइंट-साइड रेंडरिंग के लिए JavaScript का इस्तेमाल किया जाता है. इससे id सर्च पैरामीटर का इस्तेमाल करके प्रॉडक्ट का डेटा फ़ेच किया जाता है. इसलिए, हम उस यूआरएल को तुरंत प्रीफ़ेच करते हैं. साथ ही, यह No-Vary-Search एचटीटीपी हेडर दिखाता है कि पेज का इस्तेमाल किसी भी id सर्च पैरामीटर के लिए किया जा सकता है.

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

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

    "expects_no_vary_search": "params=(\"param1\" \"param2\" \"param3\")"

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

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

डिफ़ॉल्ट रूप से, अनुमान लगाने की सुविधा सिर्फ़ एक ही ऑरिजिन वाले पेजों के लिए उपलब्ध होती है. एक ही साइट के अलग-अलग ऑरिजिन वाले पेजों के लिए स्पेकुलेशन (उदाहरण के लिए, 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 के साथ काम करने की सुविधा का पता लगाना

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

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

टैग मैनेजर की मदद से अनुमान लगाने से जुड़े नियम जोड़ना

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

Google Tag Manager में कस्टम एचटीएमएल टैग कॉन्फ़िगरेशन
Google Tag Manager की मदद से अनुमान लगाने के नियम जोड़ना.

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

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

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

Browser Support

  • Chrome: 138.
  • Edge: 138.
  • Firefox: not supported.
  • Safari: not supported.

Source

prefetchCache और prerenderCache डायरेक्टिव के साथ Clear-Site-Data एचटीटीपी हेडर का इस्तेमाल करके भी, अटकलें रद्द की जा सकती हैं.

सर्वर पर स्थिति बदलने पर, यह काम आ सकता है. उदाहरण के लिए, "add-to-basket" एपीआई या लॉगिन या लॉग आउट एपीआई को कॉल करते समय.

आदर्श रूप से, इन स्टेट अपडेट को Broadcast Channel API जैसे एपीआई का इस्तेमाल करके, पहले से रेंडर किए गए पेजों पर भेजा जाना चाहिए. हालांकि, ऐसा न होने पर या इस तरह की लॉजिक को लागू किए जाने तक, स्पेकुलेशन को रद्द करना आसान हो सकता है.

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

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

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

प्रीरेंडरिंग का पता लगाना और उसे बंद करना

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

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

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

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

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

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

Sec-Purpose: prefetch;prerender

Speculation Rules API का इस्तेमाल करके प्रीफ़ेच किए गए पेजों के लिए, यह हेडर सिर्फ़ 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 टाइप करें. अगर शून्य से अलग कोई वैल्यू मिलती है, तो इसका मतलब है कि पेज को पहले से रेंडर किया गया था:

Chrome DevTools में कंसोल, जिसमें positive activationStart दिख रहा है. इससे पता चलता है कि पेज को पहले से रेंडर किया गया था
कंसोल में प्रीरेंडरिंग की जांच करना.

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

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

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

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

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

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

इसे 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();

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

// 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');

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Acknowledgements

Unsplash पर Marc-Olivier Jodoin की थंबनेल इमेज