पेज लाइफ़साइकल एपीआई

Philip Walton

आजकल के आधुनिक ब्राउज़र, सिस्टम के संसाधनों की कमी होने पर कभी-कभी पेजों को निलंबित कर देते हैं या उन्हें पूरी तरह से खारिज कर देते हैं. आने वाले समय में, ब्राउज़र इस सुविधा को पहले से ही चालू रखना चाहते हैं, ताकि वे कम बैटरी और मेमोरी का इस्तेमाल करें. Page Lifecycle API, लाइफ़साइकल हुक उपलब्ध कराता है. इससे आपके पेज, ब्राउज़र के इन इंटरवेंशन को सुरक्षित तरीके से हैंडल कर सकते हैं. साथ ही, उपयोगकर्ता अनुभव पर इसका कोई असर नहीं पड़ता. एपीआई देखें, ताकि यह पता चल सके कि आपको अपने ऐप्लिकेशन में ये सुविधाएं लागू करनी चाहिए या नहीं.

बैकग्राउंड

ऐप्लिकेशन का लाइफ़साइकल, आधुनिक ऑपरेटिंग सिस्टम के लिए संसाधनों को मैनेज करने का एक अहम तरीका है. Android, iOS, और Windows के नए वर्शन पर, ओएस किसी भी समय ऐप्लिकेशन को शुरू और बंद कर सकता है. इससे इन प्लैटफ़ॉर्म को, संसाधनों को व्यवस्थित करने और उन्हें फिर से आवंटित करने में मदद मिलती है, ताकि उपयोगकर्ता को सबसे ज़्यादा फ़ायदा मिल सके.

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

वेब प्लैटफ़ॉर्म पर लंबे समय से ऐसे इवेंट मौजूद हैं जो लाइफ़साइकल की स्थितियों से जुड़े हैं. जैसे, load, unload, और visibilitychange. हालांकि, इन इवेंट की मदद से डेवलपर सिर्फ़ उन लाइफ़साइकल की स्थितियों में बदलाव कर सकते हैं जिन्हें उपयोगकर्ता ने शुरू किया है. कम पावर वाले डिवाइसों पर वेब को भरोसेमंद तरीके से काम करने के लिए, ब्राउज़र को सिस्टम के संसाधनों को पहले से ही वापस पाने और फिर से असाइन करने का तरीका चाहिए. साथ ही, सभी प्लैटफ़ॉर्म पर सामान्य तौर पर ज़्यादा संसाधन इस्तेमाल करने से बचना चाहिए.

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

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

Page Lifecycle API इस समस्या को हल करने की कोशिश करता है. इसके लिए, वह ये काम करता है:

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

इस समाधान से वेब डेवलपर को यह अनुमान लगाने में मदद मिलती है कि सिस्टम के इंटरवेंशन से ऐप्लिकेशन पर क्या असर पड़ेगा. इससे वे ऐसे ऐप्लिकेशन बना पाते हैं जो सिस्टम के इंटरवेंशन से सुरक्षित रहते हैं. साथ ही, इससे ब्राउज़र को सिस्टम के संसाधनों को ज़्यादा बेहतर तरीके से ऑप्टिमाइज़ करने में मदद मिलती है. इससे वेब का इस्तेमाल करने वाले सभी लोगों को फ़ायदा मिलता है.

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

पेज के लाइफ़साइकल की स्थितियों और इवेंट के बारे में खास जानकारी

पेज के लाइफ़साइकल की सभी स्थितियां अलग-अलग होती हैं और एक-दूसरे से जुड़ी नहीं होती हैं. इसका मतलब है कि कोई पेज एक समय में सिर्फ़ एक स्थिति में हो सकता है. साथ ही, पेज के लाइफ़साइकल की स्थिति में होने वाले ज़्यादातर बदलावों को आम तौर पर डीओएम इवेंट के ज़रिए देखा जा सकता है. अपवादों के लिए, हर स्थिति के लिए डेवलपर के सुझाव देखें.

पेज के लाइफ़साइकल की स्थितियों और उनके बीच ट्रांज़िशन का सिग्नल देने वाले इवेंट के बारे में बताने का सबसे आसान तरीका शायद यह डायग्राम है:

राज्य

यहां दी गई टेबल में, हर स्थिति के बारे में पूरी जानकारी दी गई है. इसमें उन संभावित स्थितियों की सूची भी दी गई है जो पहले और बाद में आ सकती हैं. साथ ही, इसमें उन इवेंट की सूची भी दी गई है जिनका इस्तेमाल डेवलपर, बदलावों को देखने के लिए कर सकते हैं.

