Tus clientes ven la versión antigua de la tienda: caché del navegador y versionado

Has corregido un fallo del diseño en el móvil, has comprobado que se ve bien y das el tema por cerrado. Al día siguiente un cliente te manda una captura con la página descuadrada, justo como estaba antes. Tú no consigues reproducirlo. No es que el cliente se equivoque: su navegador sigue usando la hoja de estilos antigua que guardó la última vez que visitó la tienda.

Es uno de los problemas más desconcertantes de mantener una tienda, porque a quien hace el cambio nunca le pasa. Vamos a ver por qué ocurre y cómo evitarlo.

Por qué el navegador guarda los ficheros

Para que las páginas carguen rápido, el navegador guarda una copia de los ficheros que no cambian a menudo: hojas de estilo, scripts, imágenes y fuentes. La siguiente vez que los necesita, usa su copia en lugar de pedirlos al servidor. Cuánto tiempo los guarda lo deciden las cabeceras de caché que envía el servidor con cada fichero.

Para una tienda, que esos ficheros se guarden mucho tiempo es bueno: menos peticiones, páginas más rápidas, menos carga en el servidor. El problema aparece cuando cambias uno de ellos y su dirección sigue siendo la misma. El navegador no tiene forma de saber que hay una versión nueva, y sigue usando la que tiene hasta que caduque.

Los síntomas

• Diseño descuadrado o a medias solo para algunos clientes.
• Un botón que no hace nada porque el HTML es nuevo pero el JavaScript es el viejo (o al revés).
• Errores de JavaScript en la consola que en tu navegador no aparecen.
• Quejas que desaparecen solas al cabo de unos días, cuando caducan las copias.
• El clásico «a mí me funciona» del desarrollador, que recarga con la caché vaciada.

No es solo el navegador

Entre tu servidor y el cliente puede haber varias capas que guardan copias:

• La caché de PrestaShop de ficheros combinados. Si tienes activada la opción de combinar, comprimir y cachear el CSS y el JS, la tienda sirve ficheros generados a partir de los tuyos. Si cambias un fichero fuente y no se regenera la versión combinada, nadie ve el cambio, ni siquiera tú.
• La caché de plantillas de Smarty, si has cambiado una plantilla.
• Una caché de página, en un módulo o en el servidor, que guarda el HTML con las direcciones antiguas.
• Una CDN o un proxy delante de la tienda, con su propia copia de los ficheros.
• El navegador de cada cliente.

Las cuatro primeras las controlas tú: vaciarlas forma parte de cualquier cambio de diseño. La última no: no puedes pedir a cada cliente que vacíe su caché.

La solución: que la dirección cambie cuando cambia el fichero

La técnica estándar se llama versionado (o cache busting). Consiste en que la dirección del fichero incluya algo que cambie cada vez que cambia su contenido. Por ejemplo, añadiendo un parámetro: custom.css?v=20 pasa a custom.css?v=21. Para el navegador es una dirección nueva, así que la descarga; y mientras no cambie, puede seguir guardándola todo el tiempo que quiera.

Hay varias formas de calcular esa marca:

• Por fecha de modificación del fichero. Automático: cada vez que guardas el fichero, cambia. Solo se descarga de nuevo lo que ha cambiado.
• Por huella del contenido. Igual de automático y más preciso, pero hay que calcularla.
• Un número de versión global que subes tú en cada despliegue. Se descarga todo de nuevo, aunque solo haya cambiado un fichero.

Cuando PrestaShop combina y comprime los ficheros, ya genera nombres nuevos para el fichero combinado al regenerarlo. Pero no todas las tiendas usan esa opción (a veces da problemas con el orden de carga de ciertos módulos) y no cubre los ficheros que se cargan sueltos.

Cuidado con las fechas en los despliegues

El versionado por fecha de modificación tiene una trampa: si subes los ficheros con una herramienta que conserva la fecha original (algunos programas de FTP, algunas formas de desplegar o de restaurar copias), el fichero cambia pero su fecha no, y la marca de versión sigue siendo la misma. En esos casos necesitas poder forzar una versión nueva a mano después de desplegar.

¿Y si acorto el tiempo de caché?

Es la tentación cuando el problema se repite: configurar el servidor para que el navegador guarde el CSS y el JS solo unos minutos, o que pregunte siempre si hay versión nueva. Funciona, pero lo pagas en cada visita: más peticiones, más espera en el móvil y más carga en el servidor, también para los ficheros que no cambian en meses. Con el versionado puedes hacer justo lo contrario: dejar tiempos de caché largos, que es lo que favorece la velocidad, porque cuando un fichero cambia su dirección también cambia.

Lo que sí conviene es que el HTML de las páginas no se guarde mucho tiempo en el navegador ni en capas intermedias, porque es él quien lleva las direcciones con la versión. Si el HTML antiguo sigue en caché, seguirá pidiendo los ficheros antiguos aunque estén versionados.

Qué hacer después de cada cambio de diseño

1. Vacía la caché de PrestaShop (plantillas y ficheros combinados) desde Parámetros avanzados → Rendimiento.
2. Si tienes caché de página o CDN, púrgalas.
3. Comprueba que las direcciones de los CSS y JS que has cambiado tienen una marca de versión nueva (en el código fuente de la página).
4. Prueba en un navegador en el que ya hubieras visitado la tienda antes del cambio, sin vaciar su caché: así lo ve un cliente real.
5. Prueba en el móvil, que suele tener copias más antiguas.

Cómo resolverlo en PrestaShop

Rekire Cache Buster añade una marca de versión (?v=) a cada fichero CSS y JS local del front, para que el navegador descargue el nuevo en cuanto cambia. Tiene dos modos: automático, con la versión sacada de la fecha de modificación de cada fichero, o manual, con un token único que cambias tú. Puedes activarlo para CSS, para JS o para los dos, y el botón Forzar recarga ahora obliga a todos los visitantes a descargar de nuevo el CSS y el JS tras un despliegue, que es lo que necesitas si tu forma de subir ficheros conserva sus fechas. No toca los ficheros servidos desde otro dominio o CDN, ni los que ya llevan su propia versión, y no combina ni comprime nada, así que no altera el orden de carga. Compatible con PrestaShop 1.7, 8 y 9.