Por qué no ves los cambios en tu web aunque ya los hayamos publicado

El jueves pasado un cliente que lleva una academia de idiomas online me llamó, casi enfadado, diciendo que llevaba tres días pidiéndonos que cambiásemos el precio de un curso en la web y que seguía viendo el número antiguo. Le pedí que hiciera Ctrl+Mayús+R en el navegador. Lo vio cambiado al instante. Colgó sin darme las gracias, cosa que entiendo perfectamente.

Si no ves los cambios en tu web nada más publicarlos, casi siempre es cuestión de caché: el navegador de quien visita la página, un proxy intermedio o nuestro propio servidor están sirviendo una copia guardada que todavía no sabe que existe una versión más nueva. El cambio lleva en el servidor desde el primer segundo, solo que nadie, entre el servidor y la pantalla, ha vuelto a pedirlo.

Hay dos cachés distintas metidas ahí, y la gente las mezcla, con razón, porque desde fuera se comportan igual: la web «no cambia». Está la del navegador de cada visitante, que no controlamos del todo pero sí podemos indicarle cuánto tiempo fiarse de un archivo. Y está la que sirve nuestro propio servidor antes de que la petición llegue a generar la página, que esa sí es enteramente cosa nuestra.

Los archivos con hash no dan ningún problema

Astro, al hacer el build, mete un hash del contenido en el nombre de cada archivo CSS y JS, algo como index.a3f9c2.css. Si cambia una coma del CSS, cambia el hash, cambia el nombre del archivo, y el navegador pide uno nuevo sin que nadie le diga nada. A esos archivos les decimos que se guarden durante un año entero (Cache-Control: public, max-age=31536000, immutable) y no pasa nada, porque si el contenido cambia también cambia el nombre. Ese truco nos ahorró bastantes llamadas cuando lo montamos, hace ya un par de años.

El problema de verdad está en el HTML, que no lleva hash en el nombre: sigue siendo /precios/index.html se actualice como se actualice el CSS que carga. Si le decimos al navegador o a nuestro nginx que lo guarde durante, pongamos, una hora, cualquier cambio de precio tarda hasta una hora en verse aunque el servidor lo tenga listo desde el segundo uno. Y una hora es mucho tiempo cuando quien llama es un cliente con un curso a medio vender.

Lo que cambiamos después de la enésima llamada

Después de varias llamadas parecidas a la de la academia de idiomas, dejamos de servir el HTML con caché larga. Ahora se sirve con no-cache, must-revalidate: el navegador tiene que preguntarle al servidor si hay algo nuevo cada vez, aunque guarde una copia local para no descargarla entera si no ha cambiado nada. Los archivos con hash siguen cacheados un año. Es la combinación que corre en el mismo VPS del que hablamos hace poco, con nginx sirviendo los estáticos delante de Docker, el mismo servidor al que le hicimos una auditoría de seguridad que nos dejó bastante menos tranquilos de lo que esperábamos.

Sigue habiendo un caso que no hemos resuelto del todo bien.

Cuando el cambio es en una imagen que no lleva hash (un logo, una foto de producto que el cliente nos manda con el mismo nombre de archivo de siempre), ahí sí recomendamos, sin mucho orgullo, lo de toda la vida: refrescar con Ctrl+Mayús+R o esperar un rato. Podríamos meter hash también en esas imágenes, pero complicaría el flujo con clientes que suben sus propias fotos por FTP, y de momento el coste no compensa el beneficio.

Lo que sí hemos aprendido es a no dar por hecho que «publicado» signifique «visible». Cuando entregamos un cambio urgente le avisamos al cliente, antes de que llame, de que puede tardar un poco en verse y por qué. Cuesta un minuto explicarlo y evita una llamada de las que empiezan con «esto no funciona» cuando en realidad sí funciona: solo que su navegador todavía no se ha enterado.