इवेंट

ब्राउज़र कई इवेंट डिस्पैच करते हैं, लेकिन उनमें से सिर्फ़ कुछ ही इवेंट, पेज के लाइफ़साइकल की स्थिति में संभावित बदलाव का संकेत देते हैं. यहां दी गई टेबल में, लाइफ़साइकल से जुड़े सभी इवेंट के बारे में बताया गया है. साथ ही, यह भी बताया गया है कि ये इवेंट किन स्थितियों में ट्रांज़िशन कर सकते हैं.

* यह Page Lifecycle API से तय किया गया नया इवेंट है

Chrome 68 में जोड़ी गई नई सुविधाएं

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

Chrome 68 में, डेवलपर अब यह देख सकते हैं कि कोई छिपा हुआ टैब कब फ़्रीज़ होता है और कब अनफ़्रीज़ होता है. इसके लिए, उन्हें document पर freeze और resume इवेंट सुनने होंगे.

document.addEventListener('freeze', (event) => {
  // The page is now frozen.
});

document.addEventListener('resume', (event) => {
  // The page has been unfrozen.
});

Chrome 68 से, document ऑब्जेक्ट में अब डेस्कटॉप Chrome पर wasDiscarded प्रॉपर्टी शामिल है. Android पर इस सुविधा के काम करने से जुड़ी समस्या को ट्रैक किया जा रहा है. यह पता लगाने के लिए कि किसी पेज को छिपे हुए टैब में बंद करते समय खारिज किया गया था या नहीं, पेज लोड होने के समय इस प्रॉपर्टी की वैल्यू की जांच की जा सकती है. ध्यान दें: खारिज किए गए पेजों को फिर से इस्तेमाल करने के लिए, उन्हें फिर से लोड करना होगा.

if (document.wasDiscarded) {
  // Page was previously discarded by the browser while in a hidden tab.
}

freeze और resume इवेंट में किन चीज़ों का ध्यान रखना ज़रूरी है, इस बारे में सलाह पाने के लिए हर स्थिति के लिए डेवलपर के सुझाव देखें. साथ ही, यह भी जानें कि पेजों को खारिज किए जाने की स्थिति को कैसे मैनेज करें और इसके लिए तैयारी कैसे करें.

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

कोड में पेज के लाइफ़साइकल की स्थितियां देखने का तरीका

चालू, निष्क्रिय, और छिपी हुई स्थितियों में, JavaScript कोड को चलाया जा सकता है. यह कोड, मौजूदा वेब प्लैटफ़ॉर्म एपीआई से पेज के लाइफ़साइकल की मौजूदा स्थिति का पता लगाता है.

const getState = () => {
  if (document.visibilityState === 'hidden') {
    return 'hidden';
  }
  if (document.hasFocus()) {
    return 'active';
  }
  return 'passive';
};

दूसरी ओर, फ़्रीज़ और बंद किया गया स्टेटस का पता सिर्फ़ उनके इवेंट लिसनर (freeze और pagehide) में लगाया जा सकता है, क्योंकि स्टेटस बदल रहा होता है.

स्टेट में होने वाले बदलावों को मॉनिटर करने का तरीका

पहले से तय किए गए getState() फ़ंक्शन के आधार पर, यहां दिए गए कोड की मदद से पेज के लाइफ़साइकल की स्थिति में हुए सभी बदलावों को देखा जा सकता है.

// Stores the initial state using the `getState()` function (defined above).
let state = getState();

// Accepts a next state and, if there's been a state change, logs the
// change to the console. It also updates the `state` value defined above.
const logStateChange = (nextState) => {
  const prevState = state;
  if (nextState !== prevState) {
    console.log(`State change: ${prevState} >>> ${nextState}`);
    state = nextState;
  }
};

// Options used for all event listeners.
const opts = {capture: true};

// These lifecycle events can all use the same listener to observe state
// changes (they call the `getState()` function to determine the next state).
['pageshow', 'focus', 'blur', 'visibilitychange', 'resume'].forEach((type) => {
  window.addEventListener(type, () => logStateChange(getState()), opts);
});

// The next two listeners, on the other hand, can determine the next
// state from the event itself.
window.addEventListener('freeze', () => {
  // In the freeze event, the next state is always frozen.
  logStateChange('frozen');
}, opts);

window.addEventListener('pagehide', (event) => {
  // If the event's persisted property is `true` the page is about
  // to enter the back/forward cache, which is also in the frozen state.
  // If the event's persisted property is not `true` the page is
  // about to be unloaded.
  logStateChange(event.persisted ? 'frozen' : 'terminated');
}, opts);

