Cambias un horario en el sitio, pero una persona sigue viendo la versión anterior. Puede existir una copia guardada en el navegador, en un servicio intermedio o dentro de la aplicación. La caché permite reutilizar recursos y puede mejorar la entrega, pero necesita reglas acordes con el contenido. No todo dato tolera la misma antigüedad. Antes de culpar a la publicación o pedir que todos borren su navegador, conviene identificar qué recurso está desactualizado, dónde se conserva y cómo debería reconocer el sistema que existe una versión nueva.
Identifica qué parte de la página quedó antigua
Separa texto, imágenes, estilos y datos cargados desde otros servicios. Una portada puede mostrar el horario nuevo con una imagen anterior, o una pantalla antigua consultar datos recientes. Registra la dirección, el momento de la revisión y el recurso concreto. Compara con una sesión nueva sin convertir esa prueba en la única solución. Si el problema afecta solo a quienes visitaron antes, esa diferencia es una pista. El equipo técnico necesita saber qué se esperaba ver y qué aparece realmente para localizar la capa responsable.
Ajusta la política a la frecuencia de cambio
MDN explica que la caché HTTP reutiliza respuestas y distingue copias privadas y compartidas. El negocio debería clasificar contenido según cuánto puede esperar una actualización. Un logotipo versionado puede conservarse de forma distinta a una disponibilidad o una información personalizada. No conviene desactivar toda reutilización por un incidente ni aplicar una duración larga a cualquier respuesta. Pide una justificación por tipo de recurso y una explicación de cómo se comprueba que sigue vigente. La política correcta depende del uso, no de una configuración universal copiada de otro proyecto.
Publica recursos que puedan identificarse por versión
Cuando cambia un archivo de estilos o una imagen importante, la forma de identificar su versión ayuda a evitar mezclas. El detalle técnico puede variar, pero el proceso de publicación debe asegurar que la página y sus recursos correspondan a la misma entrega. Pregunta qué ocurre si un visitante mantiene una pestaña abierta mientras se publica. Si se eliminan archivos anteriores demasiado pronto, esa pestaña podría pedir recursos que ya no existen. Considera una transición que conserve compatibilidad durante el uso normal, especialmente en aplicaciones con sesiones prolongadas.
Comprueba desde una visita nueva y otra existente
Después de publicar, revisa una sesión limpia y otra que haya cargado la versión previa. Prueba navegación interna y una recarga normal. Si existe una aplicación instalable, inclúyela porque puede añadir su propia capa de recursos guardados. Documenta cómo invalidar una copia administrada cuando sea necesario y quién puede hacerlo. Evita usar limpieza total como respuesta automática: primero identifica el contenido afectado. La meta es que las actualizaciones lleguen de forma predecible y que una incidencia pueda explicarse sin convertir al cliente en responsable del mantenimiento técnico.
DE LA LECTURA A LA ACCIÓN
Para aplicar hoy
- Localiza el recurso antiguo antes de modificar toda la configuración.
- Define antigüedad aceptable según el tipo de contenido.
- Verifica una visita nueva y una sesión que conserve la versión anterior.
Fuentes y referencias
Documentación para profundizar. Los ejemplos de esta guía son didácticos.