सिंक्रोनस XMLHttpRequest() में, पेज खारिज होने की स्थिति को बेहतर बनाना

देर से होने वाले नेविगेशन में कमी आ रही है

जो मेडली

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

इस तरीके को बदलने की ज़रूरत है और ब्राउज़र काम कर रहे हैं. XMLHttpRequest() की खास जानकारी को पहले ही बंद करने और हटाने की तारीख तय कर दी गई है. खारिज करने के दौरान, Chrome 80 कई इवेंट हैंडलर में चालू होने वाले beforeunload, unload, pagehide, और visibilitychange जैसे इवेंट हैंडलर में सिंक्रोनस कॉल को अनुमति नहीं देता. WebKit ने हाल ही में इसी तरह व्यवहार में होने वाले बदलाव को लागू करने का वादा किया है.

इस लेख में, मैं संक्षेप में उन लोगों के लिए विकल्पों के बारे में बताऊँगी जिन्हें अपनी साइटों को अपडेट करने के लिए समय चाहिए. साथ ही, मैं XMLHttpRequest() के विकल्पों के बारे में भी बताऊँगी.

कुछ समय के लिए ऑप्ट-आउट करना

Chrome सिर्फ़ XMLHttpRequest() को प्लग-इन नहीं करना चाहता, इसलिए कुछ समय के लिए ऑप्ट-आउट करने के कुछ विकल्प उपलब्ध हैं. इंटरनेट पर मौजूद साइटों के लिए, ऑरिजिन ट्रायल की सुविधा उपलब्ध है. इससे, अपने पेज के हेडर में ऑरिजिन के हिसाब से बना टोकन जोड़ा जाता है. इससे, सिंक्रोनस XMLHttpRequest() कॉल चालू हो जाते हैं. यह विकल्प मार्च 2021 में, Chrome 89 के लॉन्च होने से कुछ समय पहले बंद हो जाएगा. Enterprise Chrome के ग्राहक AllowSyncXHRInPageDismissal नीति फ़्लैग का भी इस्तेमाल कर सकते हैं, जो इसके साथ खत्म होता है.

विकल्प

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

कीपअलाइव पाएं

फे़च एपीआई, अलग-अलग प्लैटफ़ॉर्म एपीआई पर इस्तेमाल करने के लिए, सर्वर इंटरैक्शन से निपटने का बेहतर तरीका उपलब्ध कराता है. साथ ही, एक जैसा इंटरफ़ेस भी उपलब्ध कराता है. इसके विकल्पों में keepalive है, जो यह पक्का करता है कि जिस पेज ने उसे खोला है वह खुला है या नहीं, इस पर अनुरोध जारी रहता है:

window.addEventListener('unload', {
  fetch('/siteAnalytics', {
    method: 'POST',
    body: getStatistics(),
    keepalive: true
  });
}

fetch() वाले तरीके का इस्तेमाल करके, सर्वर को भेजे जाने वाले डेटा पर बेहतर कंट्रोल मिलता है. इस उदाहरण में, मैं यह नहीं दिखाता कि fetch() ऐसा प्रॉमिस भी देता है जो Response ऑब्जेक्ट से हल होता है. मैं पेज के अनलोड होने के तरीके से बाहर निकलने की कोशिश कर रहा हूँ. इसलिए, मैंने इसे बंद करने का फ़ैसला किया है.

SendBeacon()

SendBeacon() असल में, फे़ड एपीआई का इस्तेमाल करता है. इसलिए, इसमें 64 केबी के पेलोड की सीमा एक जैसी है. इसलिए, यह भी पक्का करता है कि पेज अनलोड होने के बाद भी अनुरोध जारी रहे. इसका मुख्य फ़ायदा यह है कि इसे आसानी से समझा जा सकता है. इसकी मदद से, सिर्फ़ एक लाइन के कोड का इस्तेमाल करके डेटा सबमिट किया जा सकता है:

window.addEventListener('unload', {
  navigator.sendBeacon('/siteAnalytics', getStatistics());
}

नतीजा

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

Unsplash पर मैथ्यू हैमिल्टन की फ़ोटो