पब्लिश करने की तारीख: 07 मार्च, 2025
अनुमान के आधार पर तय किए गए नियमों वाला एपीआई, उपयोगकर्ताओं को परफ़ॉर्मेंस को बेहतर बनाने में मदद करता है. इसके लिए, आने वाले समय में इस्तेमाल होने वाले पेज नेविगेशन को प्रीफ़ेच या प्रीरेंडर किया जाता है, ताकि पेज नेविगेशन तुरंत या तुरंत के बाद दिख सकें.
एपीआई को खास तौर पर, आसानी से लागू करने के मकसद से डिज़ाइन किया गया है. हालांकि, इसका इस्तेमाल करने से पहले, खास तौर पर जटिल साइटों को कुछ बातों का ध्यान रखना होगा. इस गाइड से, साइट के मालिकों को इन बातों को समझने में मदद मिलती है.
प्लानिंग
अनुमान लगाने से जुड़े नियम लागू करने से पहले, एपीआई को लागू करने का तरीका (इसके कुछ विकल्प हैं) और अनुमान लगाने की लागत (इससे आपको यह तय करने में मदद मिलेगी कि किन पेजों के लिए अनुमान लगाना है) पर विचार करना ज़रूरी है.
अनुमान लगाने के नियमों को लागू करने का तरीका तय करना
आपको सबसे पहले यह तय करना होगा कि अपनी साइट पर सट्टेबाज़ी के नियमों को कैसे लागू किया जाए. इसके लिए, कई तरीके इस्तेमाल किए जा सकते हैं:
- सीधे पेज के एचटीएमएल में
- JavaScript का इस्तेमाल करना
- एचटीटीपी हेडर का इस्तेमाल करना
आखिर में, हर तरीके का एक ही असर होता है. हालांकि, लागू करने में आसानी और सुविधा के मामले में फ़ायदे हो सकते हैं.
साइटों को अपनी ज़रूरत के हिसाब से विकल्प चुनना चाहिए. ज़रूरत पड़ने पर, वे इन विकल्पों के कॉम्बिनेशन का भी इस्तेमाल कर सकती हैं. इसके अलावा, इन्हें किसी प्लग इन (जैसे, WordPress के लिए Speculative Loading प्लग इन) या लाइब्रेरी या प्लैटफ़ॉर्म का इस्तेमाल करके लागू किया जा सकता है. ये प्लग इन या लाइब्रेरी या प्लैटफ़ॉर्म, आपके लिए यह विकल्प चुन सकते हैं. हालांकि, उपलब्ध विकल्पों के बारे में जानना ज़रूरी है.
अनुमान लगाने के नियमों को सीधे पेज के एचटीएमएल में शामिल करना
अनुमान लगाने से जुड़े नियमों को सीधे पेज पर लागू किया जा सकता है. इसके लिए, पेज के एचटीएमएल में <script type="speculationrules"> एलिमेंट शामिल करें. टेंप्लेट का इस्तेमाल करके, स्टैटिक साइटों के लिए इसे बिल्ड टाइम पर जोड़ा जा सकता है. इसके अलावा, पेज का अनुरोध किए जाने पर, सर्वर इसे रन टाइम पर जोड़ सकता है. एज वर्कर्स, उन्हें एचटीएमएल में भी इंजेक्ट कर सकते हैं. हालांकि, इसके लिए एचटीटीपी हेडर का तरीका इस्तेमाल करना ज़्यादा आसान है. इस बारे में इस गाइड में आगे बताया गया है.
इसकी मदद से, पूरी साइट पर स्टैटिक नियम शामिल किए जा सकते हैं. हालांकि, दस्तावेज़ के नियम अब भी डाइनैमिक हो सकते हैं. इसके लिए, आपको पेज से रेंडर करने के लिए यूआरएल चुनने की सुविधा मिलती है. इसके लिए, सीएसएस क्लास से ट्रिगर होने वाले नियमों का इस्तेमाल किया जाता है:
<script type="speculationrules">
{
"prerender": [{
"where": { "selector_matches": ".prerender" }
}],
"prefetch": [{
"where": { "selector_matches": ".prefetch" }
}]
}
</script>
पिछली स्क्रिप्ट, prerender क्लास वाले लिंक को पहले से रेंडर करेगी. इसी तरह, अगर किसी लिंक में prefetch क्लास है, तो उसे पहले से लोड करेगी. इससे डेवलपर, एचटीएमएल में इन क्लास को शामिल करके, अनुमान ट्रिगर कर सकते हैं.
इन क्लास को पेज के शुरुआती HTML में लिंक के तौर पर शामिल करने के अलावा, अगर आपके ऐप्लिकेशन ने डाइनैमिक तौर पर ये क्लास जोड़ी हैं, तो इनके लिए भी अनुमान लगाया जाएगा. इससे आपके ऐप्लिकेशन को ज़रूरत के हिसाब से अनुमान ट्रिगर करने और हटाने की सुविधा मिलती है. यह, अनुमान से जुड़े ज़्यादा सटीक नियम बनाने या हटाने के मुकाबले आसान हो सकता है. अगर आपको साइट के ज़्यादातर पेजों पर इस्तेमाल होने वाला बुनियादी नियम और पेज के हिसाब से नियम चाहिए, तो हर पेज पर हर पेज के लिए अनुमान के कई नियम शामिल किए जा सकते हैं.
इसके अलावा, अगर आपको अनुमान लगाने के लिए ज़्यादा सटीक नियमों का इस्तेमाल करना है, तो पेज या टेंप्लेट के हिसाब से बनाए गए नियमों की मदद से, कुछ पेजों या पेज टाइप के लिए अलग-अलग नियम बनाए जा सकते हैं.
आखिर में, सर्वर साइड रेंडर किए गए पेजों में, सर्वर के पास मौजूद जानकारी के आधार पर ज़्यादा डाइनैमिक नियम भी हो सकते हैं. जैसे, उस पेज के लिए आंकड़ों की जानकारी या कुछ पेजों के लिए सामान्य उपयोगकर्ता के सफ़र की जानकारी.
JavaScript का इस्तेमाल करके, अनुमान लगाने के नियम जोड़ना
नियमों को पेज पर मौजूद स्क्रिप्ट में शामिल करने के बजाय, उन्हें JavaScript का इस्तेमाल करके इंजेक्ट किया जा सकता है. इससे, पेज टेंप्लेट को कम अपडेट करना पड़ सकता है. उदाहरण के लिए, टैग मैनेजर से नियम इंजेक्ट करने पर, अनुमान के नियमों को तुरंत रोल आउट किया जा सकता है. साथ ही, ज़रूरत पड़ने पर उन्हें तुरंत बंद भी किया जा सकता है.
इस विकल्प की मदद से, उपयोगकर्ता के पेज से इंटरैक्ट करने के तरीके के आधार पर, डाइनैमिक क्लाइंट-साइड नियम भी बनाए जा सकते हैं. उदाहरण के लिए, अगर उपयोगकर्ता बास्केट में कोई आइटम जोड़ता है, तो चेकआउट पेज को पहले से रेंडर किया जा सकता है. इसके अलावा, इसका इस्तेमाल कुछ खास स्थितियों के आधार पर अनुमान ट्रिगर करने के लिए भी किया जा सकता है. एपीआई में इगरीनेस सेटिंग शामिल होती है, जो इंटरैक्शन पर आधारित बुनियादी नियमों की अनुमति देती है. वहीं, JavaScript की मदद से डेवलपर अपने लॉजिक का इस्तेमाल करके यह तय कर सकते हैं कि किस पेज पर और कब अनुमान लगाना है.
जैसा कि पहले बताया गया है, नए नियम डालने का एक अन्य तरीका यह है कि पेज पर कोई बुनियादी दस्तावेज़ नियम हो और लिंक में सही क्लास जोड़कर, JavaScript दस्तावेज़ नियमों को ट्रिगर किया जाए, ताकि वे नियम से मैच कर सकें.
एचटीटीपी हेडर का इस्तेमाल करके, अनुमान लगाने के नियम जोड़ना
डेवलपर के पास, एचटीटीपी हेडर का इस्तेमाल करके नियम शामिल करने का आखिरी विकल्प होता है:
Speculation-Rules: "/speculationrules.json"
नियमों के रिसॉर्स (इस उदाहरण में /speculationrules.json) को डिलीवर और इस्तेमाल करने के तरीके से जुड़ी कुछ अन्य ज़रूरी शर्तें हैं.
इस विकल्प की मदद से, सीडीएन के ज़रिए दस्तावेज़ को आसानी से डिप्लॉय किया जा सकता है. इसके लिए, दस्तावेज़ के कॉन्टेंट में बदलाव करने की ज़रूरत नहीं होती. इसका मतलब है कि JavaScript का इस्तेमाल करके, अनुमान लगाने के नियमों में डाइनैमिक तरीके से बदलाव नहीं किया जा सकता. हालांकि, सीएसएस सिलेक्टर ट्रिगर वाले दस्तावेज़ के नियमों में अब भी डाइनैमिक बदलाव किए जा सकते हैं. उदाहरण के लिए, किसी लिंक से prerender क्लास को हटाकर.
JavaScript विकल्प की तरह ही, एचटीटीपी हेडर की मदद से अनुमान लगाने के नियम लागू करने पर, उन्हें साइट के कॉन्टेंट से अलग से लागू किया जा सकता है. इससे, साइट को फिर से बनाने के बिना नियमों को जोड़ना और हटाना आसान हो जाता है.
लागत के असर को ध्यान में रखें
अनुमान लगाने से जुड़े नियम लागू करने से पहले, इस एपीआई की मदद से अपने उपयोगकर्ताओं और साइट, दोनों के लिए लागत के असर पर थोड़ा समय दें. इनमें बैंडविड्थ (इसकी वजह से उपयोगकर्ताओं और साइटों, दोनों को पैसे चुकाने पड़ते हैं!) और प्रोसेसिंग की लागत (क्लाइंट और सर्वर, दोनों साइड पर) शामिल है.
उपयोगकर्ताओं के लिए लागत को ध्यान में रखना
अनुमान के हिसाब से यूआरएल लोड होने का मतलब है, यह अनुमान लगाना कि उपयोगकर्ता कहां पर जा सकता है. हालांकि, अगर नेविगेशन नहीं होता है, तो हो सकता है कि आपने संसाधनों को बर्बाद किया हो. इसलिए, आपको उपयोगकर्ताओं पर पड़ने वाले असर के बारे में पता होना चाहिए. खास तौर पर:
- आने वाले समय में इस्तेमाल होने वाले नेविगेशन को डाउनलोड करने के लिए ज़्यादा बैंडविड्थ का इस्तेमाल किया जाता है. खास तौर पर, मोबाइल पर, जहां बैंडविड्थ की कमी हो सकती है.
- पेजों को पहले से रेंडर करने की सुविधा का इस्तेमाल करने पर, उन पेजों को रेंडर करने के लिए प्रोसेसिंग की ज़्यादा लागत.
पूरी तरह सटीक अनुमान लगाने पर, कोई अतिरिक्त शुल्क नहीं देना पड़ता. ऐसा इसलिए है, क्योंकि विज़िटर अगले पेज पर जाएंगे. हालांकि, इस बात में अंतर है कि उन पेजों के लिए शुल्क पहले ही लिया जाता है. हालांकि, आने वाले समय में क्या होगा, इसका सटीक अनुमान लगाना असंभव है. साथ ही, अनुमान लगाने की रणनीति जितनी आक्रामक होगी, पैसे बर्बाद होने का जोखिम उतना ही ज़्यादा होगा.
Chrome ने इस समस्या पर ध्यान से विचार किया है. साथ ही, एपीआई में कई सुविधाएं शामिल हैं. इसका मतलब है कि इसकी लागत आपकी सोच से काफ़ी कम है. खास तौर पर, एचटीटीपी कैश का फिर से इस्तेमाल करके और क्रॉस-ऑरिजिन iframes को लोड न करके, एक ही साइट पर नेविगेशन को पहले से रेंडर करने की लागत, अक्सर बिना कैश किए गए संसाधनों वाले पूरे पेज की लागत से काफ़ी कम होती है. इससे अनुमानित लोड की लागत, अनुमान से कम हो जाती है.
हालांकि, इन सुरक्षा उपायों के बावजूद, साइटों को इस बात का ध्यान रखना चाहिए कि किन पेजों के लिए अनुमान लगाया जाए. साथ ही, इस बात का भी ध्यान रखना चाहिए कि इस तरह के अनुमान से उपयोगकर्ताओं को क्या नुकसान हो सकता है. अनुमानित लोडिंग के लिए, ऐसे पेजों को चुना जाता है जिनके लोड होने का अनुमान, आंकड़ों या आम तौर पर उपयोगकर्ताओं के सफ़र के आधार पर, ज़्यादा कॉन्फ़िडेंस के साथ लगाया जा सकता है. साथ ही, इन पेजों की लागत कम होनी चाहिए. उदाहरण के लिए, कम रिच पेज.
यह भी तय किया जा सकता है कि किस JavaScript को चालू होने तक इंतज़ार करना चाहिए. कॉन्टेंट को ज़रूरत पड़ने तक लेज़ी लोड करने की तरह ही, इससे प्री-रेंडर को सस्ता बनाया जा सकता है. हालांकि, इससे उपयोगकर्ता को बेहतर अनुभव मिलता है. कम कीमत पर अनुमान लगाने की सुविधा से, आपको ज़्यादा बार या उत्सुकता से अनुमान लगाने में आसानी हो सकती है.
अगर ऐसा नहीं किया जा सकता, तो मध्यम या कंज़र्वेटिव, उत्सुकता के नियमों का इस्तेमाल करके, कम आक्रामक रणनीति का सुझाव दिया जाता है. इसके अलावा, प्रीफ़ेच का इस्तेमाल किया जा सकता है. कॉन्फ़िडेंस लेवल कम होने पर, इसकी लागत, पेज को पहले से रेंडर करने की लागत से काफ़ी कम होती है. कॉन्फ़िडेंस लेवल बढ़ने पर, इसे पूरी तरह से रेंडर करने की सुविधा पर अपग्रेड किया जा सकता है. उदाहरण के लिए, जब किसी लिंक पर कर्सर घुमाया जाता है या उस पर क्लिक किया जाता है.
बैकएंड पर अतिरिक्त लोड
साइट के मालिकों को उपयोगकर्ता से लिए जाने वाले अतिरिक्त शुल्क के साथ-साथ, अपने इन्फ़्रास्ट्रक्चर की लागत पर भी ध्यान देना चाहिए. अगर हर पेज के लिए दो, तीन या उससे ज़्यादा पेज लोड होते हैं, तो इस एपीआई का इस्तेमाल करने पर, बैकएंड की लागत बढ़ सकती है.
यह पक्का करने पर कि आपके पेज और रिसॉर्स कैश मेमोरी में सेव किए जा सकते हैं, ऑरिजिन लोड की संख्या काफ़ी कम हो जाएगी. इससे, कुल जोखिम भी कम हो जाएगा. सीडीएन के साथ इस्तेमाल करने पर, आपके ओरिजिन सर्वर पर कम से कम लोड दिखेगा. हालांकि, सीडीएन की लागत में होने वाली बढ़ोतरी को ध्यान में रखें.
sec-purpose एचटीटीपी हेडर की पहचान के आधार पर, अनुमान के नतीजों को कंट्रोल करने के लिए भी सर्वर या सीडीएन का इस्तेमाल किया जा सकता है. उदाहरण के लिए, Cloudflare का Speed Brain प्रॉडक्ट, सीडीएन के एज सर्वर पर सिर्फ़ उन अनुमानों को अनुमति देता है जो पहले से कैश मेमोरी में सेव हैं. साथ ही, यह अनुरोधों को ऑरिजिन पर वापस नहीं भेजेगा.
हालांकि, आम तौर पर अनुमानित लोड का इस्तेमाल, एक ही ऑरिजिन वाले पेज के लोड के लिए किया जाता है. इसलिए, उपयोगकर्ताओं के पास अपने ब्राउज़र की कैश मेमोरी में पहले से ही शेयर किए गए संसाधन होंगे. ऐसा तब माना जाता है, जब वे संसाधन पहले से ही कैश मेमोरी में सेव किए जा सकते हों. इसलिए, आम तौर पर अनुमानित लोड, पूरे पेज के लोड के मुकाबले कम खर्चीला होता है.
अनुमान लगाने के लिए ज़रूरत से ज़्यादा या कम समय न लगाएं
सप्लाई में उतार-चढ़ाव के नियमों वाले एपीआई का ज़्यादा से ज़्यादा फ़ायदा पाने के लिए, यह ज़रूरी है कि आप बहुत ज़्यादा अनुमान न लगाएं. इसका मतलब है कि ज़रूरत से ज़्यादा शुल्क न चुकाएं और अनुमान का इस्तेमाल न करें. साथ ही, बहुत कम या बहुत देर से अनुमान न लगाएं, ताकि आपको ज़्यादा से ज़्यादा फ़ायदा मिल सके.
जहां लागत कम होती है (उदाहरण के लिए, सीडीएन एज नोड पर कैश किए गए छोटे, स्टैटिक तौर पर जनरेट किए गए पेज), वहां अनुमान लगाने के लिए ज़्यादा जोखिम उठाया जा सकता है.
हालांकि, बड़े और बेहतर पेजों के लिए, ज़्यादा सावधानी बरतनी चाहिए. ऐसा इसलिए, क्योंकि शायद इन्हें सीडीएन एज पर कैश मेमोरी में सेव नहीं किया जा सकता. इसी तरह, ज़्यादा संसाधनों वाले पेज, नेटवर्क बैंडविड्थ या प्रोसेसिंग पावर का इस्तेमाल कर सकते हैं. इससे मौजूदा पेज पर बुरा असर पड़ सकता है. एपीआई का मकसद परफ़ॉर्मेंस को बेहतर बनाना है. इसलिए, हम परफ़ॉर्मेंस में गिरावट नहीं चाहते! यह एक और वजह है कि प्री-रेंडर की संख्या को ज़्यादा से ज़्यादा एक या दो पेजों तक ही सीमित रखा जाए. यह भी ध्यान रखें कि Chrome, एक बार में दो या ज़्यादा प्री-रेंडर करने की सुविधा देता है. हालांकि, यह इस बात पर निर्भर करता है कि उपयोगकर्ता कितनी जल्दी पेज देखना चाहता है.
अनुमान लगाने के नियमों को लागू करने का तरीका
अनुमान लगाने से जुड़े नियमों को लागू करने का तरीका तय करने के बाद, आपको यह तय करना होगा कि अनुमान किस बारे में लगाया जाए और इसे कैसे रोल आउट किया जाए. स्टैटिक निजी ब्लॉग जैसी आसान साइटें, कुछ पेजों को पूरी तरह से पहले से रेंडर कर सकती हैं. हालांकि, ज़्यादा जटिल साइटों के लिए, कुछ और बातों का ध्यान रखना पड़ता है.
प्रीफ़ेच से शुरू करना
आम तौर पर, ज़्यादातर साइटों के लिए प्रीफ़ेच को लागू करना सुरक्षित होता है. कई लोग शुरुआत में यही तरीका अपनाते हैं. इनमें Cloudflare और WordPress जैसे बड़े रोल आउट भी शामिल हैं.
इन मुख्य समस्याओं के बारे में पता होना ज़रूरी है: अगर किसी यूआरएल को पहले से लोड करने से, स्टेटस में कोई बदलाव होता है और सर्वर साइड की लागत बढ़ती है, तो खास तौर पर उन पेजों के लिए ऐसा हो सकता है जिन्हें कैश मेमोरी में सेव नहीं किया जा सकता. आम तौर पर, स्टेटस में होने वाले बदलावों को GET लिंक के तौर पर लागू नहीं किया जाना चाहिए. उदाहरण के लिए, /logout पेज को पहले से लोड करना. हालांकि, अफ़सोस की बात है कि वेब पर ऐसा होना आम बात है.
इन यूआरएल को खास तौर पर नियमों से बाहर रखा जा सकता है:
<script type="speculationrules">
{
"prefetch": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
पेज को पहले से लोड करने की सुविधा को, एक पेज से दूसरे पेज पर जाने के सामान्य नेविगेशन तक सीमित किया जा सकता है. इसके अलावा, moderate या conservative eagerness सेटिंग का इस्तेमाल करके, एक ही ऑरिजिन के सभी लिंक के लिए, कर्सर घुमाने या क्लिक करने पर भी पेज को पहले से लोड किया जा सकता है. conservative सेटिंग में जोखिम सबसे कम होता है. हालांकि, इसमें कमाई करने की संभावना भी सबसे कम होती है. अगर आपने अभी-अभी शुरू किया है, तो कम से कम moderate तक अपग्रेड करें. हालांकि, eager तक अपग्रेड करने पर परफ़ॉर्मेंस बेहतर होगी. इसके बाद, prerender तक अपग्रेड करें.
कम जोखिम वाले प्रीरेंडर
प्रीफ़ेच किए गए अनुमान को डिप्लॉय करना आसान है, लेकिन एपीआई की परफ़ॉर्मेंस को बेहतर बनाने के लिए, प्री-रेंडर का इस्तेमाल करना ज़्यादा बेहतर है. अगर अनुमान लगाने के कुछ समय बाद पेज पर विज़िट नहीं की जाती है, तो इस पर कुछ और बातें लागू हो सकती हैं. इस बारे में हम अगले सेक्शन में बताएंगे. हालांकि, moderate या conservative प्री-रेंडर की मदद से, अगर कुछ समय बाद नेविगेशन की संभावना है, तो अगले चरण में जोखिम कम हो सकता है.
<script type="speculationrules">
{
"prerender": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
सामान्य पेजों को प्रीफ़ेच करके, बिना रीडायरेक्ट किए पेजों को पहले से रेंडर करने की सुविधा को बेहतर बनाना
एक आम रणनीति यह है कि eager सेटिंग की मदद से, अक्सर विज़िट किए जाने वाले अगले पेजों को लोड होने से पहले ही प्रीफ़ेच किया जाए. इसके लिए, उन्हें यूआरएल की सूची में शामिल किया जा सकता है या selector_matches का इस्तेमाल किया जा सकता है. इसके बाद, moderate सेटिंग की मदद से, पेजों को पहले से रेंडर किया जा सकता है. लिंक पर कर्सर घुमाने के समय तक, एचटीएमएल प्रीफ़ेच की प्रोसेस पूरी हो जाती है. इससे, प्रीफ़ेच के बिना कर्सर घुमाने पर प्री-रेंडरिंग की तुलना में बेहतर परफ़ॉर्मेंस मिलती है.
<script type="speculationrules">
{
"prefetch": [{
"urls": ["next.html", "next2.html"],
"eagerness": "eager"
}],
"prerender": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
पहले से रेंडर किए गए पेज
moderate दस्तावेज़ के नियमों की मदद से, एपीआई का इस्तेमाल कम जोखिम के साथ किया जा सकता है. साथ ही, इसे लागू करना भी आसान होता है. हालांकि, आम तौर पर, पेज को पूरी तरह से पहले से रेंडर करने के लिए, यह समय काफ़ी नहीं होता. इस एपीआई की मदद से, पेज पर तुरंत नेविगेट करने की सुविधा पाने के लिए, आपको पेजों को ज़्यादा तेज़ी से प्री-रेंडर करना होगा.
ऐसा, यूआरएल की स्टैटिक सूची (जैसे कि पहले दिए गए प्रीफ़ेच के उदाहरण में) या selector_matches की मदद से किया जाता है. इसमें, कुछ यूआरएल (आम तौर पर एक या दो पेज) की पहचान की जाती है. साथ ही, अन्य यूआरएल के लिए दस्तावेज़ के नियम लागू किए जाते हैं:
<script type="speculationrules">
{
"prerender": [
{
"where": {
"selector_matches": : ".prerender"
},
"eagerness": "eager",
},
{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}
]
}
</script>
अगले नेविगेशन का सटीक अनुमान लगाने के लिए, ट्रैफ़िक का विश्लेषण करना पड़ सकता है. अपनी साइट पर ग्राहक के सफ़र को समझने से, अनुमानित लोडिंग के लिए अच्छे विकल्पों की पहचान करने में भी मदद मिल सकती है.
ज़्यादा तेज़ी से पेज को पहले से रेंडर करने की सुविधा का इस्तेमाल करने पर, Analytics, विज्ञापनों, और JavaScript के बारे में ज़्यादा बातें हो सकती हैं. साथ ही, पहले से रेंडर किए गए पेज को अप-टू-डेट रखने या स्थिति में बदलाव होने पर अनुमानों को रद्द करने या रीफ़्रेश करने की ज़रूरत भी पड़ सकती है.
Analytics, विज्ञापन, और JavaScript
पहले से रेंडर करने की सुविधा का इस्तेमाल करते समय, ज़्यादा जटिल साइटों को आंकड़ों पर पड़ने वाले असर का भी ध्यान रखना चाहिए. आम तौर पर, पेज के अनुमानित होने पर, पेज (या विज्ञापन) व्यू को लॉग नहीं किया जाता. ऐसा सिर्फ़ तब किया जाता है, जब अनुमान लगाने की सुविधा चालू हो.
आंकड़ों की सेवा देने वाली कुछ कंपनियां (जैसे, Google Analytics) और विज्ञापन की सेवा देने वाली कुछ कंपनियां (जैसे, Google पब्लिशर टैग), पहले से ही अनुमान के नियमों के साथ काम करती हैं. साथ ही, जब तक पेज चालू नहीं हो जाता, तब तक वे व्यू को लॉग नहीं करतीं. हालांकि, आपने जिन अन्य सेवा देने वाली कंपनियों या कस्टम ऐनलिटिक्स का इस्तेमाल किया है उनके लिए ज़्यादा ध्यान देने की ज़रूरत हो सकती है.
JavaScript में जांच जोड़ी जा सकती है, ताकि पेज चालू होने या दिखने तक कोड के कुछ हिस्सों को लागू होने से रोका जा सके. साथ ही, पूरे <script> एलिमेंट को ऐसी जांच में लपेटा जा सकता है. अगर पेज ऐसी स्क्रिप्ट इंजेक्ट करने के लिए टैग मैनेजर का इस्तेमाल करते हैं, तो Tag Manager स्क्रिप्ट में देरी करके, इन सभी समस्याओं को एक साथ हल किया जा सकता है.
इसी तरह, सहमति मैनेजर की मदद से, तीसरे पक्ष की स्क्रिप्ट को चालू होने तक रोका जा सकता है. Google, सहमति मैनेज करने वाले अलग-अलग प्लैटफ़ॉर्म के साथ मिलकर काम कर रहा है, ताकि उन्हें प्री-रेंडर करने की सुविधा मिल सके. हमें उन लोगों की मदद करके खुशी होगी जो ऐसा करना चाहते हैं. PubTech ऐसी ही एक कंपनी है जो डेवलपर को प्री-रेंडरिंग के दौरान, अपने JavaScript को चलाने या ब्लॉक करने का विकल्प देती है.
ऐप्लिकेशन कोड के लिए, ऐक्टिवेशन होने तक कोड के एक्ज़ीक्यूशन में देरी करने के लिए, इसी तरह बदलाव जोड़ा जा सकता है. ऐसा खास तौर पर तब किया जा सकता है, जब पेज को रेंडर करने के लिए JavaScript कोड की ज़रूरत न हो. यह तेज़ और सुरक्षित विकल्प है. हालांकि, इसका मतलब है कि चालू होने पर, सारा कोड एक साथ चलेगा. इस वजह से, ट्रिगर होने के समय काफ़ी काम हो सकता है. इससे INP पर असर पड़ सकता है. ऐसा इसलिए, क्योंकि पेज पूरी तरह से लोड हो सकता है और इंटरैक्ट करने के लिए तैयार हो सकता है.
इसके अलावा, अगर कोई कॉन्टेंट JavaScript पर निर्भर करता है (उदाहरण के लिए, क्लाइंट-साइड रेंडर किया गया कॉन्टेंट), तो इसकी देरी करने से LCP और CLS पर होने वाले अच्छे असर में कमी आएगी. प्री-रेंडरिंग के दौरान ज़्यादा JavaScript को चलाने की अनुमति देने के लिए, ज़्यादा टारगेट किए गए तरीके से बेहतर अनुभव मिलता है. हालांकि, इसे लागू करना आसान नहीं होता.
शुरुआत में, ज़्यादा जटिल साइटों के लिए, कई स्क्रिप्ट टैग को पूरी तरह से देर से लोड करने की रणनीति अपनाना अच्छा हो सकता है. हालांकि, एपीआई का ज़्यादा से ज़्यादा फ़ायदा पाने के लिए, प्री-रेंडरिंग के दौरान ज़्यादा से ज़्यादा JavaScript को चलाने की अनुमति देना ज़रूरी है.
आंकड़ों या विज्ञापनों से जुड़ी समस्याओं वाली साइटें भी प्रीफ़ेच से शुरू कर सकती हैं. यहां इन समस्याओं की कम संभावना होती है. साथ ही, वे यह भी तय कर सकती हैं कि प्री-रेंडरिंग की सुविधा के लिए क्या करना होगा.
पेज को पहले से रेंडर करने से जुड़े अनुमान अपडेट करना
नेविगेशन से पहले पेजों को पहले से रेंडर करने पर, इस बात का खतरा होता है कि पहले से रेंडर किया गया पेज पुराना हो जाए. उदाहरण के लिए, किसी ई-कॉमर्स साइट के पहले से रेंडर किए गए पेज में चेकआउट बास्केट शामिल हो सकता है. यह बास्केट, सामानों से भरा हो सकता है या सिर्फ़ एक काउंटर हो सकता है, जो दूसरे पेजों पर बास्केट में मौजूद सामान की संख्या दिखाता हो. अगर बास्केट में ज़्यादा आइटम जोड़े जाते हैं और फिर पहले से रेंडर किए गए पेज पर नेविगेट किया जाता है, तो उपयोगकर्ता को चेकआउट की पुरानी स्थिति दिखेगी.
यह कोई नई समस्या नहीं है. जब उपयोगकर्ताओं के ब्राउज़र में कई टैब खुले होते हैं, तो उन्हें भी यही समस्या आती है. हालांकि, पहले से रेंडर किए गए पेजों के लिए, इस बात की संभावना ज़्यादा होती है और यह अचानक भी हो सकता है. इसकी वजह यह है कि उपयोगकर्ता ने जान-बूझकर पेज को पहले से रेंडर नहीं किया है.
Broadcast Channel API, ब्राउज़र में मौजूद किसी पेज को दूसरे पेजों पर इस तरह के अपडेट ब्रॉडकास्ट करने की अनुमति देने का एक तरीका है. इससे एक से ज़्यादा टैब की समस्या भी हल हो जाएगी. पहले से रेंडर किए गए पेज, ब्रॉडकास्ट मैसेज सुन सकते हैं. हालांकि, चालू होने तक वे अपने ब्रॉडकास्ट मैसेज नहीं भेज सकते.
इसके अलावा, पहले से रेंडर किए गए पेजों को सर्वर का इस्तेमाल करके अपडेट किया जा सकता है. इसके लिए, समय-समय पर fetch() या WebSocket कनेक्शन का इस्तेमाल किया जा सकता है. हालांकि, अपडेट में देरी हो सकती है.
पेज को पहले से रेंडर करने के अनुमान को रद्द करना या रीफ़्रेश करना
हमारा सुझाव है कि पहले से रेंडर किए गए पेजों को अपडेट करें. इससे, उपयोगकर्ताओं को भ्रम से बचाने के साथ-साथ, पहले से रेंडर किए गए पेजों का इस्तेमाल जारी रखा जा सकता है. अगर ऐसा नहीं किया जा सकता, तो अनुमान रद्द किए जा सकते हैं.
अगर साइटों को उन पेजों को पहले से रेंडर करना है जिन पर जाने की संभावना ज़्यादा है, तो इसका इस्तेमाल Chrome की सीमाओं के अंदर रहने के लिए भी किया जा सकता है.
अनुमान लगाने की सुविधा को रद्द करने के लिए, आपको पेज से अनुमान लगाने के नियम हटाने होंगे. इसके अलावा, अगर अनुमान लगाने के लिए क्लास या मैच करने की अन्य शर्तों का इस्तेमाल किया जा रहा है, तो उन्हें भी हटाएं. इसके अलावा, अगर अनुमानित पेज को पता चलता है कि वह अब मौजूद नहीं है, तो वह window.close() को कॉल कर सकता है. हालांकि, अगर पेज इसकी पहचान कर लेता है, तो उसे अप-टू-डेट करने के लिए उसकी स्थिति अपडेट करना बेहतर विकल्प होगा.
इन नियमों (या मैच करने की शर्तों) को फिर से डाला जा सकता है, ताकि पेजों को फिर से प्री-रेंडर किया जा सके. हालांकि, आम तौर पर किसी मौजूदा पेज को अप-टू-डेट रखना बेहतर विकल्प होता है, क्योंकि इससे कम खर्च होता है. अनुमान लगाने से जुड़े नियम हटाने के बाद, नए माइक्रोटास्क में या उसके बाद, एलिमेंट को फिर से शामिल करना ज़रूरी है. इससे ब्राउज़र को हटाए गए एलिमेंट की जानकारी मिलती है और अनुमान रद्द हो जाते हैं. नीचे दिए गए उदाहरण में, अनुमान लगाने के सभी नियमों की स्क्रिप्ट को मिटाने और हटाने का एक तरीका बताया गया है:
async function refreshSpeculations() {
const speculationScripts = document.querySelectorAll('script[type="speculationrules"]');
for (const speculationScript of speculationScripts) {
// Get the current rules as JSON text
const ruleSet = speculationScript.textContent;
// Remove the existing script to reset prerendering
speculationScript.remove();
// Await for a microtask before re-inserting.
await Promise.resolve();
// Reinsert rule in a new speculation rules script
const newScript = document.createElement('script');
newScript.type = 'speculationrules';
newScript.textContent = ruleSet;
console.log(newScript);
// Append the new script back to the document
document.body.appendChild(newScript);
}
}
नियमों को हटाने पर, मौजूदा प्रीटेंडर (या प्रीफ़ेच) रद्द हो जाएंगे. हालांकि, नियमों को फिर से डालने पर, सिर्फ़ तुरंत लागू होने वाले या जल्दी लागू होने वाले नियमों का अनुमान लगाया जाएगा. इनमें, तुरंत लागू होने वाले नियमों का इस्तेमाल करने वाले यूआरएल की सूची के नियम भी शामिल हैं. हालांकि, मॉडरेट या कंज़र्वेटिव अनुमान हटा दिए जाएंगे. हालांकि, जब तक लिंक पर फिर से इंटरैक्ट नहीं किया जाता, तब तक ये अपने-आप फिर से ट्रिगर नहीं होंगे.
रीफ़्रेश करने का यह विकल्प, JavaScript से डाले गए नियमों तक ही सीमित नहीं है. एचटीएमएल में शामिल स्टैटिक नियमों को भी इसी तरह हटाया या बदला जा सकता है, क्योंकि यह डीओएम में होने वाला एक स्टैंडर्ड बदलाव है. एचटीटीपी के अनुमान से जुड़े नियमों को हटाया नहीं जा सकता. हालांकि, मैच करने की शर्तों (उदाहरण के लिए, prerender क्लास) को हटाया जा सकता है और JavaScript की मदद से उन्हें फिर से जोड़ा जा सकता है.
Chrome, Clear-Site-Header की सुविधा भी जोड़ने पर काम कर रहा है. इससे, सर्वर के जवाबों को प्री-रेंडरिंग रद्द करने की अनुमति मिलती है. उदाहरण के लिए, जब बास्केट अपडेट करने का अनुरोध किया जाता है.
असर का आकलन करना
अनुमान लगाने से जुड़े नियम लागू करने के बाद, आपको सफलता का आकलन करना चाहिए. सिर्फ़ यह नहीं मानना चाहिए कि यह अपने-आप तेज़ी से काम करेगा. जैसा कि पहले बताया गया है, अगर क्लाइंट या सर्वर पर ज़्यादा काम किया जाता है, तो ज़्यादा अनुमान लगाने की वजह से परफ़ॉर्मेंस में गिरावट आ सकती है.
एक से ज़्यादा चरणों (प्रीफ़ेच, कम जोखिम वाले प्री-रेंडर, और फिर जल्दी प्री-रेंडर) में लागू करते समय, आपको हर चरण को मेज़र करना चाहिए.
सफलता का आकलन कैसे करें
अनुमान लगाने के नियमों से, एलसीपी जैसी मुख्य परफ़ॉर्मेंस मेट्रिक पर अच्छा असर पड़ना चाहिए. साथ ही, हो सकता है कि सीएलएस और आईएनपी पर भी इसका असर पड़े. हालांकि, हो सकता है कि साइट-लेवल की सभी मेट्रिक में यह असर साफ़ तौर पर न दिखे. ऐसा इसलिए हो सकता है, क्योंकि साइटें मुख्य रूप से दूसरे तरह के नेविगेशन (उदाहरण के लिए, लैंडिंग पेज) से बनी हों या एक ही ऑरिजिन वाले नेविगेशन पहले से ही इतने तेज़ हों कि उनमें काफ़ी सुधार करने के बावजूद, Chrome के लिए उपयोगकर्ता अनुभव की रिपोर्ट (CrUX) में बताई गई 75वें पर्सेंटाइल मेट्रिक पर असर न पड़े.
CrUX में पेज नेविगेशन टाइप का इस्तेमाल करके, यह देखा जा सकता है कि नेविगेशन का कितना प्रतिशत navigate_cache या prerender है. साथ ही, यह भी देखा जा सकता है कि समय के साथ यह प्रतिशत बढ़ रहा है या नहीं. हालांकि, ज़्यादा जानकारी वाले विश्लेषण के लिए, आपको अपने डेटा को अनुमानित नेविगेशन में सेगमेंट करने के लिए, रीयल यूज़र मॉनिटरिंग का इस्तेमाल करना पड़ सकता है. इससे यह पता चलता है कि वे अन्य नेविगेशन की तुलना में कितने तेज़ हैं.
इस्तेमाल और बेकार होने वाले ईमेल को मेज़र करने का तरीका
यह भी मेज़र करना ज़रूरी है कि क्या सही पेजों पर अनुमान लगाया जा रहा है. इससे, अनुरोधों को बेकार होने से बचाने के साथ-साथ यह भी पक्का किया जाता है कि इस एपीआई का फ़ायदा पाने के लिए, सबसे अच्छे पेजों को टारगेट किया जा रहा है.
माफ़ करें, अनुमान लगाने की प्रोसेस शुरू करने वाले पेज को, अनुमान लगाने की कोशिशों की स्थिति सीधे तौर पर नहीं दिखती. इसके अलावा, यह नहीं माना जा सकता कि कोशिशें ट्रिगर हुई हैं, क्योंकि ब्राउज़र कुछ मामलों में अनुमान लगाने से रोक सकता है. इसलिए, इन्हें पेज पर ही मेज़र किया जाना चाहिए. इसके लिए, दो एपीआई की जांच भी ज़रूरी है, ताकि यह पता लगाया जा सके कि पेज पर अनुमान लगाया जा रहा है या पहले से अनुमान लगाया जा चुका है:
if (document.prerendering) {
console.log("Page is prerendering");
} else if (performance.getEntriesByType("navigation")[0]?.activationStart > 0) {
console.log("Page has already prerendered");
} else {
console.log("This page load was not using prerendering");
}
इसके बाद, यह पेज बैकएंड सर्वर पर अनुमान लगाने की कोशिश को लॉग कर सकता है.
Analytics से जुड़ी एक समस्या यह है कि Google Analytics जैसे कुछ प्रोवाइडर, पेज के पहले से रेंडर होने की जानकारी रखते हैं. साथ ही, पेज के ऐक्टिव होने तक Analytics कॉल को अनदेखा करते हैं. यहां तक कि अलग-अलग इवेंट कॉल को भी अनदेखा किया जाता है. इसलिए, Google Analytics के उपयोगकर्ताओं को सर्वर साइड लॉगिंग के दूसरे विकल्प का इस्तेमाल करना होगा.
क्लाइंट-साइड पर भी ऐसा किया जा सकता है. इसके तहत, पहले से रेंडर किया गया हर पेज, शेयर किए गए स्टोरेज में पहले से रेंडर किए गए पेज को लॉग करता है और कॉल करने वाला पेज इसे पढ़ता है. localStorage सबसे अच्छा काम करता है, क्योंकि इसे किसी पेज से बाहर निकलने पर पढ़ा जा सकता है. ध्यान दें कि sessionStorage का इस्तेमाल नहीं किया जा सकता, क्योंकि इसमें पहले से रेंडर किए गए पेजों के लिए खास तरीके से हैंडल करने की सुविधा है. हालांकि, ध्यान रखें कि localStorage ट्रांज़ैक्शन के लिहाज़ से सुरक्षित नहीं है. साथ ही, अगर कई पेजों को पहले से रेंडर किया गया है, तो हो सकता है कि उसी समय दूसरे पेज भी इसे अपडेट कर रहे हों. इस डेमो में, यूनीक हैश और अलग-अलग एंट्री का इस्तेमाल किया गया है, ताकि इस तरह की समस्याओं से बचा जा सके.
नतीजा
अनुमान के नियमों से, आपके पेज की परफ़ॉर्मेंस में काफ़ी बढ़ोतरी हो सकती है. इस गाइड में, इस एपीआई को लागू करते समय ध्यान रखने वाली बातों के बारे में बताया गया है. इससे, किसी भी संभावित समस्या से बचा जा सकता है और एपीआई का ज़्यादा से ज़्यादा फ़ायदा भी लिया जा सकता है.
लागू करने से पहले प्लान बनाने से, दोबारा काम करने से बचा जा सकता है. खास तौर पर, ज़्यादा जटिल साइटों के लिए, कई चरणों में रोल आउट किया जाना चाहिए. सबसे पहले, प्रीफ़ेच से शुरू करके, कम जोखिम वाले प्री-रेंडर और फिर जल्दी प्री-रेंडर पर जाना चाहिए. आखिर में, सुधारों को मेज़र करना ज़रूरी है. साथ ही, यह भी देखना ज़रूरी है कि API का इस्तेमाल किस तरह किया जा रहा है और कितनी डेटा खर्च हो रही है. इससे यह पक्का किया जा सकता है कि API का बेहतर तरीके से इस्तेमाल किया जा रहा है.