अनुमान लगाने के नियम वाले एपीआई में सुधार

Barry Pollard

Chrome की टीम सपने-प्रक्रिया नियम एपीआई के कुछ दिलचस्प अपडेट पर काम कर रही है. इनका इस्तेमाल नेविगेशन की परफ़ॉर्मेंस को बेहतर बनाने के लिए किया जाता है. अपडेट को प्रीफ़ेच करके या आगे के नेविगेशन को पहले से रेंडर करके किया जाता है. ये अतिरिक्त सुधार अब Chrome 122 में उपलब्ध हैं (हालांकि, इसके पुराने वर्शन में कुछ सुविधाएं भी उपलब्ध हैं).

इन बदलावों की वजह से, पेजों को प्रीफ़ेच और प्रीरेंडरिंग करने की प्रोसेस आसान हो जाती है और इससे कोई नुकसान नहीं होता. हमें उम्मीद है कि आने वाले समय में इस तरह के इस्तेमाल को बढ़ावा मिलेगा.

अतिरिक्त सुविधाएं

सबसे पहले, अनुमान के नियम वाले एपीआई में जोड़े गए नए बदलावों के बारे में ज़्यादा जानकारी और उन्हें इस्तेमाल करने के तरीके के बारे में जानकारी दी गई है. इसके बाद, हम आपको एक डेमो दिखाएंगे, ताकि आप उन्हें काम करते हुए देख सकें.

दस्तावेज़ के नियम

पहले, Speculation Rules API के लिए, प्रीफ़ेच या प्रीरेंडरिंग करने के लिए यूआरएल की एक सूची तय की जाती थी:

<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 ने इस एपीआई के ज़रूरत से ज़्यादा इस्तेमाल को रोकने के लिए कुछ सीमाएं तय की हैं:

moderate और conservative सेटिंग—जो उपयोगकर्ता के इंटरैक्शन पर निर्भर करती हैं—फ़र्स्ट इन, फ़र्स्ट आउट (एफ़आईएफ़ओ) के हिसाब से काम करती हैं. सीमा तक पहुंचने के बाद, नए अनुमान को रद्द कर दिया जाएगा और मेमोरी बचाने के लिए, नए अनुमान को बदल दिया जाएगा.

इस तथ्य की वजह से उपयोगकर्ता moderate और conservative अनुमान लगाते हैं, तो हमें मेमोरी बचाने के लिए दो सेट के ज़्यादा सामान्य थ्रेशोल्ड का इस्तेमाल करने का विकल्प मिलता है. immediate और eager सेटिंग, उपयोगकर्ता की कार्रवाई से ट्रिगर नहीं होती हैं. इसलिए, इनकी सीमा भी ज़्यादा होती है. ऐसा इसलिए, क्योंकि ब्राउज़र को यह पता नहीं चलता कि किस कार्रवाई की ज़रूरत है और कब उनकी ज़रूरत है.

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

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

इसकी वजह से दोबारा अनुमान लगाना भी काफ़ी सस्ता हो जाता है, क्योंकि Chrome कैश मेमोरी में सेव किए जा सकने वाले रिसॉर्स के लिए, एचटीटीपी कैश मेमोरी का इस्तेमाल करेगा. उदाहरण के लिए, moderate eagerness सेटिंग वाले दस्तावेज़ नियमों के लिए).

हम कैश मेमोरी को फिर से इस्तेमाल करने की सुविधा को बेहतर बनाने के लिए, No-Vary-Search के नए प्रस्ताव पर भी काम करते हैं.

No-Vary-Search सहायता

किसी पेज को प्रीफ़ेच या प्रीरेंडर करते समय, ऐसा हो सकता है कि सर्वर के डिलीवर किए गए पेज के लिए, कुछ यूआरएल पैरामीटर (जिन्हें तकनीकी तौर पर खोज पैरामीटर कहा जाता है) ज़रूरी न हों. इन पैरामीटर का इस्तेमाल सिर्फ़ क्लाइंट-साइड JavaScript पर किया जाता है.

उदाहरण के लिए, Google Analytics, UTM पैरामीटर का इस्तेमाल कैंपेन मेज़रमेंट के लिए करता है. हालांकि, आम तौर पर इनकी वजह से सर्वर से अलग-अलग पेज डिलीवर नहीं होते. इसका मतलब है कि page1.html?utm_content=123 और page1.html?utm_content=456 एक ही पेज को सर्वर से डिलीवर करेंगे. इसलिए, कैश मेमोरी से उसी पेज को फिर से इस्तेमाल किया जा सकता है.

इसी तरह, ऐप्लिकेशन ऐसे दूसरे यूआरएल पैरामीटर का इस्तेमाल कर सकते हैं जिन्हें सिर्फ़ क्लाइंट-साइड हैंडल किया जाता है.

No-variant-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 eagerness सेटिंग चालू की जा सकती है:

DevTools खोलें और ऐप्लिकेशन पैनल पर क्लिक करें. इसके बाद, बैकग्राउंड सेवाएं सेक्शन में, अनुमानित लोड पर क्लिक करें. इसके बाद, अनुमान पैनल पर क्लिक करें और स्थिति कॉलम के हिसाब से क्रम में लगाएं.

फलों पर कर्सर घुमाने पर, आपको पेज प्रीरेंडरिंग करते हुए दिखेंगे. इन पर क्लिक करने से किसी एक रेसिपी की तुलना में, एलसीपी टाइम कम समय में दिखेगा, जिसे पहले से रेंडर नहीं किया जाता. इस डेमो की पूरी जानकारी इस वीडियो में भी दी गई है:

