ज़्यादा जटिल साइटों के लिए, अनुमान लगाने से जुड़े नियमों को लागू करने के बारे में गाइड

Barry Pollard

पब्लिश करने की तारीख: 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 लोड न करके, एक ही साइट पर नेविगेशन को पहले से रेंडर करने की लागत अक्सर, कैश की गई किसी भी संसाधन के बिना पूरे पेज की लागत से काफ़ी कम होती है. इससे स्पेकुलेटिव लोड, अनुमान से कम लागत वाले हो जाते हैं.

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

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

नतीजा

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

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