यह कोड तीन काम करता है:

• getState() फ़ंक्शन का इस्तेमाल करके, शुरुआती स्थिति सेट करता है.
• यह एक ऐसे फ़ंक्शन को तय करता है जो अगली स्थिति को स्वीकार करता है. साथ ही, अगर कोई बदलाव होता है, तो स्थिति में हुए बदलावों को कंसोल में लॉग करता है.
• यह सभी ज़रूरी लाइफ़साइकल इवेंट के लिए, इवेंट लिसनर कैप्चर करता है. इसके बाद, यह logStateChange() को कॉल करता है और अगली स्थिति में पास होता है.

कोड के बारे में एक बात ध्यान देने वाली है कि सभी इवेंट लिसनर को window में जोड़ा जाता है और वे सभी {capture: true} पास करते हैं. ऐसा होने की कुछ वजहें होती हैं:

• सभी पेज लाइफ़साइकल इवेंट का टारगेट एक जैसा नहीं होता. pagehide और pageshow को window पर ट्रिगर किया जाता है; visibilitychange, freeze, और resume को document पर ट्रिगर किया जाता है. साथ ही, focus और blur को उनके DOM एलिमेंट पर ट्रिगर किया जाता है.
• इनमें से ज़्यादातर इवेंट बब्ल नहीं होते. इसका मतलब है कि किसी सामान्य पूर्वज एलिमेंट में, कैप्चर न करने वाले इवेंट लिसनर नहीं जोड़े जा सकते. साथ ही, उन सभी को मॉनिटर नहीं किया जा सकता.
• कैप्चर फ़ेज़, टारगेट या बबल फ़ेज़ से पहले लागू होता है. इसलिए, वहां लिसनर जोड़ने से यह पक्का करने में मदद मिलती है कि वे अन्य कोड से रद्द होने से पहले चलें.

हर स्थिति के लिए डेवलपर के सुझाव

डेवलपर के तौर पर, पेज के लाइफ़साइकल की स्थितियों को समझना और कोड में उन्हें मॉनिटर करने का तरीका जानना ज़रूरी है. ऐसा इसलिए, क्योंकि आपको किस तरह का काम करना चाहिए और किस तरह का काम नहीं करना चाहिए, यह काफ़ी हद तक इस बात पर निर्भर करता है कि आपका पेज किस स्थिति में है.

उदाहरण के लिए, अगर पेज छिपा हुआ है, तो उपयोगकर्ता को कुछ समय के लिए दिखने वाली सूचना दिखाना सही नहीं है. यह उदाहरण काफ़ी आसान है. हालांकि, ऐसे अन्य सुझाव भी हैं जो इतने आसान नहीं हैं, लेकिन उनके बारे में बताना ज़रूरी है.

हम आपको फिर से बता दें कि लाइफ़साइकल इवेंट के भरोसेमंद होने और उनके क्रम को सभी ब्राउज़र में एक जैसा लागू नहीं किया जाता है. इसलिए, टेबल में दिए गए सुझावों को आसानी से लागू करने के लिए, PageLifecycle.js का इस्तेमाल करें.

लाइफ़साइकल के पुराने एपीआई, जिनका इस्तेमाल नहीं करना चाहिए

जहां तक हो सके, इन इवेंट से बचें.

अनलोड इवेंट

कई डेवलपर, unload इवेंट को गारंटीड कॉलबैक के तौर पर मानते हैं. साथ ही, इसका इस्तेमाल सेशन के खत्म होने के सिग्नल के तौर पर करते हैं, ताकि स्थिति को सेव किया जा सके और आंकड़ों का डेटा भेजा जा सके. हालांकि, ऐसा करना बहुत भरोसेमंद नहीं है. खास तौर पर, मोबाइल पर! unload इवेंट, अनलोड होने की कई सामान्य स्थितियों में ट्रिगर नहीं होता. जैसे, मोबाइल पर टैब स्विचर से टैब बंद करना या ऐप्लिकेशन स्विचर से ब्राउज़र ऐप्लिकेशन बंद करना.

इसलिए, सेशन के खत्म होने का समय पता लगाने के लिए, visibilitychange इवेंट पर भरोसा करना हमेशा बेहतर होता है. साथ ही, ऐप्लिकेशन और उपयोगकर्ता के डेटा को सेव करने के लिए, आखिरी भरोसेमंद समय के तौर पर छिपी हुई स्थिति पर विचार करें.

