API de Page Lifecycle

Philip Walton

En la actualidad, los navegadores modernos a veces suspenden las páginas o las descartan por completo cuando los recursos del sistema están limitados. En el futuro, los navegadores querrán hacer esto de forma proactiva para consumir menos energía y memoria. La API de Page Lifecycle proporciona hooks de ciclo de vida para que tus páginas puedan controlar de forma segura estas intervenciones del navegador sin afectar la experiencia del usuario. Consulta la API para ver si debes implementar estas funciones en tu aplicación.

Segundo plano

El ciclo de vida de las aplicaciones es una forma clave en la que los sistemas operativos modernos administran los recursos. En Android, iOS y versiones recientes de Windows, el SO puede iniciar y detener apps en cualquier momento. Esto permite a estas plataformas optimizar y reasignar los recursos donde más beneficien al usuario.

En la Web, históricamente, no ha existido ese ciclo de vida, y las apps se pueden mantener activas de forma indefinida. Con una gran cantidad de páginas web en ejecución, los recursos del sistema críticos, como la memoria, la CPU, la batería y la red, pueden tener una suscripción excesiva, lo que genera una mala experiencia del usuario final.

Si bien la plataforma web tiene desde hace mucho tiempo eventos relacionados con los estados del ciclo de vida, como load, unload y visibilitychange, estos eventos solo permiten que los desarrolladores respondan a los cambios de estado del ciclo de vida que inicia el usuario. Para que la Web funcione de manera confiable en dispositivos de baja potencia (y sea más consciente de los recursos en general en todas las plataformas), los navegadores necesitan una forma de recuperar y reasignar de forma proactiva los recursos del sistema.

De hecho, los navegadores actuales ya toman medidas activas para conservar recursos en las páginas de las pestañas en segundo plano, y muchos navegadores (en especial, Chrome) les gustaría hacer mucho más para reducir su huella de recursos general.

El problema es que los desarrolladores no tienen forma de prepararse para este tipo de intervenciones iniciadas por el sistema ni siquiera de saber que están sucediendo. Esto significa que los navegadores deben ser conservadores o correr el riesgo de dañar las páginas web.

La API de Page Lifecycle intenta resolver este problema de la siguiente manera:

• Presentamos y estandarizamos el concepto de estados del ciclo de vida en la Web.
• Definir estados nuevos iniciados por el sistema que permitan a los navegadores limitar los recursos que pueden consumir las pestañas ocultas o inactivas
• Crear APIs y eventos nuevos que permitan a los desarrolladores web responder a las transiciones hacia y desde estos nuevos estados iniciados por el sistema

Esta solución proporciona la previsibilidad que los desarrolladores web necesitan para compilar aplicaciones resistentes a las intervenciones del sistema y permite que los navegadores optimicen los recursos del sistema de manera más agresiva, lo que beneficia a todos los usuarios web.

En el resto de esta publicación, se presentarán las nuevas funciones del ciclo de vida de la página y se explorará cómo se relacionan con todos los estados y eventos existentes de la plataforma web. También te brindará recomendaciones y prácticas recomendadas para los tipos de trabajo que los desarrolladores deben (y no deben) realizar en cada estado.

Descripción general de los estados y eventos del ciclo de vida de la página

Todos los estados del ciclo de vida de la página son discretos y se excluyen mutuamente, lo que significa que una página solo puede estar en un estado a la vez. Además, la mayoría de los cambios en el estado del ciclo de vida de una página se pueden observar a través de eventos de DOM (consulta las recomendaciones para desarrolladores de cada estado para conocer las excepciones).

Quizás la forma más sencilla de explicar los estados del ciclo de vida de la página, así como los eventos que indican transiciones entre ellos, es con un diagrama:

Estados

En la siguiente tabla, se explica cada estado en detalle. También enumera los posibles estados que pueden ocurrir antes y después, así como los eventos que los desarrolladores pueden usar para observar los cambios.

Eventos

Los navegadores envían muchos eventos, pero solo una pequeña parte de ellos indica un posible cambio en el estado del ciclo de vida de la página. En la siguiente tabla, se describen todos los eventos que pertenecen al ciclo de vida y se enumeran los estados a los que pueden realizar la transición.

* Indica un evento nuevo definido por la API de Page Lifecycle.

Funciones nuevas agregadas en Chrome 68

En el gráfico anterior, se muestran dos estados que inicia el sistema en lugar de que los inicie el usuario: congelado y descartado. Como se mencionó anteriormente, los navegadores hoy en día, en ocasiones, inmovilizan y descartan pestañas ocultas (a su discreción), pero los desarrolladores no tienen forma de saber cuándo sucede esto.

En Chrome 68, los desarrolladores ahora pueden observar cuándo se inmoviliza y se desinmoviliza una pestaña oculta escuchando los eventos freeze y resume en document.

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

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

A partir de Chrome 68, el objeto document ahora incluye una propiedad wasDiscarded en Chrome para computadoras (se está haciendo un seguimiento de la compatibilidad con Android en este problema). Para determinar si se descartó una página mientras estaba en una pestaña oculta, puedes inspeccionar el valor de esta propiedad en el tiempo de carga de la página (nota: las páginas descartadas se deben volver a cargar para volver a usarlas).

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

