Memoria limitada y la pestaña que se recarga sola

El usuario abre tu aplicación, empieza a rellenar un formulario largo, cambia a la aplicación de correo para copiar un dato, vuelve, y se encuentra la página recargada desde cero con todo lo escrito perdido. No ha habido ningún error, nada ha fallado y no aparecerá nada en tu registro. El sistema necesitaba memoria, tu pestaña era la candidata más gorda, y la mató. Esto ocurre constantemente en móviles de gama baja y es invisible para prácticamente toda la instrumentación estándar.

Cuánta memoria hay de verdad

Un teléfono barato reciente tiene entre dos y cuatro gigabytes de memoria total. De ahí, el sistema operativo se lleva una parte importante, los servicios de fondo otra, y el resto se reparte entre las aplicaciones abiertas. Al proceso que dibuja tu pestaña le quedan, en la práctica, unos pocos cientos de megabytes antes de convertirse en candidato a morir.

Ese presupuesto se llena más deprisa de lo que la intuición sugiere:

La fila de la imagen merece énfasis porque es la que más sorprende. El tamaño en memoria de una imagen no tiene nada que ver con el tamaño del fichero. Un archivo de 800 kilobytes muy comprimido, al descodificarse, ocupa cuatro bytes por píxel: doce millones de píxeles son cuarenta y ocho megabytes de memoria viva mientras esté en pantalla. Una galería con seis imágenes de ese tamaño se come casi trescientos megabytes en un aparato que tenía unos cientos. Servir las imágenes al tamaño en el que se van a mostrar no es solo una optimización de descarga: es, en móvil, sobre todo una optimización de memoria.

Para saber dónde estás, measureUserAgentSpecificMemory() es la vía estándar y está tratada en medir memoria en producción. Lo que aporta esta lección es qué hacer con el número: en móvil, el umbral de preocupación es mucho más bajo de lo que parece razonable desde un portátil. Doscientos megabytes en un escritorio no son nada; doscientos megabytes en un móvil de dos gigabytes te ponen en la lista de candidatos.

La escalera de reacciones

El sistema no mata la pestaña de golpe. Hay una progresión, y cada escalón se puede detectar y aprovechar.

Uno: congelación en segundo plano. Con la página oculta un rato, el navegador congela el proceso: los temporizadores dejan de dispararse y la ejecución se detiene. En motores basados en Chromium hay eventos explícitos, freeze y resume, para enterarse. Es reversible y no se pierde nada.

Dos: descarte. El navegador destruye el proceso de la pestaña pero conserva su entrada en la lista, con el título y la URL. Cuando el usuario vuelve, se produce una navegación completa a esa URL: se recarga la página desde cero, el estado en memoria ha desaparecido, y document.wasDiscarded vale true.

Tres: el sistema mata el navegador entero. Ocurre en aparatos muy justos y con presión externa. Al volver, el navegador restaura las pestañas y todas se recargan.

Cuatro: agotamiento dentro de la pestaña. Tu propio código pide memoria y no hay. El proceso muere y el usuario ve una página de error del navegador o, en móvil, a menudo una recarga automática.

La detección de los dos primeros escalones es directa y cabe en pocas líneas:

// Restauracion tras un descarte.
if (document.wasDiscarded) {
  restaurarDesdeInstantanea();
}

// Congelacion y reanudacion, donde exista.
document.addEventListener('freeze', () => {
  guardarInstantanea();   // Ultima oportunidad garantizada.
});
document.addEventListener('resume', () => {
  // El proceso sobrevivio: no hace falta restaurar nada.
});

// Universal y el que de verdad importa.
document.addEventListener('visibilitychange', () => {
  if (document.visibilityState === 'hidden') guardarInstantanea();
});

La regla operativa que se deduce: el momento fiable para persistir estado es cuando la página pasa a oculta, no cuando se descarga. El evento de descarga no se dispara de forma fiable en móvil —el sistema mata el proceso sin avisar— y además tiene un efecto secundario grave, que veremos ahora.

Persistencia por instantáneas

El patrón que sobrevive a los cuatro escalones consiste en guardar una instantánea del estado que merece la pena conservar cada vez que la página se oculta, y restaurarla al arrancar si detectas que hubo descarte.