इसके अलावा, रजिस्टर किए गए unload इवेंट हैंडलर (onunload या addEventListener() के ज़रिए) की मौजूदगी की वजह से, ब्राउज़र पेजों को बैक/फ़ॉरवर्ड कैश मेमोरी में नहीं रख पाते. इससे, पेजों को तेज़ी से वापस और आगे लोड करने में समस्या आती है.

सभी नए ब्राउज़र में, हमारा सुझाव है कि पेज अनलोड (यानी कि टर्मिनेटेड स्थिति) का पता लगाने के लिए, हमेशा pagehide इवेंट का इस्तेमाल करें. unload इवेंट का इस्तेमाल न करें. अगर आपको Internet Explorer के वर्शन 10 और इससे पुराने वर्शन के लिए सहायता देनी है, तो आपको pagehide इवेंट का पता लगाना चाहिए. साथ ही, अगर ब्राउज़र pagehide के साथ काम नहीं करता है, तो सिर्फ़ unload का इस्तेमाल करना चाहिए:

const terminationEvent = 'onpagehide' in self ? 'pagehide' : 'unload';

window.addEventListener(terminationEvent, (event) => {
  // Note: if the browser is able to cache the page, `event.persisted`
  // is `true`, and the state is frozen rather than terminated.
});

beforeunload इवेंट

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

beforeunload और unload के बीच एक अंतर यह है कि beforeunload का इस्तेमाल सही तरीके से किया जा सकता है. उदाहरण के लिए, जब आपको उपयोगकर्ता को यह चेतावनी देनी हो कि उसके बदलाव सेव नहीं किए गए हैं. अगर वह पेज को अनलोड करना जारी रखता है, तो उसके बदलाव मिट जाएंगे.

beforeunload का इस्तेमाल करने की कुछ मान्य वजहें हैं. इसलिए, हमारा सुझाव है कि आप beforeunload लिसनर सिर्फ़ तब जोड़ें, जब उपयोगकर्ता ने बदलाव सेव न किए हों. इसके बाद, बदलाव सेव होने पर उन्हें तुरंत हटा दें.

दूसरे शब्दों में कहें, तो ऐसा न करें. ऐसा इसलिए, क्योंकि यह बिना किसी शर्त के beforeunload लिसनर जोड़ता है:

addEventListener('beforeunload', (event) => {
  // A function that returns `true` if the page has unsaved changes.
  if (pageHasUnsavedChanges()) {
    event.preventDefault();

    // Legacy support for older browsers.
    event.returnValue = true;
  }
});

इसके बजाय, यह तरीका अपनाएं. इससे beforeunload लिसनर सिर्फ़ तब जुड़ता है, जब इसकी ज़रूरत होती है. साथ ही, जब इसकी ज़रूरत नहीं होती, तब यह हट जाता है:

const beforeUnloadListener = (event) => {
  event.preventDefault();

  // Legacy support for older browsers.
  event.returnValue = true;
};

// A function that adds a `beforeunload` listener if there are unsaved changes.
onPageHasUnsavedChanges(() => {
  addEventListener('beforeunload', beforeUnloadListener);
});

// A function that removes the `beforeunload` listener when the page's unsaved
// changes are resolved.
onAllChangesSaved(() => {
  removeEventListener('beforeunload', beforeUnloadListener);
});

अक्सर पूछे जाने वाले सवाल

"लोड हो रहा है" स्थिति क्यों नहीं है?

पेज लाइफ़साइकल एपीआई, अलग-अलग और एक-दूसरे से अलग स्टेट तय करता है. किसी पेज को चालू, बंद या छिपा हुआ मोड में लोड किया जा सकता है. साथ ही, लोड होने से पहले ही इसकी स्थिति बदली जा सकती है या इसे बंद किया जा सकता है. इसलिए, इस पैराडाइम में अलग से लोडिंग की स्थिति का कोई मतलब नहीं है.

मेरा पेज बैकग्राउंड में ज़रूरी काम करता है. इसे फ़्रीज़ या बंद होने से कैसे रोका जा सकता है?

कई मान्य वजहों से, वेब पेजों को बैकग्राउंड में चलते समय फ़्रीज़ नहीं किया जाना चाहिए. इसका सबसे सामान्य उदाहरण, संगीत चलाने वाला ऐप्लिकेशन है.