Si deseas obtener sugerencias sobre qué es importante hacer en los eventos freeze y resume, así como cómo controlar y prepararte para que se descarten páginas, consulta las recomendaciones para desarrolladores para cada estado.

En las siguientes secciones, se ofrece una descripción general de cómo estas nuevas funciones se ajustan a los estados y eventos existentes de la plataforma web.

Cómo observar los estados del ciclo de vida de la página en el código

En los estados activo, pasivo y oculto, es posible ejecutar código JavaScript que determine el estado actual del ciclo de vida de la página desde las APIs de la plataforma web existentes.

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

Por otro lado, los estados congelado y finalizado solo se pueden detectar en sus respectivos objetos de escucha de eventos (freeze y pagehide) a medida que cambia el estado.

Cómo observar los cambios de estado

Con base en la función getState() definida anteriormente, puedes observar todos los cambios de estado del ciclo de vida de la página con el siguiente código.

// 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);

Este código realiza tres acciones:

• Establece el estado inicial con la función getState().
• Define una función que acepta un estado siguiente y, si hay un cambio, registra los cambios de estado en la consola.
• Agrega objetos de escucha de eventos de captura para todos los eventos de ciclo de vida necesarios, que a su vez llaman a logStateChange() y pasan el siguiente estado.

Una cosa que debes tener en cuenta sobre el código es que todos los objetos de escucha de eventos se agregan a window y todos pasan {capture: true}. Esto se debe a varios motivos:

• No todos los eventos del ciclo de vida de la página tienen el mismo objetivo. pagehide y pageshow se activan en window; visibilitychange, freeze y resume se activan en document, y focus y blur se activan en sus respectivos elementos DOM.
• La mayoría de estos eventos no se propagan, lo que significa que es imposible agregar objetos de escucha de eventos que no capturen a un elemento ancestro común y observarlos todos.
• La fase de captura se ejecuta antes que las fases de destino o de burbuja, por lo que agregar objetos de escucha allí ayuda a garantizar que se ejecuten antes de que otro código pueda cancelarlos.

Recomendaciones para desarrolladores para cada estado

Como desarrolladores, es importante comprender los estados del ciclo de vida de la página y saber cómo observarlos en el código, ya que el tipo de trabajo que debes (o no debes) realizar depende en gran medida del estado en el que se encuentra tu página.

Por ejemplo, no tiene sentido mostrarle una notificación transitoria al usuario si la página está en el estado oculto. Si bien este ejemplo es bastante obvio, hay otras recomendaciones que no lo son tanto y que vale la pena enumerar.

Una vez más, como la confiabilidad y el orden de los eventos del ciclo de vida no se implementan de manera coherente en todos los navegadores, la forma más fácil de seguir los consejos de la tabla es usar PageLifecycle.js.

APIs de ciclo de vida heredados que se deben evitar

Siempre que sea posible, se deben evitar los siguientes eventos.

El evento de descarga

Muchos desarrolladores tratan el evento unload como una devolución de llamada garantizada y la usan como un indicador de fin de sesión para guardar el estado y enviar datos de estadísticas, pero hacerlo es extremadamente poco confiable, en especial en dispositivos móviles. El evento unload no se activa en muchas situaciones de descarga típicas, como cerrar una pestaña desde el selector de pestañas en dispositivos móviles o cerrar la app del navegador desde el selector de apps.

Por este motivo, siempre es mejor confiar en el evento visibilitychange para determinar cuándo finaliza una sesión y considerar el estado oculto como el último momento confiable para guardar datos de usuarios y de apps.

Además, la sola presencia de un controlador de eventos unload registrado (a través de onunload o addEventListener()) puede impedir que los navegadores puedan colocar páginas en la memoria caché atrás/adelante para cargas más rápidas hacia atrás y hacia adelante.

En todos los navegadores modernos, se recomienda usar siempre el evento pagehide para detectar posibles descargas de páginas (también conocido como estado terminated) en lugar del evento unload. Si necesitas admitir Internet Explorer 10 y versiones anteriores, debes detectar el evento pagehide y usar solo unload si el navegador no admite 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.
});

El evento beforeunload

El evento beforeunload tiene un problema similar al evento unload, en el sentido de que, históricamente, la presencia de un evento beforeunload podría impedir que las páginas sean aptas para la memoria caché atrás/adelante. Los navegadores modernos no tienen esta restricción. Sin embargo, algunos navegadores, como precaución, no activarán el evento beforeunload cuando intenten colocar una página en la caché de atrás/adelante, lo que significa que el evento no es confiable como indicador de fin de sesión. Además, algunos navegadores (incluido Chrome) requieren una interacción del usuario en la página antes de permitir que se active el evento beforeunload, lo que afecta aún más su confiabilidad.

Una diferencia entre beforeunload y unload es que hay usos legítimos de beforeunload. Por ejemplo, cuando quieras advertirle al usuario que tiene cambios sin guardar que perderá si continúa descargando la página.

