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

Barry Pollard

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

• 109
• 109
• x
• x

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

क्या आपको वीडियो पढ़ना पसंद है? इस पेज पर मौजूद कॉन्टेंट के बारे में जानने के लिए, Google I/O का यह वीडियो देखें.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

उत्सुकता

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

• 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 विकल्प बीच का विकल्प है. कई साइटों को अनुमान लगाने के इन नियम का फ़ायदा मिल सकता है. यह नियम, 200 मिलीसेकंड के लिए पॉइंटर को लिंक पर या पॉइंटरडाउन इवेंट पर, बुनियादी तौर पर होल्ड करने पर, लिंक को प्रीरेंडर करेगा. हालांकि, अनुमान लगाने के नियम लागू करने से ये नियम लागू हो जाते हैं:

<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 को तब तक रेंडर नहीं करता है, जब तक Chrome को चालू नहीं किया जाता.

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

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

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

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

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

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

Google Tag Manager की मदद से, अनुमान लगाने के नियम जोड़ना.

ध्यान दें कि इस उदाहरण में 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 या 304), तो पेज को पहले से रेंडर नहीं किया जाएगा. साथ ही, प्रीफ़ेच किए गए पेज को खारिज कर दिया जाएगा.

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

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

इन एपीआई का इस्तेमाल करके, फ़्रंटएंड 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, {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 भी रेंडर नहीं होते हैं, इसलिए इस तरह के कॉन्टेंट को मैन्युअल तौर पर रोकना ज़रूरी होता है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

स्वीकार की गई

Unस्प्लैश पर मार्क-ओलिवियर जोडोइन ने थंबनेल इमेज बनाई