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

Barry Pollard

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Speculation Rules API

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

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

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

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

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

उत्सुकता

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

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

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

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

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

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

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

प्रीफ़ेच

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

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

Chrome की सीमाएं

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Speculation-Rules: "/speculationrules.json"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

No-Vary-Search सहायता

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Chrome में प्रीरेंडरिंग सक्षम और अक्षम करना

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

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

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

Sec-Purpose: prefetch;prerender

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

Sec-Purpose: prefetch

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

initAnalytics();

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

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

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

initAnalytics();

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

धन्यवाद

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