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

Barry Pollard

ब्राउज़र सहायता

• 109
• 109
• x
• x

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

प्रीरेंडरिंग का छोटा इतिहास

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Chrome के पता बार के सुझाव देखें

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

Chrome पूर्वानुमान पेज.

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

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

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

पता बार 'Typeahead' सुविधा.

आपके टाइप किए जाने और चुने गए विकल्पों के आधार पर, 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": {"selector_matches": ".do-not-prerender"}},
        { "not": {"selector_matches": "[rel=nofollow]"}}
      ]
    }
  }]
}
</script>

ध्यान दें: अनुमान के नियम एपीआई में source कुंजी को शामिल किया जाता था, जिसे यूआरएल की सूची के लिए list या दस्तावेज़ के यूआरएल के लिए document पर सेट किया गया था. हालांकि, इसे urls या where कुंजी (जो म्युचुअली एक्सक्लूसिव हैं) की मौजूदगी से लागू किया जा सकता है, इसलिए इस ज़रूरी शर्त को Chrome 121 से हटा दिया गया. आपको अब भी कुछ साइटों पर इस्तेमाल की गई source कुंजी या उदाहरण वाले कोड दिख सकते हैं.

उत्सुकता

ब्राउज़र सहायता

• 121
• 121
• x
• x

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

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

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

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

प्रीफ़ेच करें

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

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

ध्यान दें: एचटीटीपी की कैश मेमोरी में प्रीफ़ेच किए गए पुराने <link rel="prefetch"> रिसॉर्स हिंट के उलट, अनुमान के नियमों का इस्तेमाल करके लोड किए गए दस्तावेज़ों को उसी तरह प्रोसेस किया जाता है जिस तरह नेविगेशन किया जाता है (लेकिन उसके बाद रेंडर नहीं किया जाता). साथ ही, उन्हें मेमोरी में रखा जाता है. इसलिए, ज़रूरत पड़ने पर ब्राउज़र पर वे तेज़ी से उपलब्ध होंगे. इसकी मदद से, एचटीटीपी कैश मेमोरी में सेव नहीं किए गए दस्तावेज़ों को प्रीफ़ेच भी किया जा सकता है. <link rel="prefetch"> का इस्तेमाल करके दस्तावेज़ों को प्रीफ़ेच करने से जुड़ी समस्याओं की वजह से, हमारा सुझाव है कि आने वाले समय में इन दस्तावेज़ों के लिए अनुमान लगाने के नियमों का इस्तेमाल करें. <link rel="prefetch"> का इस्तेमाल सिर्फ़ सबरिसॉर्स को प्रीफ़ेच करने के लिए किया जाएगा.

Chrome की सीमाएं

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

उत्सुकता	प्रीफ़ेच करें	प्रीरेंडर
immediate / eager	50	10
moderate / conservative	2 (एफ़आईएफ़ओ)	2 (एफ़आईएफ़ओ)

Chrome में अनुमान लगाने की सीमाएं.

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

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

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

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

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

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

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

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

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

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

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

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

ब्राउज़र सहायता

• 121
• 121
• x
• x

सोर्स

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

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

Speculation-Rules: "/speculationrules.json"

चेतावनी: यह एक स्ट्रक्चर्ड हेडर है, इसलिए कोटेशन ज़रूरी हैं और हेडर की वैल्यू में इन्हें शामिल करना ज़रूरी है.

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

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 सहायता

ब्राउज़र सहायता

• 121
• 121
• x
• x

सोर्स

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

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

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

No-var-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, दोनों के लिए एक जैसा है. हालांकि, 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 एचटीटीपी हेडर के साथ ऑप्ट-इन करती है). साथ ही, नए टैब में प्रीरेंडरिंग की सुविधा चालू भी हो सकती है.

अनुमान लगाने के नियम वाले एपीआई से जुड़ी सहायता का पता लगाएं

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

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

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

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

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

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

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 या 304 नहीं दिखाता है.

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

JavaScript में प्रीरेंडरिंग का पता लगाएं

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

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

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

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

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

कंसोल में प्रीरेंडरिंग की जांच करना.

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

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

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

चेतावनी: PerformanceNavigationTiming.type prerender वैल्यू का इस्तेमाल नहीं किया जाता, जो कि पुराने, ओरिजनल <link rel="prerender"...> नेविगेशन टाइप के लिए थी. आने वाले समय में यह बदलाव हो सकता है. हालांकि, फ़िलहाल क्लाइंट को प्रीरेंडरिंग वाले पेजों की पहचान करने के लिए document.prerendering API का इस्तेमाल करना चाहिए. साथ ही, पहले से रेंडर किए गए पेजों की पहचान करने के लिए, शून्य PerformanceNavigationTiming.activationStart फ़ील्ड का इस्तेमाल करना चाहिए.

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

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

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

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

ध्यान दें: Google Analytics, प्रीरेंडरिंग को मैनेज करता है. ऐसा इसलिए होता है, क्योंकि वह डिफ़ॉल्ट रूप से ऐक्टिवेट होने में देरी करता है. Google पब्लिशर टैग (GPT) और Google AdSense के चालू होने में भी देरी होती है.

ऐसा 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);
  } else {
    resolve();
  }
});

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

initAnalytics();

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

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

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

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

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

• अनुमान लगाने के नियमों को डीबग करना
• पेश है NoState प्रीफ़ेच
• अनुमान के नियम का एपीआई
• नेविगेशन का अनुमान लगाने के लिए GitHub का रेपो
• Chrome एक्सटेंशन: झटपट नेविगेशन के साथ काम करने वाले एपीआई को बढ़ाना

स्वीकार हैं

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