डेवलपर को Chrome के मेमोरी और एनर्जी सेवर मोड के बारे में क्या जानने की ज़रूरत है

Philip Walton

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 API, इस मोड के चालू होने पर डिसप्ले रीफ़्रेश दर में होने वाले किसी भी बदलाव से अपने-आप अडजस्ट हो जाएंगे.

अगर आपकी साइट ऐसे JavaScript-आधारित ऐनिमेशन का इस्तेमाल करती है जो सभी उपयोगकर्ताओं के लिए खास रीफ़्रेश दर के हिसाब से काम करते हैं, तो इस मोड में समस्या हो सकती है.

उदाहरण के लिए, अगर आपकी साइट requestAnimationFrame() लूप का इस्तेमाल करती है और यह मानती है कि कॉलबैक के बीच ठीक 16.67 मिलीसेकंड होंगे, तो एनर्जी सेवर मोड चालू होने पर आपके ऐनिमेशन दोगुने धीमी रफ़्तार से चलेंगे.

ध्यान दें कि डेवलपर के लिए यह हमेशा समस्या बनी रहती है कि सभी उपयोगकर्ताओं के लिए, डिफ़ॉल्ट रीफ़्रेश दर 60 हर्ट्ज़ की है. ऐसा इसलिए है, क्योंकि कई मौजूदा डिवाइसों पर यह दर लागू नहीं होती.

डिसप्ले की रीफ़्रेश दर को मेज़र किया जा रहा है

डिसप्ले रीफ़्रेश दर को मापने के लिए कोई खास वेब एपीआई नहीं है. आम तौर पर, मौजूदा एपीआई की मदद से ऐसा करने का सुझाव नहीं दिया जाता.

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

अपनी साइट को एनर्जी सेवर मोड में टेस्ट करना

एनर्जी सेवर मोड में अपनी साइट की जांच करने का एक तरीका यह है कि आप Chrome की सेटिंग में मोड चालू करके, डिवाइस के अनप्लग होने पर उसे चलाने के लिए कॉन्फ़िगर करें.

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

1. chrome://flags/#battery-saver-mode-available फ़्लैग चालू करें.
2. chrome://discards पर जाएं और बैटरी सेवर मोड टॉगल करें लिंक पर क्लिक करें (ज़रूरी: लिंक काम करे, इसके लिए #battery-saver-mode-available फ़्लैग का चालू होना ज़रूरी है).

इस सुविधा को चालू करने के बाद, अपनी साइट से इंटरैक्ट किया जा सकता है और यह पुष्टि की जा सकती है कि सब कुछ वैसा ही है जैसा होना चाहिए: उदाहरण के लिए, ऐनिमेशन और ट्रांज़िशन आपके हिसाब से चलते हैं.

खास जानकारी

Chrome के 'मेमोरी सेवर' और 'एनर्जी सेवर' वाले मोड मुख्य तौर पर लोगों के लिए उपलब्ध होते हैं. हालांकि, इन सुविधाओं का असर डेवलपर पर भी पड़ सकता है, क्योंकि इन्हें ठीक से मैनेज न करने पर, आपकी साइट पर आने वाले लोगों के अनुभव पर बुरा असर पड़ सकता है.

आम तौर पर, इन नए मोड को डेवलपर के मौजूदा सबसे सही तरीकों को ध्यान में रखकर डिज़ाइन किया गया था. अगर डेवलपर लंबे समय से वेब पर इस्तेमाल किए जाने के सबसे सही तरीके अपना रहे हैं, तो उनकी साइटें इन नए मोड के साथ ठीक से काम करती रहेंगी.

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

हमेशा की तरह, शानदार अनुभव देने के लिए अपनी साइट की जांच करना सबसे अच्छा तरीका है. इसके लिए, यह देखें कि आपकी साइट, उपयोगकर्ताओं की शर्तों से मेल खाती हो.