पब्लिश करने की तारीख: 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 ने इस समस्या पर काफ़ी सोच-विचार किया है. साथ ही, API में कई ऐसी सुविधाएं शामिल हैं जिनसे इसकी लागत आपकी सोच से काफ़ी कम हो जाती है. खास तौर पर, एचटीटीपी कैश मेमोरी का दोबारा इस्तेमाल करके और क्रॉस-ऑरिजिन 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 लेन-देन के लिए सुरक्षित नहीं है. साथ ही, अगर कई पेजों को पहले से रेंडर किया जाता है, तो हो सकता है कि अन्य पेज भी इसी समय इसे अपडेट कर रहे हों. इस डेमो में, यूनीक हैश और अलग-अलग एंट्री का इस्तेमाल किया गया है, ताकि इससे जुड़ी समस्याओं से बचा जा सके.
नतीजा
अनुमान लगाने के नियमों की मदद से, पेज की परफ़ॉर्मेंस को बेहतर बनाया जा सकता है. इस गाइड में, इस एपीआई को लागू करते समय ध्यान रखने वाली बातों के बारे में सलाह दी गई है. इससे आपको संभावित समस्याओं से बचने और एपीआई का ज़्यादा से ज़्यादा फ़ायदा पाने में मदद मिलेगी.
पहले से प्लान करके लागू करने से, दोबारा काम करने की ज़रूरत नहीं पड़ेगी. खास तौर पर, ज़्यादा जटिल साइटों के लिए, एक से ज़्यादा चरणों में रोल आउट करने की प्रोसेस को फ़ॉलो करना चाहिए. इसकी शुरुआत प्रीफ़ेच से होनी चाहिए. इसके बाद, कम जोखिम वाले प्रीरेंडर और फिर अर्ली प्रीरेंडर पर जाना चाहिए. आखिर में, यह जानना ज़रूरी है कि इस एपीआई का इस्तेमाल करने से, आपके कारोबार में कितना सुधार हुआ. साथ ही, यह भी जानना ज़रूरी है कि आपने इसका कितना इस्तेमाल किया और कितना डेटा बर्बाद हुआ. इससे यह पक्का किया जा सकेगा कि आपने इस एपीआई का इस्तेमाल सही तरीके से किया है.