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.
}
अगर आपको यह समझना है कि आपके उपयोगकर्ताओं को इस तरह की स्थितियां कितनी बार आती हैं, तो इस जानकारी को कैप्चर करने के लिए, Analytics टूल को कॉन्फ़िगर करें.
उदाहरण के लिए, Google Analytics में कस्टम इवेंट पैरामीटर कॉन्फ़िगर किया जा सकता है. इससे यह पता लगाया जा सकता है कि टैब खारिज करने से कितने प्रतिशत पेज व्यू मिले:
gtag('config', 'G-XXXXXXXXXX', {
was_discarded: document.wasDiscarded,
});
अगर आप एनालिटिक्स कंपनी हैं, तो आप डिफ़ॉल्ट रूप से अपने प्रॉडक्ट में इस डाइमेंशन को जोड़ने पर विचार कर सकते हैं.
मेमोरी सेवर मोड में साइट की जांच करना
पेज लोड करके और फिर किसी अलग टैब या विंडो में chrome://discards पर जाकर, यह जांच की जा सकती है कि पेज को खारिज किए जाने का तरीका क्या है.
chrome://discards यूज़र इंटरफ़ेस (यूआई) से, सूची से वह टैब ढूंढा जा सकता है जिसे आपको खारिज करना है. इसके बाद, कार्रवाइयां कॉलम में तुरंत खारिज करें पर क्लिक करें.
इससे टैब खारिज हो जाएगा और आप उस पर दोबारा जा सकेंगे. इस बात की पुष्टि करने के बाद कि पेज को उसी स्थिति में फिर से लोड किया गया था जिस स्थिति में आपने उसे छोड़ा था.
ध्यान दें कि फ़िलहाल, वेबड्राइवर या कठपुतली जैसे टेस्टिंग टूल का इस्तेमाल करके, टैब खारिज किए जाने की प्रोसेस को ऑटोमेट करने का कोई तरीका नहीं है; हालांकि, टैब को खारिज करना और वापस लाना, पेज के फिर से लोड होने की तरह ही होता है. इसलिए, अगर उपयोगकर्ता के फ़्लो के दौरान में ही उपयोगकर्ता की स्थिति को फिर से लोड होने की जांच की जाती है, तो हो सकता है कि वह खारिज/वापस आ जाए. इन दोनों में मुख्य अंतर यह है कि beforeunload, pagehide, और unload इवेंट तब ट्रिगर नहीं होते, जब टैब को खारिज किया जा रहा हो. अगर उपयोगकर्ता की स्थिति को बनाए रखने के लिए आपको उन इवेंट पर भरोसा नहीं है, तो खारिज करने/वापस पाने के तरीके की जांच करने के लिए, फिर से लोड करने का इस्तेमाल किया जा सकता है.
एनर्जी सेवर मोड
एनर्जी सेवर मोड चालू होने पर Chrome, डिसप्ले की रीफ़्रेश दर को कम करके बैटरी की बचत करता है. इससे स्क्रोलिंग, ऐनिमेशन की क्वालिटी, और वीडियो के फ़्रेम रेट पर असर पड़ता है.
आम तौर पर, डेवलपर को एनर्जी सेवर मोड की सुविधा देने के लिए कुछ नहीं करना होता. इस मोड के चालू होने पर, ऐनिमेशन, ट्रांज़िशन, और requestAnimationFrame() के लिए सीएसएस और JavaScript API, डिसप्ले रीफ़्रेश दर में होने वाले किसी भी बदलाव के हिसाब से अपने-आप अडजस्ट हो जाएंगे.
इस मोड की मुख्य वजह हो सकता है कि आपकी साइट, JavaScript पर आधारित ऐनिमेशन का इस्तेमाल करती हो. इनमें सभी उपयोगकर्ताओं की रीफ़्रेश दर एक ही होती है.
उदाहरण के लिए, अगर आपकी साइट requestAnimationFrame() लूप का इस्तेमाल करती है और यह मान लेती है कि कॉलबैक के बीच ठीक 16.67 मिलीसेकंड का समय बीत चुका है, तो एनर्जी सेवर मोड चालू होने पर आपके ऐनिमेशन दोगुना धीमे चलेंगे.
ध्यान दें कि सभी उपयोगकर्ताओं के लिए, रीफ़्रेश दर को 60 हर्ट्ज़ पर डिफ़ॉल्ट तौर पर सेट करने में डेवलपर को हमेशा समस्या आती है. ऐसा इसलिए, क्योंकि मौजूदा कई डिवाइसों पर ऐसा नहीं होता है.
डिसप्ले की रीफ़्रेश दर को मेज़र किया जा रहा है
डिसप्ले रीफ़्रेश दर को मापने के लिए, कोई खास वेब एपीआई नहीं है. आम तौर पर, मौजूदा एपीआई का इस्तेमाल करके ऐसा करने का सुझाव नहीं दिया जाता.
मौजूदा एपीआई का इस्तेमाल करके, सबसे अच्छे डेवलपर requestAnimationFrame() कॉलबैक के बीच टाइमस्टैंप की तुलना कर सकते हैं. यह सुविधा ज़्यादातर मामलों में किसी तय समय पर रीफ़्रेश दर का अनुमान लगाने में काम करती है, लेकिन रीफ़्रेश दर में बदलाव होने पर आपको इसकी सूचना नहीं मिलती. ऐसा करने के लिए, आपको लगातार requestAnimationFrame() पोल चलाना होगा. इससे उपयोगकर्ताओं के ऊर्जा या बैटरी लाइफ़ को सुरक्षित रखने का लक्ष्य खत्म हो जाता है.
एनर्जी सेवर मोड में साइट की जांच करना
एनर्जी सेवर मोड में अपनी साइट की जांच करने का एक तरीका यह है कि Chrome की सेटिंग में जाकर, मोड को चालू करें और डिवाइस के अनप्लग होने पर चलने के लिए कॉन्फ़िगर करें.
यदि आपके पास ऐसा डिवाइस नहीं है जिसे अनप्लग किया जा सकता है, तो आप इन चरणों का पालन करके मैन्युअल रूप से भी मोड को सक्षम कर सकते हैं:
chrome://flags/#battery-saver-mode-availableफ़्लैग चालू करें.chrome://discardsपर जाएं और बैटरी सेवर मोड टॉगल करें लिंक पर क्लिक करें (ज़रूरी: लिंक को काम करने के लिए#battery-saver-mode-availableफ़्लैग चालू करना पड़े).
इस सुविधा को चालू करने के बाद, अपनी साइट के साथ इंटरैक्ट किया जा सकता है. साथ ही, यह पुष्टि की जा सकती है कि सब कुछ ठीक वैसा ही दिख रहा है जैसा कि यहां बताया गया है: उदाहरण के लिए, ऐनिमेशन और ट्रांज़िशन आपकी पसंद की स्पीड पर चलते हैं.
खास जानकारी
Chrome के मेमोरी सेवर और एनर्जी सेवर मोड, मुख्य रूप से उपयोगकर्ताओं के इस्तेमाल के लिए उपलब्ध हैं. हालांकि, इनका असर डेवलपर पर पड़ता है, क्योंकि अगर इन्हें सही तरीके से मैनेज न किया जाए, तो इनकी वजह से आपकी साइट पर आने वालों को परेशानी हो सकती है.
आम तौर पर, इन नए मोड को, डेवलपर के लिए सबसे सही तरीकों को ध्यान में रखकर डिज़ाइन किया गया है. अगर डेवलपर लंबे समय से वेब पर चलने वाले सबसे सही तरीकों का पालन कर रहे हैं, तो उनकी साइटें इन नए मोड के साथ ठीक से काम करती रहेंगी.
हालांकि, अगर आपकी साइट में इस पोस्ट में बताई गई कोई भी कार्रवाई शामिल है, तो हो सकता है कि उपयोगकर्ताओं को ऐसी समस्याएं आ रही हों जो सिर्फ़ इन दो मोड को चालू करने पर ही बढ़ेंगी.
हमेशा की तरह, इस बात की पुष्टि करने का सबसे अच्छा तरीका यह है कि आपकी साइट का अनुभव बेहतरीन है या नहीं. इसके लिए, अपनी साइट की शर्तों को उन उपयोगकर्ताओं की शर्तों के हिसाब से टेस्ट करें.