La caché que se invalida sola solo cuando algo realmente cambia
· 6 min
Un sitio funcionando como PWA tenía un service worker encargado de dos cosas: servir el shell de la aplicación (HTML, CSS, JS, íconos) directo desde la caché antes de intentar la red, y mantener los datos en JSON actualizados en segundo plano sin bloquear la respuesta. Funciona bien, hasta el día en que el sitio cambia y la caché necesita acompañar ese cambio.
La forma ingenua: un número que alguien tiene que recordar cambiar
La forma más común de hacer esto es nombrar la caché con una cadena de versión escrita a mano, incrementada en cada deploy. El riesgo queda escondido: si alguien olvida subir ese número en un cambio, el deploy sube CSS y JS nuevos, pero el service worker de cada usuario sigue reconociendo la caché antigua como válida y sirve exactamente los archivos de antes, indefinidamente. No falla de forma visible, el sitio simplemente parece "no haberse actualizado", y el síntoma aparece mucho después del deploy, lejos de cualquier log que señale la causa.
Sacar la memoria humana de la ecuación
La corrección fue dejar de escribir ese número a mano. El identificador de versión de la caché pasó a calcularse en el build: un hash SHA-256 del contenido final del CSS, del JS ya empaquetado y del sprite de íconos, truncado a un formato corto. Cualquier cambio real en esos archivos cambia el hash, lo que cambia el nombre de la caché, lo que hace que el paso de activación del service worker reconozca la caché antigua como obsoleta y la borre, sin exigir que nadie recuerde hacer nada.
Dos estrategias, una base en común
El shell de la aplicación usa cache-first con un respaldo de página offline; los datos en JSON usan stale-while-revalidate, sirviendo la versión en caché al instante mientras busca la actualizada en segundo plano. Las dos estrategias son distintas, pero dependen por completo de que el nombre de la caché sea confiable, corregir la versión corrigió la base sobre la que se construyeron ambas.
Resultado
Servir una versión obsoleta después de un deploy dejó de ser un riesgo que dependía de que alguien recordara un paso manual, pasó a ser estructuralmente imposible, porque ya no existe ningún número que olvidar actualizar.