Chrome 108 में दो नए मोड पेश किए गए हैं: मेमोरी सेवर और एनर्जी सेवर. इनकी मदद से, उपयोगकर्ताओं को यह कंट्रोल करने की सुविधा मिलती है कि Chrome उनके सिस्टम के संसाधनों का इस्तेमाल कैसे करे.
ये नए मोड मुख्य रूप से उपयोगकर्ताओं के लिए हैं. हालांकि, इनका असर वेब डेवलपर पर भी पड़ता है. इसलिए, वेब डेवलपर को इनके बारे में पता होना चाहिए, क्योंकि इनसे आपकी साइट के उपयोगकर्ता अनुभव पर असर पड़ सकता है.
इस पोस्ट में, इन नए मोड के संभावित असर के बारे में बताया गया है. साथ ही, यह भी बताया गया है कि वेब डेवलपर क्या कर सकते हैं, ताकि वे उपयोगकर्ताओं को सबसे अच्छा अनुभव दे सकें.
मेमोरी सेवर मोड
मेमोरी सेवर मोड चालू होने पर, Chrome उन टैब को हटा देगा जिन्हें कुछ समय से बैकग्राउंड में इस्तेमाल नहीं किया गया है. इससे, इस्तेमाल किए जा रहे टैब के साथ-साथ, चल रहे अन्य ऐप्लिकेशन के लिए मेमोरी खाली हो जाती है. उपयोगकर्ता, Chrome को कुछ साइटों के टैब बंद न करने का निर्देश दे सकते हैं. हालांकि, यह उपयोगकर्ता की प्राथमिकता है और डेवलपर के तौर पर इसे कंट्रोल नहीं किया जा सकता.
किसी टैब को खारिज करने पर, उसका टाइटल और फ़ैविकन अब भी टैब स्ट्रिप में दिखता है. हालांकि, पेज नहीं दिखता. यह ठीक वैसा ही है जैसे टैब को सामान्य तरीके से बंद किया गया हो. अगर उपयोगकर्ता उस टैब पर फिर से जाता है, तो पेज अपने-आप फिर से लोड हो जाएगा.
सिर्फ़ कॉन्टेंट वाले पेजों के लिए, किसी टैब को खारिज करने और फिर से लोड करने से, उपयोगकर्ता अनुभव पर शायद कोई असर न पड़े. हालांकि, जटिल उपयोगकर्ता फ़्लो वाली रिच और इंटरैक्टिव साइटों के लिए, उस फ़्लो के बीच में पेज को फिर से लोड करने से बहुत परेशानी हो सकती है. ऐसा तब होगा, जब साइट उस पेज को ठीक उसी जगह पर वापस नहीं ला पाएगी जहां उपयोगकर्ता ने उसे छोड़ा था.
Chrome, मेमोरी बचाने के लिए टैब को खारिज करता है. ऐसा वह कई सालों से कर रहा है. हालांकि, ऐसा सिर्फ़ तब किया जाता है, जब सिस्टम की मेमोरी कम हो. यह समस्या बहुत कम होती है. इसलिए, हो सकता है कि वेब डेवलपर को पता न हो कि यह समस्या हो रही है.
Chrome 108 से, टैब को खारिज करने की सुविधा ज़्यादा सामान्य हो जाएगी. इसलिए, यह ज़रूरी है कि साइटें इन स्थितियों को आसानी से मैनेज कर सकें.
टैब को खारिज करने से जुड़ी समस्याओं को हल करने के सबसे सही तरीके
वेब डेवलपर के लिए, टैब को खारिज करना कोई नई चुनौती नहीं है. उपयोगकर्ता, अपने टास्क को पूरा करने से पहले, किसी पेज को जान-बूझकर या गलती से भी रीफ़्रेश कर सकता है. इसलिए, साइटों के लिए उपयोगकर्ता की स्थिति को सेव करना हमेशा ज़रूरी रहा है, ताकि उपयोगकर्ता के साइट छोड़ने और वापस आने पर, उसे वापस लाया जा सके.
सबसे अहम बात यह नहीं है कि उपयोगकर्ता की स्थिति को सेव करना है या नहीं, बल्कि यह है कि उसे कब सेव करना है. यह अहम है, क्योंकि किसी टैब को खारिज करने पर कोई इवेंट ट्रिगर नहीं होता. इसलिए, डेवलपर के पास इस बात पर प्रतिक्रिया देने का कोई तरीका नहीं होता कि यह क्या हो रहा है. इसके बजाय, डेवलपर को इस संभावना को पहले से ही समझ लेना चाहिए और इसके लिए पहले से तैयार रहना चाहिए.
उपयोगकर्ता की स्थिति को सेव करने के लिए सबसे सही समय ये हैं:
- स्थिति बदलने पर, समय-समय पर.
- जब भी कोई टैब बैकग्राउंड में चला जाता है (
visibilitychangeइवेंट).
स्टेटस को सेव करने के लिए ये सबसे खराब समय हैं:
beforeunloadइवेंट कॉलबैक में.unloadइवेंट कॉलबैक में.
स्टेटस को सेव करने के लिए ये सबसे खराब समय हैं, क्योंकि ये इवेंट पूरी तरह से भरोसेमंद नहीं हैं और कई स्थितियों में ट्रिगर नहीं होते. इनमें, किसी टैब को खारिज किए जाने की स्थिति भी शामिल है.
पेज लाइफ़साइकल इवेंट डायग्राम देखकर पता लगाया जा सकता है कि पेज को खारिज किए जाने पर कौनसे इवेंट ट्रिगर होंगे. इस डायग्राम से पता चलता है कि कोई टैब, किसी भी इवेंट के ट्रिगर होने के बिना, "छिपा हुआ" स्टेटस से "खारिज किया गया" स्टेटस में जा सकता है.
असल में, जब भी पेज "छिपा हुआ" स्टेटस में होता है, तो इस बात की कोई गारंटी नहीं होती कि ब्राउज़र के पेज को खारिज करने या उपयोगकर्ता के पेज को बंद करने से पहले, कोई दूसरा इवेंट ट्रिगर होगा. इसलिए, यह ज़रूरी है कि सेव नहीं किए गए उपयोगकर्ता स्टेटस को हमेशा visibilitychange इवेंट में सेव किया जाए, क्योंकि आपको दूसरा मौका नहीं मिल सकता.
नीचे दिए गए कोड में, उपयोगकर्ता की मौजूदा स्थिति में होने वाले किसी भी बदलाव को तुरंत सेव करने या उपयोगकर्ता के टैब को बैकग्राउंड में ले जाने या किसी दूसरे टैब पर जाने पर, उसे तुरंत सेव करने के लिए, लॉजिक के कुछ उदाहरण दिए गए हैं:
let state = {};
let hasUnstoredState = false;
function storeState() {
if (hasUnstoredState) {
// Store `state` to localStorage or IndexedDB...
}
hasUnstoredState = false;
}
export function updateState(newState) {
state = newState;
hasUnstoredState = true;
requestIdleCallback(storeState);
}
document.addEventListener('visibilitychange', () => {
if (document.visibilityState === 'hidden') {
storeState();
}
});
किसी टैब को खारिज किए जाने का पता लगाना
जैसा कि पहले बताया गया है, यह पता नहीं लगाया जा सकता कि कोई टैब बंद होने वाला है. हालांकि, यह पता लगाया जा सकता है कि उपयोगकर्ता के टैब पर वापस आने और पेज को रीलोड करने के बाद, टैब बंद हो गया था. इन स्थितियों में document.wasDiscarded प्रॉपर्टी की वैल्यू 'सही' होगी.
if (document.wasDiscarded) {
// The page was reloaded after a discard.
} else {
// The page was not reloaded after a discard.
}
अगर आपको यह समझना है कि आपके उपयोगकर्ताओं को इस तरह की समस्याएं कितनी बार आती हैं, तो इस जानकारी को कैप्चर करने के लिए अपने आंकड़े जुटाने वाले टूल को कॉन्फ़िगर करें.
उदाहरण के लिए, Google Analytics में कस्टम इवेंट पैरामीटर कॉन्फ़िगर किया जा सकता है. इससे यह पता लगाया जा सकता है कि टैब को खारिज करने से कितने प्रतिशत पेज व्यू मिले:
gtag('config', 'G-XXXXXXXXXX', {
was_discarded: document.wasDiscarded,
});
अगर आप आंकड़ों की सेवा देने वाली कंपनी हैं, तो हो सकता है कि आप अपने प्रॉडक्ट में इस डाइमेंशन को डिफ़ॉल्ट रूप से जोड़ना चाहें.
मेमोरी सेवर मोड में अपनी साइट की जांच करना
पेज को लोड करके और फिर किसी अलग टैब या विंडो में chrome://discards पर जाकर, यह जांच की जा सकती है कि कोई पेज खारिज होने पर उसे कैसे मैनेज किया जाता है.
chrome://discards यूज़र इंटरफ़ेस (यूआई) से, वह टैब ढूंढा जा सकता है जिसे आपको सूची से हटाना है. इसके बाद, कार्रवाइयां कॉलम में जाकर, तुरंत हटाएं पर क्लिक करें.
ऐसा करने पर, टैब को खारिज कर दिया जाएगा. इसके बाद, उस पर फिर से जाकर यह पुष्टि की जा सकती है कि पेज को उसी स्थिति में फिर से लोड किया गया है जिस स्थिति में आपने उसे छोड़ा था.
ध्यान दें कि फ़िलहाल, वेबड्राइवर या पपेटियर जैसे टेस्टिंग टूल की मदद से, टैब को अपने-आप खारिज करने की सुविधा को ऑटोमेट करने का कोई तरीका नहीं है. हालांकि, टैब को खारिज करने और वापस लाने की प्रोसेस, पेज को फिर से लोड करने की प्रोसेस से काफ़ी मिलती-जुलती है. इसलिए, अगर उपयोगकर्ता फ़्लो के बीच में पेज को फिर से लोड करने के बाद, उपयोगकर्ता की स्थिति को वापस लाया जाता है, तो हो सकता है कि यह सुविधा, टैब को खारिज करने/वापस लाने के लिए भी काम करे. इन दोनों के बीच मुख्य अंतर यह है कि किसी टैब को खारिज किए जाने पर, beforeunload, pagehide, और unload इवेंट ट्रिगर नहीं होते. इसलिए, जब तक उपयोगकर्ता की स्थिति को बनाए रखने के लिए इन इवेंट का इस्तेमाल नहीं किया जा रहा है, तब तक खारिज करने/वापस लाने के व्यवहार की जांच करने के लिए, रीफ़्रेश का इस्तेमाल किया जा सकता है.
एनर्जी सेवर मोड
एनर्जी सेवर मोड चालू होने पर, Chrome डिसप्ले के रीफ़्रेश रेट को कम करके बैटरी की खपत को कम करता है. इससे स्क्रोलिंग, ऐनिमेशन क्वालिटी, और वीडियो के फ़्रेम रेट पर असर पड़ता है.
आम तौर पर, डेवलपर को एनर्जी सेवर मोड के साथ काम करने के लिए कुछ करने की ज़रूरत नहीं होती. इस मोड के चालू होने पर, ऐनिमेशन, ट्रांज़िशन, और requestAnimationFrame() के लिए सीएसएस और JavaScript एपीआई, डिसप्ले के रीफ़्रेश रेट में होने वाले किसी भी बदलाव के हिसाब से अपने-आप अडजस्ट हो जाएंगे.
इस मोड से तब समस्या हो सकती है, जब आपकी साइट पर JavaScript पर आधारित ऐसे ऐनिमेशन इस्तेमाल किए जाते हैं जो सभी उपयोगकर्ताओं के लिए एक खास रीफ़्रेश रेट का इस्तेमाल करते हैं.
उदाहरण के लिए, अगर आपकी साइट requestAnimationFrame() लूप का इस्तेमाल करती है और यह मानती है कि कॉलबैक के बीच 16.67 मिलीसेकंड बीत चुके होंगे, तो एनर्जी सेवर मोड चालू होने पर आपके ऐनिमेशन दोगुनी धीमी गति से चलेंगे.
ध्यान दें कि डेवलपर के लिए, सभी उपयोगकर्ताओं के लिए डिफ़ॉल्ट तौर पर 60 हर्ट्ज़ का रिफ़्रेश रेट तय करना हमेशा समस्या पैदा करता रहा है. ऐसा इसलिए, क्योंकि यह कई मौजूदा डिवाइसों के लिए सही नहीं है.
डिसप्ले की रीफ़्रेश दर को मेज़र करना
डिसप्ले के रीफ़्रेश रेट को मेज़र करने के लिए, कोई खास वेब एपीआई नहीं है. आम तौर पर, मौजूदा एपीआई का इस्तेमाल करके ऐसा करने का सुझाव नहीं दिया जाता.
मौजूदा एपीआई का इस्तेमाल करके, डेवलपर requestAnimationFrame() कॉलबैक के बीच के टाइमस्टैंप की तुलना कर सकते हैं. ज़्यादातर मामलों में, यह किसी तय समय पर रीफ़्रेश रेट का अनुमान लगाने के लिए काम करता है. हालांकि, इससे आपको यह पता नहीं चलता कि रीफ़्रेश रेट कब बदलता है. ऐसा करने के लिए, आपको लगातार requestAnimationFrame() पोल चलाना होगा. इससे, आपके उपयोगकर्ताओं के लिए एनर्जी या बैटरी लाइफ़ को बचाने के लक्ष्य को पूरा नहीं किया जा सकेगा.
एनर्जी सेवर मोड में अपनी साइट की जांच करना
एनर्जी सेवर मोड में अपनी साइट की जांच करने का एक तरीका यह है कि आप Chrome की सेटिंग में जाकर, मोड चालू करें. इसके बाद, उसे डिवाइस के प्लग इन न होने पर चलने के लिए कॉन्फ़िगर करें.
अगर आपके पास ऐसा कोई डिवाइस नहीं है जिसे अनप्लग किया जा सकता है, तो मैन्युअल तरीके से भी मोड चालू किया जा सकता है. इसके लिए, यह तरीका अपनाएं:
chrome://flags/#battery-saver-mode-availableफ़्लैग चालू करें.chrome://discardsपर जाएं और बैटरी सेवर मोड को टॉगल करें लिंक पर क्लिक करें. अहम जानकारी: लिंक के काम करने के लिए,#battery-saver-mode-availableफ़्लैग चालू होना ज़रूरी है.
इस सुविधा को चालू करने के बाद, अपनी साइट के साथ इंटरैक्ट किया जा सकता है और यह पुष्टि की जा सकती है कि सब कुछ ठीक से दिख रहा है या नहीं. उदाहरण के लिए, ऐनिमेशन और ट्रांज़िशन सही स्पीड पर चल रहे हैं या नहीं.
खास जानकारी
Chrome के मेमोरी सेवर और एनर्जी सेवर मोड, मुख्य रूप से उपयोगकर्ताओं के लिए हैं. हालांकि, इनका असर डेवलपर पर भी पड़ता है. अगर इन मोड को सही तरीके से मैनेज नहीं किया जाता है, तो आपकी साइट पर आने वाले लोगों के अनुभव पर बुरा असर पड़ सकता है.
आम तौर पर, इन नए मोड को डेवलपर के लिए सबसे सही तरीकों को ध्यान में रखकर डिज़ाइन किया गया है. अगर डेवलपर, वेब के सबसे सही तरीकों का इस्तेमाल करते रहे हैं, तो उनकी साइटें इन नए मोड के साथ भी ठीक से काम करती रहेंगी.
हालांकि, अगर आपकी साइट पर इस पोस्ट में बताई गई कोई भी गलत गतिविधि की जा रही है, तो हो सकता है कि आपके उपयोगकर्ताओं को समस्याएं आ रही हों. इन दो मोड के चालू होने पर, ये समस्याएं और भी बढ़ सकती हैं.
हमेशा की तरह, यह पक्का करने का सबसे अच्छा तरीका है कि उपयोगकर्ताओं को बेहतरीन अनुभव मिल रहा है या नहीं. इसके लिए, अपनी साइट को उन स्थितियों में टेस्ट करें जो उपयोगकर्ताओं की स्थितियों से मेल खाती हों.