पब्लिश करने की तारीख: 7 मार्च, 2025, पिछली बार अपडेट करने की तारीख: 23 अक्टूबर, 2025
Speculation Rules API की मदद से, उपयोगकर्ता परफ़ॉर्मेंस को बेहतर बना सकते हैं. इसके लिए, वे आने वाले समय में होने वाले पेज नेविगेशन को प्रीफ़ेच या प्रीरेंडरिंग कर सकते हैं, ताकि पेज नेविगेशन को तेज़ी से या तुरंत किया जा सके.
एपीआई को खास तौर पर आसानी से लागू करने के लिए डिज़ाइन किया गया है. हालांकि, कुछ ऐसी बातें हैं जिन पर खास तौर पर जटिल साइटों को इसका इस्तेमाल करने से पहले ध्यान देना चाहिए. इस गाइड से, साइट के मालिकों को इन बातों को समझने में मदद मिलती है.
प्लानिंग
स्पेकुलेशन के नियमों को लागू करने से पहले, यह तय करना ज़रूरी है कि एपीआई को कैसे लागू किया जाए. ऐसा इसलिए, क्योंकि इसके लिए कुछ विकल्प उपलब्ध हैं. साथ ही, स्पेकुलेशन की लागत के बारे में भी पता होना चाहिए. इससे आपको यह तय करने में मदद मिलेगी कि किन पेजों पर स्पेकुलेशन करना है.
तय करना कि अनुमान लगाने के नियमों को कैसे लागू करना है
आपको सबसे पहले यह तय करना होगा कि अपनी साइट पर स्पेकुलेशन के नियम कैसे लागू किए जाएं. इसके लिए, आपके पास कई तरीके हैं:
- सीधे तौर पर पेज के एचटीएमएल में
- JavaScript का इस्तेमाल करना
- एचटीटीपी हेडर का इस्तेमाल करना
आखिरकार, हर तरीके का असर एक जैसा होता है. हालांकि, लागू करने में आसानी और फ़्लेक्सिबिलिटी के मामले में फ़ायदे मिल सकते हैं.
साइटों को वह विकल्प चुनना चाहिए जो उनके लिए सबसे सही हो. अगर ज़रूरी हो, तो वे इन विकल्पों के कॉम्बिनेशन का भी इस्तेमाल कर सकती हैं. इसके अलावा, इन्हें किसी प्लगइन (जैसे, WordPress के लिए Speculative Loading plugin) या लाइब्रेरी या प्लैटफ़ॉर्म का इस्तेमाल करके लागू किया जा सकता है. ये आपके लिए विकल्प चुन सकते हैं. हालांकि, उपलब्ध विकल्पों के बारे में जानना अब भी ज़रूरी है.
पेज के एचटीएमएल में सीधे तौर पर अनुमान लगाने के नियम शामिल करना
अनुमान लगाने से जुड़े नियमों को सीधे तौर पर पेज पर लागू किया जा सकता है. इसके लिए, पेज के एचटीएमएल में <script type="speculationrules"> एलिमेंट शामिल करें. इसे टेंप्लेट का इस्तेमाल करके स्टैटिक साइटों के लिए, बिल्ड टाइम पर जोड़ा जा सकता है. इसके अलावा, जब पेज का अनुरोध किया जाता है, तब सर्वर इसे रन टाइम पर जोड़ सकता है. इन्हें एज वर्कर, एचटीएमएल में भी इंजेक्ट कर सकते हैं. हालांकि, इसके लिए एचटीटीपी हेडर का तरीका ज़्यादा आसान है. इस बारे में इस गाइड में बाद में बताया गया है.
इससे पूरी साइट पर स्टैटिक नियम शामिल किए जा सकते हैं. हालांकि, दस्तावेज़ के नियम अब भी डाइनैमिक हो सकते हैं. इसके लिए, आपको उन यूआरएल को चुनने की अनुमति मिलती है जिन्हें पेज से रेंडर करना है. इसके लिए, सीएसएस क्लास से ट्रिगर होने वाले नियमों का इस्तेमाल किया जाता है:
<script type="speculationrules">
{
"prerender": [{
"where": { "selector_matches": ".prerender" }
}],
"prefetch": [{
"where": { "selector_matches": ".prefetch" }
}]
}
</script>
पिछली स्क्रिप्ट, prerender क्लास वाले लिंक को पहले से रेंडर करेगी. इसी तरह, prefetch क्लास वाले लिंक को पहले से फ़ेच करेगी. इससे डेवलपर, अटकलें लगाने की सुविधा को ट्रिगर करने के लिए, इन क्लास को एचटीएमएल में शामिल कर सकते हैं.
किसी पेज के शुरुआती एचटीएमएल में इन क्लास के लिंक शामिल करने के अलावा, अगर आपका ऐप्लिकेशन इन क्लास को डाइनैमिक तरीके से जोड़ता है, तो लिंक का अनुमान भी लगाया जाएगा. इससे आपका ऐप्लिकेशन, ज़रूरत के मुताबिक अनुमानों को ट्रिगर (और हटा) सकता है. यह, अनुमान लगाने के ज़्यादा खास नियम बनाने या हटाने से ज़्यादा आसान हो सकता है. अगर आपको साइट के ज़्यादातर पेजों के लिए एक बुनियादी नियम और पेज के हिसाब से नियम तय करने हैं, तो हर पेज के लिए एक से ज़्यादा अनुमान लगाने वाले नियम शामिल किए जा सकते हैं.
इसके अलावा, अगर आपको ज़्यादा सटीक अनुमान लगाने वाले नियमों का इस्तेमाल करना है, तो पेज के हिसाब से या टेंप्लेट के हिसाब से तय किए गए नियमों का इस्तेमाल किया जा सकता है. इससे कुछ पेजों या पेज टाइप के लिए अलग-अलग नियमों का इस्तेमाल किया जा सकता है.
आखिर में, सर्वर-साइड पर रेंडर किए गए पेजों में, सर्वर के लिए उपलब्ध जानकारी के आधार पर ज़्यादा डाइनैमिक नियम भी हो सकते हैं. जैसे, उस पेज के लिए आंकड़ों की जानकारी या कुछ पेजों के लिए उपयोगकर्ता के सामान्य सफ़र.
JavaScript का इस्तेमाल करके अनुमान लगाने के नियम जोड़ना
पेज पर मौजूद स्क्रिप्ट में नियमों को शामिल करने के बजाय, JavaScript का इस्तेमाल करके उन्हें इंजेक्ट किया जा सकता है. इससे पेज टेंप्लेट को कम बार अपडेट करना पड़ सकता है. उदाहरण के लिए, टैग मैनेजर के ज़रिए नियमों को इंजेक्ट करना, स्पेकुलेशन नियमों को रोल आउट करने का एक आसान तरीका हो सकता है. इससे, ज़रूरत पड़ने पर उन्हें तुरंत बंद भी किया जा सकता है.
इस विकल्प की मदद से, क्लाइंट-साइड पर डाइनैमिक नियमों को भी लागू किया जा सकता है. ये नियम, उपयोगकर्ता के पेज से इंटरैक्ट करने के तरीके पर आधारित होते हैं. उदाहरण के लिए, अगर उपयोगकर्ता बास्केट में कोई आइटम जोड़ता है, तो चेकआउट पेज को पहले से रेंडर किया जा सकता है. इसके अलावा, इसका इस्तेमाल कुछ शर्तों के आधार पर अनुमान लगाने के लिए भी किया जा सकता है. एपीआई में एक ईगरनेस सेटिंग शामिल होती है. इससे इंटरैक्शन पर आधारित बुनियादी नियमों को लागू किया जा सकता है. हालांकि, JavaScript की मदद से डेवलपर, यह तय करने के लिए अपने लॉजिक का इस्तेमाल कर सकते हैं कि अनुमान कब और किन पेजों पर लगाना है.
जैसा कि पहले बताया गया है, नए नियम डालने का एक और तरीका यह है कि पेज पर दस्तावेज़ का मूल नियम हो. साथ ही, JavaScript, दस्तावेज़ के नियमों को ट्रिगर करे. इसके लिए, लिंक में सही क्लास जोड़ें, ताकि वे नियम से मेल खाएं.
एचटीटीपी हेडर का इस्तेमाल करके अनुमान लगाने के नियम जोड़ना
डेवलपर के पास नियमों को एचटीटीपी हेडर का इस्तेमाल करके शामिल करने का विकल्प भी होता है:
Speculation-Rules: "/speculationrules.json"
नियमों के संसाधन (इस उदाहरण में /speculationrules.json) को डिलीवर करने और इस्तेमाल करने के लिए, कुछ अन्य ज़रूरी शर्तें हैं.
इस विकल्प की मदद से, सीडीएन आसानी से कॉन्टेंट को डिप्लॉय कर सकते हैं. इसके लिए, उन्हें दस्तावेज़ के कॉन्टेंट में बदलाव करने की ज़रूरत नहीं होती. इसका मतलब है कि JavaScript का इस्तेमाल करके, अनुमान लगाने से जुड़े नियमों में डाइनैमिक तरीके से बदलाव नहीं किया जा सकता. हालांकि, सीएसएस सिलेक्टर ट्रिगर वाले दस्तावेज़ के नियम अब भी डाइनैमिक बदलावों की अनुमति दे सकते हैं. उदाहरण के लिए, किसी लिंक से prerender क्लास हटाकर.
JavaScript के विकल्प की तरह ही, एचटीटीपी हेडर के साथ स्पेकुलेशन नियमों को लागू करने से, उन्हें साइट के कॉन्टेंट से अलग लागू किया जा सकता है. इससे पूरी साइट को फिर से बनाए बिना, नियमों को जोड़ना और हटाना आसान हो जाता है.
लागत पर पड़ने वाले असर के बारे में जानें
स्पेकुलेशन के नियमों को लागू करने से पहले, यह जान लें कि इस एपीआई का इस्तेमाल करने पर, आपके उपयोगकर्ताओं और आपकी साइट पर क्या असर पड़ेगा. लागत में बैंडविड्थ (जिससे उपयोगकर्ताओं और साइटों, दोनों को नुकसान होता है!) और प्रोसेसिंग की लागत (क्लाइंट और सर्वर, दोनों साइड पर) शामिल होती है.
उपयोगकर्ताओं के लिए कीमत तय करना
अनुमान के हिसाब से यूआरएल लोड होने का मतलब है कि यह अनुमान लगाना कि उपयोगकर्ता अगले पेज पर कहां जा सकता है. हालांकि, अगर ऐसा नहीं होता है, तो हो सकता है कि आपने संसाधनों का सही इस्तेमाल न किया हो. इसलिए, आपको उपयोगकर्ताओं पर पड़ने वाले असर के बारे में पता होना चाहिए. खास तौर पर:
- आने वाले समय में नेविगेशन के लिए, ज़्यादा बैंडविड्थ का इस्तेमाल किया जाता है. खास तौर पर, मोबाइल पर जहां बैंडविड्थ सीमित हो सकती है.
- प्रीरेंडरिंग का इस्तेमाल करने पर, उन पेजों को रेंडर करने के लिए प्रोसेसिंग की अतिरिक्त लागत.
पूरी तरह से सटीक अनुमानों के साथ, कोई अतिरिक्त लागत नहीं लगती है. ऐसा इसलिए, क्योंकि खरीदार अगले चरण में उन पेजों पर जाएंगे. हालांकि, लागतों में सिर्फ़ इतना अंतर होगा कि उन्हें पहले ही शामिल कर लिया जाएगा. हालांकि, पूरी तरह से सटीक अनुमान लगाना मुमकिन नहीं है. साथ ही, अनुमान लगाने की रणनीति जितनी ज़्यादा अनुमानित होगी, उतना ही ज़्यादा बजट बर्बाद होने का जोखिम होगा.
Chrome ने इस समस्या पर काफ़ी सोच-विचार किया है. साथ ही, इस एपीआई में कई ऐसी सुविधाएं शामिल हैं जिनसे इसकी लागत आपकी सोच से काफ़ी कम हो जाती है. खास तौर पर, एचटीटीपी कैश मेमोरी का दोबारा इस्तेमाल करके और क्रॉस-ऑरिजिन iframe लोड न करके, एक ही साइट पर नेविगेशन को पहले से रेंडर करने की लागत अक्सर, कैश की गई किसी भी संसाधन के बिना पूरे पेज की तुलना में काफ़ी कम होती है. इससे स्पेकुलेटिव लोड, अनुमान से कम लागत वाले हो जाते हैं.
हालांकि, इन सुरक्षा उपायों के बावजूद, साइटों को यह ध्यान से सोचना चाहिए कि किन पेजों पर अनुमान लगाना है. साथ ही, इस तरह के अनुमानों से उपयोगकर्ता पर पड़ने वाले असर के बारे में भी सोचना चाहिए. स्पेकुलेटिव लोडिंग के लिए, ऐसे कॉन्टेंट को चुना जाना चाहिए जिसके बारे में अनुमान लगाना आसान हो. जैसे, आंकड़ों या उपयोगकर्ता के सामान्य व्यवहार के आधार पर अनुमान लगाया जा सकता है. साथ ही, ऐसे कॉन्टेंट को चुना जाना चाहिए जिसे लोड करने में कम समय लगता हो. जैसे, कम रिच पेज.
यह भी तय किया जा सकता है कि कौनसी JavaScript को चालू होने तक डिले किया जाना चाहिए. यह सुविधा, ज़रूरत पड़ने पर ही कॉन्टेंट को लेज़ी लोड करने की सुविधा की तरह काम करती है. इससे प्रीरेंडरिंग की लागत कम हो सकती है. साथ ही, उपयोगकर्ताओं को बेहतर अनुभव मिल सकता है. सस्ते अनुमानों की वजह से, आपको बार-बार या उत्सुकता से अनुमान लगाने में आसानी हो सकती है.
अगर ऐसा नहीं किया जा सकता, तो मॉडरेट या कंज़र्वेटिव, ईगरनेस के नियमों का इस्तेमाल करके, कम आक्रामक रणनीति का इस्तेमाल करने का सुझाव दिया जाता है. इसके अलावा, प्रीफ़ेच का इस्तेमाल किया जा सकता है. जब कॉन्फ़िडेंस कम होता है, तो प्रीफ़ेच की लागत, प्रीरेंडरिंग की तुलना में काफ़ी कम होती है. इसके बाद, अगर कॉन्फ़िडेंस बढ़ता है, तो इसे पूरी तरह से प्रीरेंडर में अपग्रेड किया जा सकता है. उदाहरण के लिए, जब किसी लिंक पर कर्सर घुमाया जाता है या उस पर क्लिक किया जाता है.
बैकएंड पर ज़्यादा लोड होने की वजह से
साइट के मालिकों को, उपयोगकर्ता से लिए जाने वाले अतिरिक्त शुल्क के साथ-साथ, अपने बुनियादी ढांचे की लागत पर भी ध्यान देना चाहिए. अगर हर पेज पर दो, तीन या इससे ज़्यादा पेज लोड होते हैं, तो इस एपीआई का इस्तेमाल करने से बैकएंड की लागत बढ़ सकती है.
यह पक्का करने से कि आपके पेज और संसाधन कैश मेमोरी में सेव किए जा सकते हैं, ऑरिजिन लोड काफ़ी कम हो जाता है. इसलिए, कुल जोखिम भी कम हो जाता है. सीडीएन के साथ इस्तेमाल करने पर, आपके ओरिजन सर्वर पर कम से कम अतिरिक्त लोड पड़ना चाहिए. हालांकि, सीडीएन की लागत में होने वाली किसी भी बढ़ोतरी पर ध्यान दें.
सर्वर या सीडीएन का इस्तेमाल, अनुमानित नतीजों को कंट्रोल करने के लिए भी किया जा सकता है. इन नतीजों की पहचान sec-purpose एचटीटीपी हेडर से होती है. उदाहरण के लिए, Cloudflare का Speed Brain प्रॉडक्ट, सिर्फ़ उन अनुमानों की अनुमति देता है जो सीडीएन के एज सर्वर पर पहले से कैश मेमोरी में सेव हैं. साथ ही, यह अनुरोधों को वापस ओरिजन सर्वर पर नहीं भेजेगा.
हालांकि, स्पेकुलेटिव लोड का इस्तेमाल आम तौर पर एक ही ऑरिजिन वाले पेज को लोड करने के लिए किया जाता है. इसलिए, उपयोगकर्ताओं के ब्राउज़र की कैश मेमोरी में पहले से ही शेयर किए गए रिसॉर्स मौजूद होंगे. ऐसा तब होगा, जब वे रिसॉर्स कैश मेमोरी में सेव किए जा सकते हों. इसलिए, स्पेकुलेशन आम तौर पर पूरे पेज को लोड करने जितना महंगा नहीं होता.
बहुत ज़्यादा या बहुत कम अनुमान लगाने के बीच संतुलन बनाए रखना
Speculation Rules API का ज़्यादा से ज़्यादा फ़ायदा पाने के लिए, यह ज़रूरी है कि आप अनुमान लगाने के लिए सही रणनीति अपनाएं. अनुमान लगाने के लिए दो तरह की रणनीतियां अपनाई जा सकती हैं: पहली, बहुत ज़्यादा अनुमान लगाना. इसका मतलब है कि जब बिना किसी वजह के लागत चुकाई जाती है और अनुमान का इस्तेमाल नहीं किया जाता. दूसरी, बहुत कम अनुमान लगाना. इसका मतलब है कि अनुमान बहुत कम लगाया जाता है या अनुमान लगाने में बहुत देर हो जाती है, जिससे कम फ़ायदा मिलता है.
जहां लागत कम होती है (उदाहरण के लिए, सीडीएन एज नोड पर कैश किए गए छोटे, स्टैटिक रूप से जनरेट किए गए पेज), वहां अनुमान लगाने के लिए ज़्यादा असरदार तरीके अपनाए जा सकते हैं.
हालांकि, बड़े और ज़्यादा कॉन्टेंट वाले पेजों के लिए ज़्यादा सावधानी बरतनी चाहिए. ऐसा इसलिए, क्योंकि शायद इन्हें सीडीएन एज पर कैश मेमोरी में सेव नहीं किया जा सकता. इसी तरह, ज़्यादा संसाधनों का इस्तेमाल करने वाले पेजों से, नेटवर्क बैंडविथ या प्रोसेसिंग पावर का इस्तेमाल किया जा सकता है. इससे मौजूदा पेज पर बुरा असर पड़ सकता है. एपीआई का मकसद परफ़ॉर्मेंस को बेहतर बनाना है. इसलिए, परफ़ॉर्मेंस में गिरावट आना, हमारी उम्मीद के मुताबिक नहीं है! इसलिए, ज़्यादा से ज़्यादा एक या दो पेजों को प्रीरेंडर करने की सलाह दी जाती है. यह भी ध्यान दें कि 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>
अगले नेविगेशन का सटीक अनुमान लगाने के लिए, ट्रैफ़िक का विश्लेषण करना ज़रूरी हो सकता है. आपकी साइट पर ग्राहकों के सामान्य सफ़र को समझने से, स्पेकुलेटिव लोडिंग के लिए अच्छे कैंडिडेट की पहचान करने में भी मदद मिल सकती है.
ज़्यादा eager या immediate प्रीरेंडरिंग पर स्विच करने से, Analytics, विज्ञापनों, और JavaScript के बारे में ज़्यादा बातों पर ध्यान देना पड़ सकता है. साथ ही, प्रीरेंडर किए गए पेज को अप-टू-डेट रखना पड़ सकता है. इसके अलावा, स्थिति में बदलावों के बारे में अनुमानों को रद्द या रीफ़्रेश करना भी पड़ सकता है.
Analytics, विज्ञापन, और JavaScript
प्रीरेंडरिंग का इस्तेमाल करते समय, ज़्यादा जटिल साइटों को आंकड़ों पर पड़ने वाले असर पर भी ध्यान देना चाहिए. आम तौर पर, आपको पेज (या विज्ञापन) व्यू को तब तक लॉग नहीं करना चाहिए, जब तक पेज का अनुमान लगाया जा रहा हो. ऐसा सिर्फ़ तब करना चाहिए, जब अनुमान लगाने की सुविधा चालू हो.
आंकड़े इकट्ठा करने की सेवाएं देने वाली कुछ कंपनियां (जैसे, Google Analytics) और विज्ञापन दिखाने की सेवाएं देने वाली कंपनियां (जैसे, Google पब्लिशर टैग), पहले से ही स्पेकुलेशन नियमों का पालन करती हैं. ये कंपनियां, पेज के चालू होने तक व्यू लॉग नहीं करती हैं. हालांकि, आपने जिन अन्य प्रोवाइडर या कस्टम ऐनलिटिक्स को लागू किया है उन पर ज़्यादा ध्यान देने की ज़रूरत पड़ सकती है. हम ऐसी कंपनियों की सूची बनाए रखते हैं जो अटकलों से जुड़े नियमों के बारे में जानती हैं.
JavaScript में चेक जोड़े जा सकते हैं, ताकि कोड के कुछ हिस्सों को पेज चालू होने या दिखने तक न चलाया जा सके. साथ ही, पूरे <script> एलिमेंट को ऐसे चेक में रैप किया जा सकता है. जिन पेजों पर टैग मैनेजर का इस्तेमाल करके ऐसी स्क्रिप्ट डाली जाती हैं, उन सभी को एक साथ ठीक किया जा सकता है. इसके लिए, टैग मैनेजर स्क्रिप्ट को कुछ समय के लिए रोक दें.
इसी तरह, सहमति मैनेज करने वाले प्लैटफ़ॉर्म, तीसरे पक्ष की स्क्रिप्ट को तब तक डिले करने का विकल्प देते हैं, जब तक उन्हें चालू नहीं किया जाता. Google, सहमति मैनेज करने वाले अलग-अलग प्लैटफ़ॉर्म के साथ मिलकर काम कर रहा है, ताकि उन्हें प्रीरेंडरिंग के बारे में जानकारी दी जा सके. हमें उन लोगों की मदद करने में खुशी होगी जो ऐसा करना चाहते हैं. PubTech ऐसी ही एक कंपनी है जो डेवलपर को प्रीरेंडरिंग के दौरान, अपनी JavaScript को चलाने या ब्लॉक करने का विकल्प देती है.
ऐप्लिकेशन कोड के लिए, इसी तरह से कोड के एक्ज़ीक्यूशन में बदलाव किया जा सकता है, ताकि कोड तब तक एक्ज़ीक्यूट न हो, जब तक उसे चालू न किया जाए. ऐसा खास तौर पर तब किया जाता है, जब पेज को रेंडर करने के लिए JavaScript कोड की ज़रूरत नहीं होती. यह एक तेज़ और सुरक्षित विकल्प है. हालांकि, इसका मतलब यह है कि ऐक्टिव होने पर, पूरा कोड एक साथ चलेगा. इससे ऐक्टिवेशन के समय बहुत काम करना पड़ सकता है. इससे आईएनपी पर असर पड़ सकता है. ऐसा इसलिए होता है, क्योंकि पेज पूरी तरह से लोड हो सकता है और इंटरैक्ट करने के लिए तैयार हो सकता है.
इसके अलावा, अगर कोई कॉन्टेंट 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-Data एचटीटीपी हेडर भी जोड़ा है, ताकि सर्वर के जवाब, प्रीफ़ेच या प्रीरेंडर को रद्द कर सकें. उदाहरण के लिए, जब अपडेट बास्केट का अनुरोध किया जाता है.
असर का आकलन करना
अनुमान लगाने से जुड़े नियमों को लागू करने के बाद, आपको यह मेज़र करना चाहिए कि इससे पेज लोड होने में कितना समय लग रहा है. यह न मान लें कि इससे पेज लोड होने में अपने-आप कम समय लगेगा. जैसा कि पहले बताया गया है, क्लाइंट या सर्वर पर ज़्यादा लोड होने पर, अनुमान लगाने की सुविधा की वजह से परफ़ॉर्मेंस में गिरावट आ सकती है.
अगर एक से ज़्यादा चरणों (प्रीफ़ेच, कम जोखिम वाले प्रीरेंडर, और फिर शुरुआती प्रीरेंडर) के साथ लागू किया जा रहा है, तो आपको हर चरण के साथ मेज़र करना चाहिए.
सफलता का आकलन कैसे करें
अनुमान लगाने के नियमों का, एलसीपी जैसी मुख्य परफ़ॉर्मेंस मेट्रिक पर अच्छा असर पड़ना चाहिए. साथ ही, हो सकता है कि इनका असर सीएलएस और आईएनपी पर भी पड़े. हालांकि, ऐसा हो सकता है कि ये बदलाव, साइट-लेवल की मेट्रिक में साफ़ तौर पर न दिखें. ऐसा इसलिए हो सकता है, क्योंकि साइटें मुख्य रूप से अन्य तरह के नेविगेशन (उदाहरण के लिए, लैंडिंग पेज) से बनी होती हैं. इसके अलावा, ऐसा इसलिए भी हो सकता है, क्योंकि एक ही ऑरिजिन वाले नेविगेशन पहले से ही काफ़ी तेज़ होते हैं. इसलिए, उन्हें बेहतर बनाने से 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 लेन-देन के लिए सुरक्षित नहीं है. साथ ही, अगर कई पेजों को पहले से रेंडर किया जाता है, तो हो सकता है कि अन्य पेज भी इसे उसी समय अपडेट कर रहे हों. इस डेमो में, यूनीक हैश और अलग-अलग एंट्री का इस्तेमाल किया गया है, ताकि इससे जुड़ी समस्याओं से बचा जा सके.
नतीजा
अनुमान लगाने के नियमों की मदद से, आपके पेज की परफ़ॉर्मेंस में काफ़ी सुधार हो सकता है. इस गाइड में, इस एपीआई को लागू करते समय ध्यान रखने वाली बातों के बारे में सलाह दी गई है. इससे संभावित समस्याओं से बचा जा सकता है. साथ ही, एपीआई का ज़्यादा से ज़्यादा फ़ायदा पाया जा सकता है.
पहले से प्लान बनाने पर, आपको दोबारा काम नहीं करना पड़ेगा. खास तौर पर, ज़्यादा जटिल साइटों के लिए, इसे कई चरणों में लागू किया जाना चाहिए. इसकी शुरुआत प्रीफ़ेच से होनी चाहिए. इसके बाद, कम जोखिम वाले प्रीरेंडर और फिर अर्ली प्रीरेंडर पर जाना चाहिए. आखिर में, यह जानना ज़रूरी है कि इस एपीआई का इस्तेमाल करने से, आपके कारोबार में कितना सुधार हुआ. साथ ही, यह भी जानना ज़रूरी है कि इसका कितना इस्तेमाल हुआ और कितना डेटा बर्बाद हुआ, ताकि यह पक्का किया जा सके कि इस एपीआई का इस्तेमाल ऑप्टिमाइज़ किया जा रहा है.