अनुमान लगाने के नियमों को डीबग करने के लिए, DevTools का इस्तेमाल करने के तरीके के बारे में ज़्यादा जानकारी के लिए, अनुमान लगाने के नियमों से जुड़ा ब्लॉग पोस्ट देखा जा सकता है.

अनुमान लगाने के नियमों के लिए प्लैटफ़ॉर्म से जुड़ी सहायता

अनुमान लगाने के नियमों को <script type="speculationrules"> एलिमेंट में इंजेक्ट करके, अनुमान लगाना आसान होता है. हालांकि, प्लैटफ़ॉर्म की मदद से, इसे एक-क्लिक में लागू किया जा सकता है. हम कई प्लैटफ़ॉर्म और पार्टनर के साथ मिलकर काम कर रहे हैं, ताकि अनुमान लगाने के नियमों को लागू करना आसान बनाया जा सके.

हम Web Incubator Community Group (WICG) के ज़रिए, एपीआई के स्टैंडर्ड तय करने की भी पूरी कोशिश कर रहे हैं. इससे दूसरे ब्राउज़र भी इस एपीआई को आसानी से लागू कर सकेंगे.

WordPress

WordPress की मुख्य परफ़ॉर्मेंस टीम ने अनुमान के नियम वाला प्लगिन बनाया. इसमें Google के डेवलपर भी शामिल हैं. इस प्लग इन की मदद से, किसी भी WordPress साइट पर दस्तावेज़ के नियमों को एक क्लिक में आसानी से जोड़ा जा सकता है. यह प्लग इन WordPress Performance Lab प्लगिन की मदद से भी इंस्टॉल किया जा सकता है. आपको इसे इंस्टॉल करने के बारे में भी सोचना चाहिए, क्योंकि यह आपको टीम से मिलते-जुलते परफ़ॉर्मेंस प्लगिन के बारे में अप-टू-डेट रखेगा.

सेटिंग के दो ग्रुप उपलब्ध हैं: अनुमान मोड और एगरनेस सेटिंग:

ज़्यादा मुश्किल सेटअप के लिए, दस्तावेज़ पढ़ें. उदाहरण के लिए, कुछ यूआरएल को प्रीफ़ेच या प्रीरेंडरिंग होने से रोकने के लिए.

अकामाई

Akamai, दुनिया की सबसे बड़ी सीडीएन प्रोवाइडर में से एक है. वे कुछ समय से, Speculation Rules API के साथ एक्सपेरिमेंट कर रहे हैं. Akamai ने दस्तावेज़ रिलीज़ किए हैं. इसमें बताया गया है कि ग्राहक, सीडीएन सेटिंग में इस एपीआई को कैसे चालू कर सकते हैं. उन्होंने पहले भी इस नए एपीआई की मदद से, शानदार नतीजे शेयर किए हैं.

NitroPack

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

Chrome की टीम ने ज़्यादा जानकारी मांगने वाले लोगों के लिए, NitroPack के साथ Speculation Rules API के लिए एक वेबिनार पर भी काम किया. इसमें, शुरुआती और अक्सर अनुमान लगाने के साथ-साथ, देर से और कम बार अनुमान लगाने के बीच ज़रूरी बातों पर चर्चा की गई थी.

एस्ट्रो

Astro ने प्रयोग के तौर पर 4.2 में अनुमान के नियम एपीआई का इस्तेमाल करके, प्रीरेंडरिंग पेज जोड़े हैं. इससे, Astro का इस्तेमाल करने वाले डेवलपर इस सुविधा को आसानी से चालू कर पाएंगे. ऐसा करने के लिए, वे ब्राउज़र के लिए स्टैंडर्ड प्रीफ़ेच में वापस जाएंगे जो अनुमान लगाने के नियम एपीआई के साथ काम नहीं करते. ज़्यादा जानकारी के लिए, क्लाइंट को प्रीरेंडरिंग से जुड़ा दस्तावेज़ पढ़ें.

नतीजा

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

अनुमान नियम एपीआई से मिलने वाले परफ़ॉर्मेंस में होने वाले फ़ायदों के अलावा, हम यह देखने के लिए भी उत्साहित हैं कि इससे आपको किस तरह के नए अवसर मिलेंगे. ट्रांज़िशन एक नया एपीआई है. इसकी मदद से डेवलपर, नेविगेशन के बीच ट्रांज़िशन को ज़्यादा आसानी से तय कर सकते हैं. फ़िलहाल, यह सुविधा एक पेज वाले ऐप्लिकेशन (एसपीए) के लिए उपलब्ध है. हालांकि, एक से ज़्यादा पेज वाला वर्शन अभी चल रहा है (और यह Chrome में एक फ़्लैग के पीछे उपलब्ध है). प्रीरेंडरिंग की सुविधा, इस सुविधा के लिए एक स्वाभाविक ऐड-ऑन है. इसकी मदद से यह पक्का किया जाता है कि कोई देरी न हो. इसकी वजह से, ट्रांज़िशन की वजह से उपयोगकर्ता अनुभव में सुधार नहीं होगा. हमने पहले ही इस कॉम्बिनेशन का इस्तेमाल करने वाली साइटें देखी हैं.

हमें उम्मीद है कि साल 2024 में, अनुमान के नियम वाले एपीआई को और भी बेहतर तरीके से लागू किया जाएगा. साथ ही, एपीआई में होने वाले किसी भी सुधार के बारे में आपको अपडेट देते रहेंगे.

स्वीकार हैं

Unsplash पर रॉबी डाउन का थंबनेल