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 के मेमोरी सेवर और एनर्जी सेवर मोड, मुख्य रूप से उपयोगकर्ताओं के इस्तेमाल के लिए उपलब्ध हैं. हालांकि, इनका असर डेवलपर पर पड़ता है, क्योंकि अगर इन्हें सही तरीके से मैनेज न किया जाए, तो इनकी वजह से आपकी साइट पर आने वालों को परेशानी हो सकती है.
आम तौर पर, इन नए मोड को डेवलपर के लिए सबसे सही तरीकों को ध्यान में रखकर डिज़ाइन किया गया है. अगर डेवलपर, वेब के सबसे सही तरीकों का इस्तेमाल करते रहे हैं, तो उनकी साइटें इन नए मोड के साथ भी ठीक से काम करती रहेंगी.
हालांकि, अगर आपकी साइट पर इस पोस्ट में बताई गई कोई भी गलत गतिविधि की जा रही है, तो हो सकता है कि आपके उपयोगकर्ताओं को समस्याएं आ रही हों. इन दो मोड के चालू होने पर, ये समस्याएं और भी बढ़ सकती हैं.
हमेशा की तरह, इस बात की पुष्टि करने का सबसे अच्छा तरीका यह है कि आपकी साइट का अनुभव बेहतरीन है या नहीं. इसके लिए, अपनी साइट की शर्तों को उन उपयोगकर्ताओं की शर्तों के हिसाब से टेस्ट करें.