const CLAVE = 'instantanea-formulario';

function guardarInstantanea() {
  try {
    const estado = {
      version: 2,
      guardadoEn: Date.now(),
      ruta: location.pathname,
      campos: Object.fromEntries(
        new FormData(document.querySelector('#formulario')).entries()
      ),
      desplazamiento: window.scrollY,
    };
    // Sincrono a proposito: en este instante puede no haber otro despues.
    localStorage.setItem(CLAVE, JSON.stringify(estado));
  } catch {
    // Cuota llena o almacenamiento bloqueado: no es motivo para romper nada.
  }
}

function restaurarDesdeInstantanea() {
  let estado;
  try {
    estado = JSON.parse(localStorage.getItem(CLAVE) || 'null');
  } catch {
    return;
  }
  if (!estado || estado.version !== 2) return;
  if (estado.ruta !== location.pathname) return;
  // Mas de un dia: probablemente ya no interesa.
  if (Date.now() - estado.guardadoEn > 86400000) return;

  const formulario = document.querySelector('#formulario');
  for (const [nombre, valor] of Object.entries(estado.campos)) {
    const campo = formulario.elements[nombre];
    if (campo) campo.value = valor;
  }
  window.scrollTo(0, estado.desplazamiento);
  avisar('Hemos recuperado lo que estabas escribiendo.');
}

Cinco detalles que hacen que esto funcione en producción. El número de versión permite cambiar el formato sin romper a quien tenga una instantánea vieja. La escritura es síncrona porque en ese instante puede no haber un instante siguiente. Todo va envuelto en try porque el almacenamiento puede estar lleno o bloqueado por la configuración del usuario, y ninguna de las dos cosas justifica romper la página. La caducidad evita restaurar algo de hace un mes. Y el aviso al usuario es imprescindible: restaurar contenido en silencio confunde, porque nadie entiende por qué hay texto que no ha escrito ahora.

La caché de retroceso y por qué se pierde

Hay un mecanismo del navegador que evita muchas de estas recargas y que se desactiva por accidente con enorme frecuencia. La caché de retroceso guarda la página entera —memoria, estado de JavaScript, posición de desplazamiento— congelada al navegar fuera, y la restaura íntegra al volver atrás. Cuando funciona, la vuelta atrás es instantánea y no se pierde nada. Cuando no, se recarga todo.

Las cuatro causas más frecuentes de que no funcione:

Un escuchador de unload. Basta con registrarlo, aunque esté vacío, para que la página deje de ser elegible. Es la causa número uno, y suele venir de una biblioteca de analítica antigua. Sustituirlo por visibilitychange con estado oculto es estrictamente mejor: además de no romper la caché, se dispara de forma fiable en móvil, cosa que unload no hace.

Cache-Control: no-store en el documento. Excluye la página de esta caché. Si lo estás usando por costumbre en una página que no tiene datos sensibles, quítalo; para lo que probablemente querías, no-cache es suficiente, como se vio en qué se puede cachear en el borde.

Conexiones abiertas de ciertos tipos en el momento de navegar fuera, que impiden congelar la página limpiamente. Cerrarlas al ocultarse y reabrirlas al mostrarse resuelve las dos cosas a la vez.

Un beforeunload mal usado. Reduce la elegibilidad en algunos motores. Úsalo solo cuando de verdad haya cambios sin guardar, registrándolo y quitándolo dinámicamente, no de forma permanente.

Y la comprobación de que ha funcionado:

window.addEventListener('pageshow', (evento) => {
  if (evento.persisted) {
    // Ha vuelto de la cache de retroceso: no ha habido carga.
    // Refresca solo lo que caduca, como relojes o contadores.
    refrescarDatosVolatiles();
  }
});

Las herramientas de desarrollo de los navegadores basados en Chromium tienen un panel específico que prueba la elegibilidad y, cuando falla, dice exactamente qué motivo lo impidió. Es una de las comprobaciones con mejor relación entre esfuerzo y beneficio que existen: lleva dos minutos y a menudo devuelve una navegación instantánea que llevabas años perdiendo.