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

Philip Walton

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

बैकग्राउंड

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

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

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

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

समस्या यह है कि डेवलपर के पास इस तरह की टेक्नोलॉजी के लिए तैयारी करने का कोई तरीका नहीं है करते हैं या आपको पता होता है कि वे किए जा रहे हैं. इसका मतलब है ब्राउज़र ऐसे होने चाहिए जो कंज़र्वेटिव या जोखिम भरे वेब पेज न हों.

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

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

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

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

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

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

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

राज्य

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

इवेंट

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

* यह पेज लाइफ़साइकल एपीआई के ज़रिए तय किए गए नए इवेंट के बारे में बताता है

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

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

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

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

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

Chrome 68 के document ऑब्जेक्ट में अब wasDiscarded प्रॉपर्टी को डेस्कटॉप Chrome पर अपडेट करें (इस समस्या में 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 इवेंट का पता लगाएं और unload का इस्तेमाल सिर्फ़ तब करें, जब ब्राउज़र काम न करे pagehide:

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.
    return (event.returnValue = true);
  }
});

इसके बजाय ऐसा करें (क्योंकि यह beforeunload लिसनर को सिर्फ़ तब जोड़ता है, जब यह ज़रूरी है, और लिंक न होने पर इसे हटा देता है):

const beforeUnloadListener = (event) => {
  event.preventDefault();
  
  // Legacy support for older browsers.
  return (event.returnValue = true);
};

// A function that invokes a callback when the page has unsaved changes.
onPageHasUnsavedChanges(() => {
  addEventListener('beforeunload', beforeUnloadListener);
});

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

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

"लोड हो रहा है" पेज क्यों नहीं दिख रहा है राज्य?

Page Lifecycle API की मदद से यह तय किया जाता है कि स्थितियां अलग-अलग होती हैं और अलग-अलग होती हैं. पेज को किसी भी ऐक्टिव, पैसिव या छिपी हुई स्थिति में लोड किया जा सकता है और क्योंकि उसके लोड होने से पहले ही स्थिति बदल सकती है—या उसे खत्म भी किया जा सकता है— इस उदाहरण में, कॉन्टेंट लोड होने की अलग-अलग स्थिति का कोई मतलब नहीं है.

मेरा पेज छिपाए जाने पर अहम काम करता है. इसे फ़्रीज़ होने या खारिज होने से कैसे रोका जा सकता है?

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

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

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

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

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

को दबाकर रखें बैक/फ़ॉरवर्ड कैश मेमोरी की सुविधा क्या है?

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

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

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

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

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

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

हालांकि, जिस कोड को आज काम करना है उसके लिए डेवलपर के पास दो विकल्प हैं:

• सेशन स्टोरेज का इस्तेमाल करें: सेशन स्टोरेज सिंक्रोनस होता है और पेज खारिज करने की प्रक्रिया में सेव रहता है.
• अपने सर्विस वर्कर से मिले IndexedDB का इस्तेमाल करना: सर्विस वर्कर, डेटा को इसमें स्टोर कर सकता है पेज को बंद या खारिज करने के बाद, IndexedDB. freeze में या pagehide इवेंट लिसनर आप इसके ज़रिए अपने सर्विस वर्कर को डेटा भेज सकते हैं postMessage(), और सर्विस वर्कर, डेटा को सेव कर सकता है.

अपने ऐप्लिकेशन को फ़्रीज़ और खारिज की गई स्थितियों में टेस्ट करना

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

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

खास जानकारी

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

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