Chrome टीम अनुमान लगाने से जुड़े नियम एपीआई के कुछ दिलचस्प अपडेट पर काम कर रही है. इनका इस्तेमाल करके, नेविगेशन की परफ़ॉर्मेंस को बेहतर बनाया जा सकता है. इसके लिए, आने वाले समय के नेविगेशन को प्रीफ़ेच या प्रीरेंडर किया जाता है. ये अतिरिक्त अपडेट अब Chrome 122 में उपलब्ध हैं. हालांकि, इसमें कुछ सुविधाएं पुराने वर्शन में भी उपलब्ध हैं.
इन बदलावों की वजह से, पेजों को प्रीफ़ेच और प्रीरेंडरिंग के लिए इस्तेमाल करना काफ़ी आसान हो जाता है. साथ ही, ये पेज कम बर्बाद होते हैं. हमें उम्मीद है कि ये बदलाव और भी लागू होंगे.
अतिरिक्त सुविधाएं
सबसे पहले, यह बताया गया है कि अनुमान से जुड़े नियमों के एपीआई में, हमने क्या नई चीज़ें जोड़ी हैं और उन्हें कैसे इस्तेमाल किया जा सकता है. इसके बाद, हम आपको एक डेमो दिखाएंगे, ताकि आप उन्हें काम करते हुए देख सकें.
दस्तावेज़ के नियम
पहले, अनुमान लगाने के नियम एपीआई, प्रीफ़ेच या प्रीरेंडर करने के लिए यूआरएल की सूची तय करके काम करता था:
<script type="speculationrules">
{
"prerender": [
{
"source": "list",
"urls": ["next.html", "next2.html"]
}
]
}
</script>
इसमें अनुमान लगाने के नियम सेमी-डाइनैमिक थे, क्योंकि अनुमान के नए नियम की स्क्रिप्ट जोड़ी जा सकती थीं. साथ ही, इन अनुमान को खारिज करने के लिए, पुरानी स्क्रिप्ट को हटा दिया जाता था. ध्यान दें कि अनुमान लगाने के मौजूदा नियमों की स्क्रिप्ट की urls सूची को अपडेट करने से, अनुमान लगाने के तरीके में कोई बदलाव नहीं होता. हालांकि, इसने अब भी साइट के लिए यूआरएल चुनने का विकल्प चुना है. यह विकल्प या तो पेज अनुरोध के समय सर्वर से भेजा जाता है या क्लाइंट-साइड JavaScript के ज़रिए डाइनैमिक तरीके से बनाया जाता है.
सूची के नियम आसान इस्तेमाल के मामलों (जहां अगला नेविगेशन, कुछ ज़रूरी मामलों से हो) या ज़्यादा बेहतर इस्तेमाल के मामलों के लिए विकल्प के तौर पर बना रहता है (जहां साइट का मालिक, अपने अनुभव के आधार पर यूआरएल की सूची डाइनैमिक तौर पर कैलकुलेट करता है और उसे पेज में डाला जाता है).
इसके विकल्प के तौर पर, हमें दस्तावेज़ के नियमों का इस्तेमाल करके, अपने-आप लिंक होने की सुविधा का नया विकल्प पेश करते हुए खुशी हो रही है. यह where शर्त के आधार पर, दस्तावेज़ से यूआरएल लेता है. इसके लिए, नीचे दिए गए लिंक का इस्तेमाल किया जा सकता है:
<script type="speculationrules">
{
"prerender": [{
"source": "document",
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout/*"}}
]
},
"eagerness": "moderate"
}]
}
</script>
सीएसएस सिलेक्टर का इस्तेमाल विकल्प के तौर पर भी किया जा सकता है. इसके अलावा, मौजूदा पेज में लिंक खोजने के लिए href मैच के साथ भी इनका इस्तेमाल किया जा सकता है:
<script type="speculationrules">
{
"prerender": [{
"source": "document",
"where": {
"and": [
{ "selector_matches": ".prerender" },
{ "not": {"selector_matches": ".do-not-prerender"}}
]
},
"eagerness": "moderate"
}]
}
</script>
इससे हर पेज के हिसाब से अलग-अलग नियम सेट करने के बजाय, पूरी साइट पर एक अनुमान लगाने के नियम का इस्तेमाल किया जा सकता है. इससे साइटों के लिए अनुमान लगाने के नियमों को लागू करना आसान हो जाता है.
बेशक, किसी पेज पर सभी लिंक को प्रीरेंडर करना वाकई काम का नहीं होगा. इसलिए, इस नई सुविधा के साथ हमने एक eagerness सेटिंग जोड़ी है.
उत्सुकता
किसी भी तरह के अनुमान के साथ, सटीक और बाज़ार को बाज़ार से हटाना और लीड टाइम के बीच फ़र्क़ होता है. पेज लोड होने पर सभी लिंक को पहले से रेंडर करने का मतलब है कि आप किसी उपयोगकर्ता के क्लिक किए जाने वाले लिंक को प्रीरेंडर कर देंगे (यह मानते हुए कि वे पेज पर एक ही साइट के लिंक पर क्लिक करते हैं) और जितना हो सके उतना लीड समय मिलेगा, लेकिन इससे बैंडविथ बहुत ज़्यादा बर्बाद हो सकता है.
दूसरी ओर, उपयोगकर्ता के किसी लिंक पर क्लिक करने के बाद ही उसे प्रीरेंडर करने से बर्बादी कम हो जाती है. हालांकि, इसमें काफ़ी कम समय लगता है. इसका मतलब है कि ब्राउज़र के उस पेज पर स्विच करने से पहले, प्रीरेंडरिंग पूरी होने की संभावना नहीं है.
eagerness सेटिंग की मदद से, यह तय किया जा सकता है कि अनुमान कब लागू किए जाएं. यह अनुमान लगाने के लिए कब किया जाता है कि किन यूआरएल पर अनुमान लगाना है. eagerness सेटिंग, list और document, दोनों के सोर्स नियमों के लिए उपलब्ध है. साथ ही, इसमें चार सेटिंग हैं, जिनके लिए Chrome के ये अनुभव हैं:
immediate: इसका इस्तेमाल जल्द से जल्द अनुमान लगाने के लिए किया जाता है. जैसे ही अनुमान लगाने के नियम देखे जाते हैं.eager: फ़िलहाल, यह सेटिंगimmediateकी सेटिंग की तरह ही काम करती है. हालांकि, आने वाले समय में हम इसेimmediateऔरmoderateके बीच रखने के बारे में सोच रहे हैं.moderate: इससे अनुमान लगाने के लिए, किसी लिंक पर 200 मिलीसेकंड तक कर्सर घुमाया जाता है. इसी तरह, अगर तय समय से पहलेpointerdownइवेंट हो रहा है, तो उस पर कर्सर घुमाया जा सकता है. इसके अलावा, मोबाइल परhoverभी इवेंट न होने पर उस पर कर्सर घुमाया जा सकता है.conservative: यह पॉइंटर या टच डाउन का अनुमान लगाता है.
list नियमों के लिए डिफ़ॉल्ट eagerness, immediate है. moderate और conservative विकल्पों का इस्तेमाल करके, list नियमों को सिर्फ़ ऐसे यूआरएल तक सीमित किया जा सकता है जिनसे उपयोगकर्ता किसी खास सूची से इंटरैक्ट करता है. हालांकि, कई मामलों में where शर्त वाले document नियम ज़्यादा सही हो सकते हैं.
document नियमों के लिए डिफ़ॉल्ट eagerness, conservative है. किसी दस्तावेज़ में कई यूआरएल हो सकते हैं. इसलिए, document नियमों के लिए immediate या eager का इस्तेमाल सावधानी से किया जाना चाहिए. इसके बाद, Chrome की सीमाएं सेक्शन भी देखें.
यह आपकी साइट पर निर्भर करता है कि आपको कौनसी eagerness सेटिंग का इस्तेमाल करना है. एक बहुत ही साधारण स्टैटिक साइट के लिए, ज़्यादा तेज़ी से अनुमान लगाने में कम लागत हो सकती है और यह उपयोगकर्ताओं के लिए फ़ायदेमंद हो सकता है. ज़्यादा कॉम्प्लेक्स आर्किटेक्चर और भारी पेज पेलोड वाली साइटें कचरे को कम करना चाहेंगी. इसके लिए तब तक कम अनुमान लगाएं, जब तक कि आपको उपयोगकर्ताओं से कचरे को कम करने की इच्छा के बारे में ज़्यादा सकारात्मक संकेत न मिल जाएं.
moderate विकल्प, बीच का विकल्प है. कई साइटों को अनुमान लगाने के इस आसान नियम का फ़ायदा मिल सकता है. यह नियम, कर्सर घुमाने पर या पॉइंटरडाउन पर, सभी लिंक को बुनियादी तौर पर प्रीरेंडर करेगा, लेकिन अनुमान लगाने के नियमों को लागू करना. हालांकि, यह कारगर साबित होगा:
<script type="speculationrules">
{
"prerender": [{
"source": "document",
"where": {
"href_matches": "/*"
},
"eagerness": "moderate"
}]
}
</script>
Chrome की सीमाएं
eagerness के विकल्प के साथ भी, Chrome ने इस एपीआई के बहुत ज़्यादा इस्तेमाल को रोकने के लिए कुछ सीमाएं तय की हैं:
eagerness |
प्रीफ़ेच करें | प्रीरेंडर |
|---|---|---|
immediate / eager |
50 | 10 |
moderate / conservative |
2 (एफ़आईएफ़ओ) | 2 (एफ़आईएफ़ओ) |
moderate और conservative की सेटिंग, उपयोगकर्ता के इंटरैक्शन पर निर्भर करती हैं. ये सेटिंग फ़र्स्ट इन, फ़र्स्ट आउट (एफ़आईएफ़ओ) के हिसाब से काम करती हैं. सीमा पूरी होने के बाद, नए अनुमान लगाने की वजह से सबसे पुराना अनुमान रद्द हो जाएगा और मेमोरी बचाने के लिए नए अनुमान की जगह नए अनुमान का इस्तेमाल हो जाएगा.
यह तथ्य कि उपयोगकर्ताओं ने moderate और conservative अनुमान लगाया है, हम मेमोरी बचाने के लिए 2 की कम सीमा का इस्तेमाल कर सकते हैं. immediate और eager सेटिंग, उपयोगकर्ता की कार्रवाई से ट्रिगर नहीं होती हैं. इसलिए, इनकी सीमा ज़्यादा होती है, क्योंकि ब्राउज़र को यह पता नहीं चलता कि कौनसी सेटिंग और सेटिंग की ज़रूरत है.
एफ़आईएफ़ओ की सूची से बाहर होने की वजह से जो अनुमान रद्द हो जाता है उसे फिर से ट्रिगर किया जा सकता है. उदाहरण के लिए, उस लिंक पर फिर से कर्सर घुमाना. इस वजह से, उस यूआरएल का फिर से अनुमान लगाया जा सकता है. उस स्थिति में, पिछले अनुमान के कारण ब्राउज़र उस URL के लिए HTTP कैश में कुछ संसाधन संचित कर सकता है, इसलिए अनुमान को दोहराने से नेटवर्क बहुत कम होगा और समय भी लगेगा.
immediate और eager की सीमाएं भी डाइनैमिक होती हैं. उत्सुकता के इन लेवल का इस्तेमाल करके, अनुमान लगाने के नियम से जुड़े स्क्रिप्ट एलिमेंट को हटाने से, हटाए गए अनुमान को रद्द कर दिया जाएगा. अगर इन यूआरएल को नई यूआरएल स्क्रिप्ट में शामिल किया गया है और इनकी सीमा खत्म नहीं हुई है, तो इनका फिर से अनुमान भी लगाया जा सकता है.
Chrome कुछ शर्तों में अनुमान लगाने पर रोक भी देगा. इनमें ये शामिल हैं:
- डेटा सेव करें.
- एनर्जी सेवर.
- मेमोरी की सीमाएं.
- जब "पेजों को पहले से लोड करने की सुविधा" सेटिंग बंद हो (इसे uBlock Origin जैसे Chrome एक्सटेंशन भी साफ़ तौर पर बंद कर देते हैं).
- बैकग्राउंड में खुले हुए पेज.
इन सभी स्थितियों का मकसद, ज़रूरत से ज़्यादा अनुमान लगाने के असर को कम करना है, ताकि उपयोगकर्ताओं को नुकसान हो.
वैकल्पिक source
Chrome 122 में, source बटन को ज़रूरी नहीं बनाया जाता है, क्योंकि इसका अनुमान url या where बटन की मौजूदगी से लगाया जा सकता है. इसलिए, अनुमान लगाने के ये दो नियम एक जैसे हैं:
<script type="speculationrules">
{
"prerender": [{
"source": "document",
"where": { "href_matches": "/*" },
"eagerness": "moderate"
}]
}
</script>
<script type="speculationrules">
{
"prerender": [{
"where": { "href_matches": "/*" },
"eagerness": "moderate"
}]
}
</script>
Speculation-Rules एचटीटीपी हेडर
अनुमान लगाने के नियम, सीधे दस्तावेज़ के एचटीएमएल में शामिल करने के बजाय, Speculation-Rules एचटीटीपी हेडर का इस्तेमाल करके भी डिलीवर किए जा सकते हैं. इससे सीडीएन से इन्हें आसानी से डिप्लॉय किया जा सकता है. इसके लिए, आपको दस्तावेज़ के कॉन्टेंट में बदलाव करने की ज़रूरत नहीं पड़ती.
Speculation-Rules एचटीटीपी हेडर, दस्तावेज़ के साथ दिखाया जाता है. साथ ही, अनुमान लगाने के नियमों वाली JSON फ़ाइल की जगह पर ले जाता है:
Speculation-Rules: "/speculationrules.json"
इस संसाधन को सही MIME टाइप का इस्तेमाल करना चाहिए. साथ ही, अगर यह क्रॉस-ऑरिजिन संसाधन है, तो सीओआरएस की जांच पास करें.
Content-Type: application/speculationrules+json
Access-Control-Allow-Origin: *
अगर आपको मिलते-जुलते यूआरएल का इस्तेमाल करना है, तो अनुमान लगाने के अपने नियमों में "relative_to": "document" कुंजी शामिल करें. ऐसा न होने पर, मिलते-जुलते यूआरएल, अनुमान लगाने के नियमों से जुड़ी JSON फ़ाइल के यूआरएल से मिलते-जुलते होंगे. यह खास तौर पर तब काम आ सकता है, जब आपको एक ही ऑरिजिन वाले कुछ लिंक या सभी लिंक चुनने हों.
कैश मेमोरी का बेहतर तरीके से दोबारा इस्तेमाल करना
हमने Chrome में कैश मेमोरी में डेटा सेव करने के लिए कई सुधार किए हैं. इससे किसी दस्तावेज़ को प्रीफ़ेच (या प्रीरेंडर करना) करके भी, एचटीटीपी कैश मेमोरी में संसाधनों को सेव और फिर से इस्तेमाल किया जा सकता है. इसका मतलब है कि अनुमान लगाने से आने वाले समय में भी फ़ायदे हो सकते हैं, भले ही अनुमान का इस्तेमाल न किया जाए.
इससे दोबारा अनुमान लगाना (उदाहरण के लिए, moderate उत्सुकता सेटिंग वाले दस्तावेज़ के नियम) काफ़ी सस्ता हो जाता है, क्योंकि Chrome कैश किए जा सकने वाले संसाधनों के लिए एचटीटीपी कैश का इस्तेमाल करेगा.
हम कैश मेमोरी के दोबारा इस्तेमाल को बेहतर बनाने के लिए, No-Vary-Search के नए प्रस्ताव को भी स्वीकार करते हैं.
No-Vary-Search सहायता
किसी पेज को प्रीफ़ेच या प्रीरेंडर करते समय, हो सकता है कि कुछ यूआरएल पैरामीटर (जिन्हें तकनीकी तौर पर खोज पैरामीटर कहा जाता है) सर्वर से डिलीवर किए गए पेज के लिए अहम न हों. इनका इस्तेमाल सिर्फ़ क्लाइंट साइड JavaScript के लिए किया जाता है.
उदाहरण के लिए, Google Analytics, कैंपेन की परफ़ॉर्मेंस का आकलन करने के लिए UTM पैरामीटर का इस्तेमाल करता है. हालांकि, आम तौर पर इस वजह से सर्वर से अलग-अलग पेज डिलीवर नहीं होते. इसका मतलब है कि page1.html?utm_content=123 और page1.html?utm_content=456, सर्वर से एक ही पेज को डिलीवर करेंगे, ताकि कैश मेमोरी से एक ही पेज का फिर से इस्तेमाल किया जा सके.
इसी तरह, ऐप्लिकेशन उन अन्य यूआरएल पैरामीटर का इस्तेमाल कर सकते हैं जिन्हें सिर्फ़ क्लाइंट साइड पर हैंडल किया जाता है.
No-Vary-Search प्रस्ताव, सर्वर को ऐसे पैरामीटर तय करने की अनुमति देता है, जिनकी वजह से डिलीवर किए गए संसाधन पर कोई असर नहीं होता है और इसलिए ब्राउज़र को किसी दस्तावेज़ के पहले से कैश मेमोरी में सेव किए गए वर्शन का फिर से इस्तेमाल करने की अनुमति देता है, जो सिर्फ़ इन पैरामीटर से अलग होते हैं. ध्यान दें: फ़िलहाल, यह सुविधा सिर्फ़ Chrome और Chromium का इस्तेमाल करने वाले ब्राउज़र में, प्रीफ़ेच किए गए नेविगेशन के अनुमान के लिए काम करती है.
अनुमान लगाने के नियम, expects_no_vary_search का इस्तेमाल करके यह बताते हैं कि No-Vary-Search एचटीटीपी हेडर कहां दिख सकता है. ऐसा करने से गै़र-ज़रूरी डाउनलोड से बचने में मदद मिल सकती है.
<script type="speculationrules">
{
"prefetch": [{
"urls": ["/products*"],
"expects_no_vary_search": "params=(\"id\")"
}]
}
</script>
<a href="/products?id=123">Product 123</a>
<a href="/products?id=124">Product 124</a>
इस उदाहरण में, /products के शुरुआती पेज का एचटीएमएल, 123 और 124, दोनों प्रॉडक्ट आईडी के लिए एक ही है. हालांकि, id सर्च पैरामीटर का इस्तेमाल करके प्रॉडक्ट डेटा फ़ेच करने के लिए JavaScript का इस्तेमाल करके, क्लाइंट-साइड रेंडरिंग के आधार पर पेज का कॉन्टेंट अलग-अलग होता है. इसलिए, हम बड़ी सावधानी के साथ उस यूआरएल को प्रीफ़ेच करते हैं और उसे No-Vary-Search एचटीटीपी हेडर दिखाना चाहिए. इससे यह पता चलना चाहिए कि पेज का इस्तेमाल किसी भी id सर्च पैरामीटर के लिए किया जा सकता है.
हालांकि, अगर प्रीफ़ेच पूरा होने से पहले उपयोगकर्ता किसी लिंक पर क्लिक करता है, तो हो सकता है कि ब्राउज़र को /products पेज न मिला हो. इस मामले में, ब्राउज़र को यह पता नहीं चलता कि उसमें No-Vary-Search एचटीटीपी हेडर होगा या नहीं. इसके बाद, ब्राउज़र में यह चुनने का विकल्प होता है कि लिंक को फिर से फ़ेच करना है या नहीं. इसके अलावा, प्रीफ़ेच के पूरा होने का इंतज़ार किया जा सकता है, ताकि यह देखा जा सके कि उसमें No-Vary-Search एचटीटीपी हेडर है या नहीं. expects_no_vary_search सेटिंग से ब्राउज़र को पता चलता है कि पेज रिस्पॉन्स में No-Vary-Search एचटीटीपी हेडर हो सकता है. साथ ही, वह प्रीफ़ेच के पूरा होने तक इंतज़ार करता है.
डेमो
हमने https://speculative-rules.glitch.me/common-fruits.html पर एक डेमो बनाया है. इसका इस्तेमाल करके, दस्तावेज़ के नियमों को देखा जा सकता है और moderate उत्सुकता दिखाने की सेटिंग लागू की जा सकती है:
DevTools खोलें और ऐप्लिकेशन पैनल पर क्लिक करें. इसके बाद, बैकग्राउंड सेवाएं सेक्शन में, अनुमान लोड पर क्लिक करें, फिर अनुमान पैनल पर क्लिक करें और स्थिति कॉलम के मुताबिक क्रम से लगाएं.
फलों पर कर्सर घुमाने पर, आपको पेज प्रीरेंडरिंग की प्रोसेस दिखेगी. इन पर क्लिक करने से, पहले से रेंडर नहीं की गई किसी रेसिपी के मुकाबले, एलसीपी में ज़्यादा समय लगता है. इस वीडियो में इस डेमो के बारे में भी बताया गया है:
अगर आपको अनुमान लगाने के नियमों को डीबग करने के लिए DevTools का इस्तेमाल करने के तरीके के बारे में ज़्यादा जानकारी चाहिए, तो सट्टा लगाने के नियमों को डीबग करने से जुड़ा ब्लॉग पोस्ट लेख पढ़ें.
अनुमान लगाने के नियमों के लिए प्लैटफ़ॉर्म से जुड़ी सहायता
<script type="speculationrules"> एलिमेंट में, अनुमान लगाने से जुड़े नियमों को इंजेक्ट करना आसान होता है. हालांकि, प्लैटफ़ॉर्म की सहायता टीम इसे एक-क्लिक में लागू कर सकती है. हम अनुमान लगाने के नियमों को लागू करने की प्रोसेस को आसान बनाने के लिए, अलग-अलग प्लैटफ़ॉर्म और पार्टनर के साथ काम कर रहे हैं.
हम वेब इनक्यूबेटर कम्यूनिटी ग्रुप (डब्ल्यूआईसीजी) की मदद से, इस एपीआई के स्टैंडर्ड तय करने के लिए कड़ी मेहनत कर रहे हैं. इससे, अन्य ब्राउज़र भी इस एपीआई का इस्तेमाल कर सकेंगे.
WordPress
WordPress कोर परफ़ॉर्मेंस टीम (जिसमें Google के डेवलपर शामिल हैं) ने एक अटकलेशन नियमों वाला प्लगिन बनाया है. इस प्लग इन की मदद से, किसी भी WordPress साइट में, बस एक क्लिक में दस्तावेज़ के नियमों को जोड़ा जा सकता है. यह प्लगिन WordPress Performance Lab प्लगिन के ज़रिए भी इंस्टॉल करने के लिए उपलब्ध है. आपको इसे भी इंस्टॉल करना चाहिए, क्योंकि यह आपको टीम के मिलते-जुलते परफ़ॉर्मेंस प्लगिन के बारे में अप-टू-डेट रखेगा.
सेटिंग के दो ग्रुप उपलब्ध हैं: अनुमान मोड और ईगरनेस सेटिंग:
ज़्यादा मुश्किल सेटअप के लिए, दस्तावेज़ पढ़ें. उदाहरण के लिए, अगर आपको कुछ यूआरएल को प्रीफ़ेच या पहले से रेंडर किए जाने से रोकना है, तो यह तरीका अपनाएं.
Akamai
Akamai, दुनिया की सबसे बड़ी सीडीएन सेवा देने वाली कंपनियों में से एक है. साथ ही, यह पिछले कुछ समय से speculation Rules API के साथ सक्रिय रूप से प्रयोग कर रहा है. Akamai ने दस्तावेज़ रिलीज़ किए हैं. इसमें बताया गया है कि ग्राहक, सीडीएन सेटिंग में इस एपीआई को कैसे चालू कर सकते हैं. उन्होंने इससे पहले, इस नए एपीआई का इस्तेमाल करके बेहतरीन नतीजे पाने की सुविधा भी शेयर की थी.
NitroPack
NitroPack, परफ़ॉर्मेंस को ऑप्टिमाइज़ करने वाला एक समाधान है. यह अपने कस्टम नेविगेशन एआई का इस्तेमाल करके अनुमान लगाने के नियमों में जोड़े जाने वाले पेजों का अनुमान लगाता है. इससे लिंक पर कर्सर घुमाने से ज़्यादा समय मिलता है. साथ ही, नज़र आने वाले सभी लिंक का अनुमान लगाने की ज़रूरत नहीं होती. ज़्यादा जानकारी के लिए, Nitropack अनुमान नियम एपीआई दस्तावेज़ देखें. इस नई सुविधा से पता चलता है कि साइट की खास जानकारी के साथ जोड़े जाने पर, पुरानी सूची के नियमों में अब भी बहुत कुछ किया जा सकता है.
Chrome टीम ने ज़्यादा जानकारी ढूंढने वाले लोगों के लिए, अनुमान नियमों के एपीआई के लिए एक वेबिनार पर NitroPack के साथ भी काम किया. इसमें, शुरुआती और अक्सर अनुमान लगाने के साथ-साथ देर से और कम बार अनुमान लगाने के बीच ज़रूरी बातों पर अच्छी चर्चा शामिल है.
एस्ट्रो
Astro ने प्रयोग के तौर पर, अनुमान नियम एपीआई के 4.2 वर्शन का इस्तेमाल करके पहले से रेंडर किए गए पेज जोड़े. इस सुविधा की मदद से डेवलपर, Astro का इस्तेमाल करके इस सुविधा को आसानी से चालू कर सकते हैं. साथ ही, जो ब्राउज़र अनुमान लगाने के लिए बने नियम एपीआई के साथ काम नहीं करते उनके लिए स्टैंडर्ड प्रीफ़ेच की सुविधा का इस्तेमाल किया जा रहा है. ज़्यादा जानकारी के लिए, क्लाइंट के प्रीरेंडरिंग से जुड़े दस्तावेज़ पढ़ें.
नतीजा
अनुमान लगाने के नियम एपीआई में ये सुविधाएं जोड़ी गई हैं. इनसे साइटों के लिए, परफ़ॉर्मेंस को बेहतर बनाने वाली इस नई दिलचस्प सुविधा को ज़्यादा आसानी से इस्तेमाल किया जा सकता है. इसमें, इस्तेमाल न किए गए अनुमान के साथ संसाधनों के बर्बाद होने का जोखिम भी कम होता है. यह देखना दिलचस्प है कि प्लैटफ़ॉर्म पहले से ही इस एपीआई का इस्तेमाल कर रहे हैं. हमें उम्मीद है कि साल 2024 में, हम इस एपीआई का ज़्यादा से ज़्यादा इस्तेमाल करेंगे. इससे असली उपयोगकर्ताओं को बेहतर परफ़ॉर्मेंस मिलेगी.
अनुमान लगाने के नियम एपीआई से मिलने वाली परफ़ॉर्मेंस के अलावा, हम यह देखने के लिए भी उत्साहित हैं कि इससे नए अवसर कैसे मिलेंगे. ट्रांज़िशन देखें एक नया एपीआई है. इसकी मदद से डेवलपर, नेविगेशन के बीच ज़्यादा आसानी से ट्रांज़िशन तय कर सकते हैं. फ़िलहाल, यह सुविधा एक पेज के ऐप्लिकेशन (एसपीए) के लिए उपलब्ध है, लेकिन एक से ज़्यादा पेज वाला वर्शन चल रहा है (और Chrome में फ़्लैग के पीछे उपलब्ध है). प्रीरेंडरिंग, इस सुविधा का एक नैचुरल ऐड-ऑन है. इससे यह पक्का किया जाता है कि कोई देरी न हो. इससे, उपयोगकर्ता अनुभव को बेहतर बनाने में रुकावट आती है. हमने पहले ही इस कॉम्बिनेशन वाली साइटें देखी हैं.
हम 2024 में, अनुमान लगाने से जुड़े नियम एपीआई को और ज़्यादा इस्तेमाल करते रहेंगे. साथ ही, एपीआई में किए जाने वाले सुधारों के बारे में आपको अपडेट देते रहेंगे.