कुछ ऐसी स्थितियां भी होती हैं जिनमें Chrome के लिए किसी पेज को खारिज करना जोखिम भरा हो सकता है. जैसे, अगर उसमें उपयोगकर्ता के इनपुट वाला ऐसा फ़ॉर्म है जिसे सबमिट नहीं किया गया है या अगर उसमें ऐसा beforeunload हैंडलर है जो पेज के अनलोड होने पर चेतावनी देता है.

फ़िलहाल, Chrome पेजों को बंद करने के मामले में काफ़ी सतर्कता बरतेगा. वह ऐसा सिर्फ़ तब करेगा, जब उसे भरोसा होगा कि इससे उपयोगकर्ताओं पर कोई असर नहीं पड़ेगा. उदाहरण के लिए, जिन पेजों को छिपाए जाने के दौरान इनमें से कोई भी गतिविधि करते हुए देखा गया है उन्हें तब तक नहीं हटाया जाएगा, जब तक कि संसाधनों की उपलब्धता बहुत कम न हो:

• ऑडियो चलाना
• WebRTC का इस्तेमाल करना
• टेबल का टाइटल या फ़ेविकॉन अपडेट करना
• सूचनाएं दिखाना
• पुश नोटिफ़िकेशन भेजना

यह तय करने के लिए कि किसी टैब को सुरक्षित तरीके से फ़्रीज़ किया जा सकता है या नहीं, फ़िलहाल इस्तेमाल की जा रही सूची की सुविधाओं के बारे में जानने के लिए, Chrome में फ़्रीज़ करने और बंद करने के लिए अनुमानित तरीके देखें.

बैक/फ़ॉरवर्ड कैश मेमोरी क्या होती है?

बैक/फ़ॉरवर्ड कैश मेमोरी एक ऐसा शब्द है जिसका इस्तेमाल नेविगेशन ऑप्टिमाइज़ेशन के लिए किया जाता है. कुछ ब्राउज़र इस सुविधा को लागू करते हैं, ताकि पीछे और आगे जाने वाले बटन का इस्तेमाल तेज़ी से किया जा सके.

जब कोई उपयोगकर्ता किसी पेज से हटता है, तो ये ब्राउज़र उस पेज के वर्शन को फ़्रीज़ कर देते हैं. ऐसा इसलिए किया जाता है, ताकि अगर उपयोगकर्ता 'वापस जाएं' या 'आगे बढ़ें' बटन का इस्तेमाल करके वापस आता है, तो पेज को तुरंत फिर से शुरू किया जा सके. ध्यान रखें कि unload इवेंट हैंडलर जोड़ने से, इस ऑप्टिमाइज़ेशन को लागू नहीं किया जा सकता.

सभी मामलों में, यह फ़्रीज़िंग, ब्राउज़र के सीपीयू/बैटरी को बचाने के लिए की जाने वाली फ़्रीज़िंग की तरह ही काम करती है. इसलिए, इसे फ़्रीज़ लाइफ़साइकल की स्थिति का हिस्सा माना जाता है.

अगर फ़्रीज़ या बंद किए गए स्टेटस में एसिंक्रोनस एपीआई नहीं चलाए जा सकते, तो IndexedDB में डेटा कैसे सेव किया जा सकता है?

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

ज़्यादातर IndexedDB API, कॉलबैक पर आधारित होते हैं. हालांकि, IDBTransaction इंटरफ़ेस पर मौजूद commit() तरीके से, चालू लेन-देन पर कमिट प्रोसेस शुरू की जा सकती है. इसके लिए, यह ज़रूरी नहीं है कि बकाया अनुरोधों से इवेंट भेजे जाने का इंतज़ार किया जाए. इससे freeze या visibilitychange इवेंट लिसनर में IndexedDB डेटाबेस में डेटा सेव करने का एक भरोसेमंद तरीका मिलता है. ऐसा इसलिए, क्योंकि कमिट को तुरंत चलाया जाता है. इसे किसी अलग टास्क में नहीं रखा जाता.

फ़्रीज़ किए गए और खारिज किए गए ऐप्लिकेशन की जांच करना

यह जांचने के लिए कि फ़्रीज़ और खारिज किए गए टैब में आपका ऐप्लिकेशन कैसा काम करता है, chrome://discards पर जाएं. यहां आपको खुले हुए किसी भी टैब को फ़्रीज़ या खारिज करने का विकल्प मिलेगा.

इससे यह पक्का किया जा सकता है कि आपका पेज, freeze और resume इवेंट के साथ-साथ document.wasDiscarded फ़्लैग को भी सही तरीके से हैंडल करता है. ऐसा तब होता है, जब पेजों को खारिज करने के बाद फिर से लोड किया जाता है.

खास जानकारी

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

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