Resumen

  • AppCache guardaba una aplicación web para abrirla sin conexión. La página apuntaba a un manifiesto con los archivos necesarios; cambiar un script o una imagen en el servidor no renovaba por sí solo la copia del navegador. Había que cambiar el manifiesto.
  • La descarga fallida de un solo recurso exigido podía cancelar toda la actualización y conservar la aplicación vieja. Chrome inició la retirada por defecto en 2020 y propuso service workers como otra forma de trabajo. El pequeño inventario había acabado decidiendo cuándo llegaba una versión al lector.

El servidor tenía la corrección; el navegador tenía ayer

El desarrollador arregla main.js. El archivo nuevo está en el servidor, pero quien abre la aplicación ve el fallo antiguo. En una aplicación gestionada por AppCache, el manual técnico de Google señalaba el motivo: sustituir un recurso incluido en la caché no provocaba una nueva descarga si el manifiesto seguía igual. Había que modificar ese documento, incluso mediante una línea de comentario que cambiase su versión, para que el navegador preparase otro conjunto.

La promesa de trabajar sin conexión se había convertido también en una regla de publicación. El navegador conservaba una copia útil de la aplicación cuando la red faltaba. El precio era que el arreglo recién subido quedaba fuera de aquella copia hasta que el manifiesto diera la orden. El pequeño fichero de texto hacía de interruptor de lanzamiento.

La lista que quería salvar una aplicación entera

La nota del W3C de mayo de 2008 explicó la idea original. Para leer correo, consultar un calendario o preparar trabajo sin red, un sitio necesitaba algo más confiable que esperar que la caché HTTP general hubiese guardado las piezas correctas. El elemento html podía incluir un atributo manifest que señalaba un archivo con tipo text/cache-manifest. Allí el autor enumeraba recursos para conservar y, mediante NETWORK:, peticiones que debían seguir acudiendo a la red.

El navegador recibía así una lista deliberada. También recibía la tarea de instalarla como un conjunto coherente. Google explicaba que, si el manifiesto o cualquiera de los recursos obligatorios no se descargaba, toda la actualización fallaba y el navegador seguía usando la caché anterior. Una página ya abierta tampoco adoptaba de inmediato la nueva copia tras una descarga correcta: había que recargarla.

La regla tenía una razón operativa. Una aplicación vieja pero completa podía funcionar mejor que una mezcla nueva con archivos ausentes. La misma regla castigaba dos olvidos comunes: reparar un archivo sin tocar el manifiesto, o tocar el manifiesto sin conseguir que todos los archivos enumerados estuvieran disponibles. «Se desplegó el arreglo» y «el lector ve el arreglo» dejaron de ser el mismo hecho.

Un inventario inmóvil y otro demasiado nervioso

Había una segunda trampa en el ritmo de actualización. El manifiesto que nunca cambiaba retenía recursos viejos. Un manifiesto que cambiaba a cada petición también podía bloquear la salida. El manual de Google describía dos comprobaciones durante la actualización: una al empezar y otra después de descargar los recursos. Si el documento cambiaba en medio, el navegador podía tener archivos de revisiones distintas y rechazar el conjunto para intentarlo más tarde.

Las secciones CACHE, NETWORK y FALLBACK repartían el tratamiento de cada ruta: conservar, solicitar a la red o mostrar un sustituto al fallar. Eso era una política de la aplicación escrita en pocas líneas. Un recurso ausente dejaba de ser un enlace roto aislado; podía impedir que entrara toda la versión nueva. El manifiesto tenía autoridad sobre la continuidad y sobre la frescura.

El mecanismo prefería mantener el lote anterior a instalar uno incompleto. Podía proteger el trabajo sin conexión y, al mismo tiempo, convertir una reparación urgente en una espera silenciosa. La diferencia la marcaban la disciplina de despliegue y la prueba en el navegador del usuario, no solo el estado del servidor.

Chrome retiró la puerta antigua

La guía de retirada de Chrome de 2020 anunció un calendario por fases. Chrome 85 quitó AppCache por defecto, con una extensión mediante prueba de origen para sitios que necesitaban tiempo. Los service workers ofrecían otra forma de preparar el uso sin conexión. La transición tenía una regla firme: una página controlada por un service worker en Chrome dejaba de usar AppCache. Un equipo no podía construir medio sistema nuevo y confiar en que la caché vieja completase lo que faltaba.

Había que decidir otra vez qué peticiones interceptar, qué archivos conservar y cómo llega una versión nueva a una pestaña ya abierta. Google advertía que su herramienta de migración reproducía parte del comportamiento anterior, pero no la interfaz window.applicationCache ni sus eventos. Se trataba de una migración de operación, no de cambiar una palabra en el código. El calendario de Chrome afectaba a Chrome; otros navegadores seguían sus propias decisiones.

AppCache había dado al lector una aplicación cuando desaparecía la conexión. También podía mantenerle una aplicación antigua cuando la conexión volvía y el servidor ya ofrecía una reparación. El manifiesto decidía qué versión estaba lista para salir; el navegador decidía cuándo esa versión quedaba instalada y visible.