Dado que hay razones válidas para usar beforeunload, se recomienda que solo agregues objetos de escucha beforeunload cuando un usuario tenga cambios sin guardar y, luego, quitarlos inmediatamente después de que se guarden.

En otras palabras, no hagas lo siguiente (ya que agrega un objeto de escucha beforeunload de forma incondicional):

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);
  }
});

En su lugar, haz lo siguiente (ya que solo agrega el objeto de escucha beforeunload cuando es necesario y lo quita cuando no lo es):

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);
});

Preguntas frecuentes

¿Por qué no hay un estado "cargando"?

La API de Page Lifecycle define los estados como discretos y mutuamente excluyentes. Dado que una página se puede cargar en el estado activo, pasivo o oculto, y puede cambiar de estado (o incluso finalizarse) antes de que termine de cargarse, un estado de carga independiente no tiene sentido dentro de este paradigma.

Mi página realiza tareas importantes cuando está oculta. ¿Cómo puedo evitar que se congele o se descarte?

Existen muchos motivos legítimos por los que las páginas web no deben inmovilizarse mientras se ejecutan en el estado oculto. El ejemplo más obvio es una app que reproduce música.

También hay situaciones en las que sería riesgoso que Chrome descartara una página, como si contiene un formulario con una entrada del usuario no enviada o si tiene un controlador beforeunload que advierte cuando se descarga la página.

Por el momento, Chrome será conservador cuando descarte páginas y solo lo hará cuando tenga la seguridad de que no afectará a los usuarios. Por ejemplo, las páginas que se observaron haciendo alguna de las siguientes acciones mientras estaban en el estado oculto no se descartarán, a menos que se encuentren en restricciones de recursos extremas:

• Cómo reproducir audio
• Cómo usar WebRTC
• Actualiza el título o el favicon de la tabla
• Cómo mostrar alertas
• Envío de notificaciones push

Para conocer las funciones de la lista actuales que se usan para determinar si una pestaña se puede inhabilitar o descartar de forma segura, consulta Heuristics for Freezing & Discarding en Chrome.

¿Qué es la memoria caché atrás/adelante?

La memoria caché de atrás/adelante es un término que se usa para describir una optimización de navegación que implementan algunos navegadores y que hace que el uso de los botones atrás y adelante sea más rápido.

Cuando un usuario sale de una página, estos navegadores inmovilizan una versión de esa página para que se pueda reanudar rápidamente en caso de que el usuario vuelva a navegar con los botones Atrás o Adelante. Recuerda que agregar un controlador de eventos unload impide que esta optimización sea posible.

A todos los efectos, esta inmovilización es funcionalmente la misma que realizan los navegadores para conservar la CPU o la batería. Por esa razón, se considera parte del estado del ciclo de vida inmovilizado.

Si no puedo ejecutar APIs asíncronas en los estados suspendidos o cerrados, ¿cómo puedo guardar datos en IndexedDB?

En los estados suspendido y cerrado, las tareas que se pueden suspender en las colas de tareas de una página se suspenden, lo que significa que no se pueden usar de forma confiable las APIs asíncronas y basadas en devoluciones de llamada, como IndexedDB.

En el futuro, agregaremos un método commit() a los objetos IDBTransaction, lo que les dará a los desarrolladores una forma de realizar transacciones de solo escritura que no requieran devoluciones de llamada. En otras palabras, si el desarrollador solo escribe datos en IndexedDB y no realiza una transacción compleja que consta de operaciones de lectura y escritura, el método commit() podrá finalizar antes de que se suspendan las filas de tareas (suponiendo que la base de datos de IndexedDB ya está abierta).

Sin embargo, para el código que debe funcionar hoy, los desarrolladores tienen dos opciones:

• Usa el almacenamiento de sesión: El almacenamiento de sesión es síncrono y se conserva en todas las descartes de páginas.
• Usa IndexedDB desde tu servicio trabajador: Un servicio trabajador puede almacenar datos en IndexedDB después de que se haya cerrado o descartado la página. En el objeto de escucha de eventos freeze o pagehide, puedes enviar datos a tu service worker a través de postMessage(), y el service worker puede controlar el guardado de los datos.

Cómo probar tu app en los estados inmovilizado y descartado

Para probar cómo se comporta tu app en los estados inactivos y descartados, puedes visitar chrome://discards para inhabilitar o descartar cualquiera de tus pestañas abiertas.

Esto te permite asegurarte de que tu página controle correctamente los eventos freeze y resume, así como la marca document.wasDiscarded cuando se vuelvan a cargar las páginas después de un descarte.

Resumen

Los desarrolladores que quieran respetar los recursos del sistema de los dispositivos de sus usuarios deben compilar sus apps teniendo en cuenta los estados del ciclo de vida de la página. Es fundamental que las páginas web no consuman recursos del sistema excesivos en situaciones que el usuario no esperaría.

Cuantos más desarrolladores comiencen a implementar las nuevas APIs de ciclo de vida de la página, más seguro será para los navegadores inmovilizar y descartar las páginas que no se están usando. Esto significa que los navegadores consumirán menos recursos de memoria, CPU, batería y red, lo que es una ventaja para los usuarios.