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

Barry Pollard

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

Browser Support

  • Chrome: 109.
  • Edge: 109.
  • Firefox Technology Preview: 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 की सुविधाओं को बेहतर बनाने के लिए भी काम कर रही है, ताकि इस तरह के मुश्किल मामलों की पहचान करना आसान हो सके.

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

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

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

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

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

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

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

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

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

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

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

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

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

Chrome के पता बार में मौजूद 'टाइपअहेड' सुविधा
पता बार में 'टाइप करते ही सुझाव देने वाली' सुविधा.

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 Technology Preview: 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 नियमों को उन यूआरएल तक सीमित किया जा सकता है जिनसे उपयोगकर्ता किसी खास सूची में इंटरैक्ट करता है. हालांकि, कई मामलों में document नियम के साथ सही where शर्त का इस्तेमाल करना ज़्यादा सही हो सकता है.

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>

Prerender until script

Chrome की टीम, Speculation Rules API में prerender_until_script को जोड़ने पर भी काम कर रही है. ज़्यादा जानकारी के लिए, लागू करने से जुड़ी गड़बड़ी देखें. यह प्रीफ़ेच और प्रीरेंडर के बीच का एक चरण होगा. इसका इस्तेमाल इस तरह किया जाएगा:

<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 50 10
eager / मोबाइल पर moderate 6 (एफ़आईएफ़ओ) 2 (एफ़आईएफ़ओ)
डेस्कटॉप पर eager / moderate 2 (एफ़आईएफ़ओ) 2 (एफ़आईएफ़ओ)
conservative 2 (एफ़आईएफ़ओ) 2 (एफ़आईएफ़ओ)
Chrome में अनुमान लगाने की सीमाएं.

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

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

स्टैटिक सूची के नियम, उपयोगकर्ता की किसी कार्रवाई से ट्रिगर नहीं होते. इसलिए, इनकी सीमा ज़्यादा होती है. ऐसा इसलिए होता है, क्योंकि ब्राउज़र को यह पता नहीं होता कि किन नियमों की ज़रूरत है और कब है.

Chrome, eager और moderate के लिए, मोबाइल पर इस सीमा को बढ़ाकर 5 करने पर भी विचार कर रहा है. कम से कम प्रीफ़ेच के लिए ऐसा किया जा सकता है. ऐसा इसलिए, क्योंकि यह कम सटीक ह्यूरिस्टिक है. eager का इस्तेमाल करने वाले डेवलपर, conservative के नियमों का भी इस्तेमाल कर सकते हैं. ऐसा तब किया जा सकता है, जब व्यूपोर्ट में कई लिंक उपलब्ध हों. इससे, पहले दो लिंक के तौर पर न चुने जाने पर भी, अनुमान लगाया जा सकता है.

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

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

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

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

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

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

Speculation rules को पेज के एचटीएमएल में स्टैटिक तौर पर शामिल किया जा सकता है या 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"

इस संसाधन के लिए, सही एमआईएमई टाइप का इस्तेमाल किया जाना चाहिए. साथ ही, अगर यह क्रॉस-ऑरिजिन संसाधन है, तो इसे सीओआरएस की जांच पास करनी होगी.

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

अगर आपको रिलेटिव यूआरएल इस्तेमाल करने हैं, तो आपको अपने अनुमान लगाने के नियमों में "relative_to": "document" कुंजी शामिल करनी होगी. अगर ऐसा नहीं है, तो रिलेटिव यूआरएल, Speculation Rules की 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": [{
    "tag": "my-prefetch-rules",
    "urls": ["next.html"]
  }],
  "prerender": [{
    "tag": "my-prerender-rules",
    "urls": ["next2.html"]
  }]
}

इसके बाद, यह टैग 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: 141.
  • Edge: 141.
  • Firefox: 154.
  • 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>

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

हालांकि, अगर उपयोगकर्ता प्रीफ़ेच पूरा होने से पहले किसी लिंक पर क्लिक करता है, तो हो सकता है कि ब्राउज़र को /products पेज न मिले. इस मामले में, ब्राउज़र को यह नहीं पता होता कि इसमें No-Vary-Search एचटीटीपी हेडर शामिल होगा या नहीं. इसके बाद, ब्राउज़र के पास दो विकल्प होते हैं: लिंक को फिर से फ़ेच करना या प्रीफ़ेच की प्रोसेस पूरी होने का इंतज़ार करना, ताकि यह देखा जा सके कि उसमें 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 में एलिमेंट पैनल में सीधे तौर पर बदलाव करने से, अनुमान लगाने के नियम रजिस्टर नहीं होते. इसके बजाय, नियमों को शामिल करने के लिए, Console से डीओएम में डाइनैमिक तौर पर जोड़ने वाली स्क्रिप्ट को चलाना ज़रूरी है.

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

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

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

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

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

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

Browser Support

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

Source

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

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

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

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

अनुमान लगाने के नियमों में <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

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 में कंसोल, जिसमें 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();

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

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

हालांकि, यह Analytics और इससे मिलते-जुलते इस्तेमाल के उदाहरणों के लिए सही हो सकता है, लेकिन अन्य मामलों में आपको उन मामलों के लिए ज़्यादा कॉन्टेंट लोड करना पड़ सकता है. इसलिए, हो सकता है कि आप खास तौर पर प्रीरेंडरिंग पेजों को टारगेट करने के लिए, 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 से Core Web Vitals को मेज़र किया जाता है. इनका मकसद, उपयोगकर्ता अनुभव को मेज़र करना है. इसलिए, इन्हें चालू होने के समय के आधार पर मेज़र किया जाता है. इससे अक्सर एलसीपी शून्य सेकंड हो जाता है. उदाहरण के लिए, इससे पता चलता है कि यह Core Web Vitals को बेहतर बनाने का एक शानदार तरीका है.

वर्शन 3.1.0 से, web-vitals लाइब्रेरी को अपडेट किया गया है, ताकि पहले से रेंडर किए गए नेविगेशन को उसी तरह मैनेज किया जा सके जिस तरह Chrome, Core Web Vitals को मेज़र करता है. अगर पेज को पूरी तरह या कुछ हद तक प्रीरेंडर किया गया है, तो यह वर्शन 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 की टीम, प्रीरेंडर की ज़रूरी शर्तों की जांच करने के लिए अतिरिक्त टूल जोड़ने पर विचार कर रही है. यह टूल, शायद बीएफ़कैश टेस्टिंग टूल जैसा होगा. साथ ही, वह एक ऐसा एपीआई भी जोड़ सकती है जिससे यह पता चल सके कि प्रीरेंडर की प्रोसेस क्यों पूरी नहीं हो पाई.

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

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

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

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

Acknowledgements

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