Cuándo se habla de velocidad de carga y rendimiento web, es muy común que se recomiende dejar que el cliente almacene en caché tanto como pueda y durante el máximo tiempo posible.

La cosa tiene su lógica: un recurso en caché estará disponible de forma instantánea, no hay nada que solicitar al servidor ni nada que descargar. El usuario lo quiere y lo tiene.

La caché client-side es controlada mediante cabeceras HTTP incluidas en la respuesta del servidor. Las cabeceras relacionadas con la caché se pueden dividir en dos grupos:

1. Cabeceras de caché propiamente dichas: expires y cache-control. Con cualquiera de ellas se dice al navegador durante cuánto tiempo un recurso descargado será válido. No es sólo que no lo tenga que descargar durante ese tiempo, es que ni siquiera tiene por qué solicitarlo de nuevo al servidor durante ese período.
2. Cabeceras de validación de respuesta: Last-modified y ETags. Con estas cabeceras, el cliente puede determinar, aún cuándo un recurso en caché haya caducado, si es necesario volver a descargarlo.

Imagina que a un archivo CSS le ponemos una caché válida de un año. Durante ese año, cada vez que el navegador se encuentre una referencia a ese archivo, va a utilizar la copia en local. Después de ese año, volverá a solicitarlo al servidor y, si las cabeceras de validación le dicen que el recurso sigue siendo el mismo que tiene, no lo descargará, utilizará la copia en local y volverá a renovar el período de caché. Si el recurso ha cambiado, descargará la nueva versión y a esta nueva descarga le aplicará el período de caché.


Hay que elegir una cabecera de cada grupo, una de tiempo de caché y una de validación, elegir dos de un mismo grupo es redundante e innecesario. Yo utilizo cache-control y ETags. Y cache-control lo establezco en no-cache, el por qué es lo que voy a intentar explicar en este post.

¿Cómo controlar que el usuario recibe los recursos actualizados?

Todo esto está muy bien para recursos estáticos: CSS, JS, imágenes y cualquier recurso de similar naturaleza estática que se os ocurra. Hay que tener muy claro que significa estático en este contexto, y significa sencillamente que son recursos que NUNCA cambian.

Pero no es del todo verdad. Estos recursos estáticos cambian. Pero tras el cambio, estrictamente hablando, ya son recursos diferentes y la URL de su localización debería igualmente cambiar. Por ejemplo, una imagen actualizada debe cambiar el nombre de su archivo, por ejemplo de imagen.webp a imagen-v2.webp, o un archivo CSS puede solicitarse con strings de versión (si trabajas con WordPress, acuérdate siempre de utilizar el parámetro de versión en wp_enqueue_script() y wp_enqueue_style()).

Si cambia la URL de solicitud, el navegador ya lo toma como lo qué es, algo nuevo. El ciclo de caché – validación comienza otra vez. Así que, a través del nombre y/o URL de los recursos estáticos, es fácil asegurarse que el usuario recibe lo último en todo momento.

¿Es estático un documento HTML?

Al contrario de lo que muchos puedan pensar, un documento HTML no es un recurso estático.

Pongamos un ejemplo muy sencillo para que se entienda. Puedes tener un artículo en un documento HTML que tenga insertada la imagen de nombre imagen.webp. Es necesario actualizar el artículo, la información que proporciona la imagen está desactualizada, así que insertas imagen-v2.webp. Puede incluso que elimines el antiguo archivo imagen.webp del servidor.

Si el HTML está en la caché del navegador, seguirá conteniendo la referencia al antiguo imagen.webp. Así de mal.

Es un ejemplo muy básico pero espero que se entienda por qué un documento HTML debe considerarse como un recurso dinámico no apto para almacenarse en caché. (Por supuesto hablando en un contexto general, puede que en contextos muy concretos un documento HTML se comporte de forma verdaderamente estática, pero eso, casos muy concretos).

A los que os veáis tentados a pensar que una caché corta, por ejemplo de 5 minutos, otorgaría algo de mejora para el usuario y que el mal sería menor, al menos de corta duración, olvidadlo. Yo no lo recomiendo en absoluto. ¿Qué parte de que un documento HTML es dinámico no habéis entendido?

Además, existen situaciones en las que, aún habiendo caducado la caché, el cliente puede mostrar una versión antigua del HTML al usuario. Lo sufrí en primera persona y fue muy frustrante leer como todo el mundo en Internet recomendaba cachear el HTML client-side y a la vez saber que algunos usuarios podrían estar viendo documentos caducados.

Trabajo en una web sobre ciencia dónde nos gusta ser muy exactos. Las actualizaciones de los artículos están a la orden del día y ser veraces es una prioridad. Que un usuario pueda perderse actualizaciones no es una opción viable. Motivo que vuelve a reforzar la idea: un documento HTML tiene naturaleza dinámica.

no-cache y ETags, una combinación perfecta

Si la posibilidad de que un usuario vea un HTML caducado no es viable, debemos asegurar que su cliente de navegación no lo guarda en caché:

<meta http-equiv="Cache-control" content="no-cache" />

Cache-Control: no-cache

Sin embargo, todavía hay espacio para optimizar la experiencia del usuario con los sistemas de validación, como los ETags, y evitar que tenga que descargar repetidamente un documento que sigue siendo el mismo y que no ha cambiado nada.

Con los ETags, la primera vez que el cliente solicita el HTML, el servidor se lo da, junto con un token de validación, un número único asociado al documento servido. Este token es el Entity Tag. Si cambia el documento, ese token cambia.

La segunda y siguientes veces que se solicite el mismo documento, como no hay nada de caché, el cliente vuelve a hacer la solicitud pero ahora envía el token de identificación que recibió antes. El servidor lo comprueba y, si es el mismo, responderá con un status 304 Not Modified. El cliente puede cerrar la conexión sin descargar de nuevo el HTML.

Se trata, por tanto, de la mejor forma de asegurarnos que nuestros usuarios siempre reciben el HTML actualizado, sin retrasos ni posibles versiones antiguas, a la vez que ofrecemos la mejor experiencia al usuario durante su sesión de navegación.

Esto mismo es aplicable a otros documentos de naturaleza similar; por ejemplo, archivos txt, XML, etc.

Esta sería la configuración de cabeceras, para mí y por ahora, idónea para este tipo de recursos (ejemplo para .htaccess):

<FilesMatch ".(html|htm|rtf|rtx|svg|svgz|txt|xsd|xsl|xml|HTML|HTM|RTF|RTX|SVG|SVGZ|TXT|XSD|XSL|XML)$">
    FileETag MTime Size
    <IfModule mod_headers.c>
        Header set Cache-Control "no-cache"
        Header unset Last-Modified
    </IfModule>
</FilesMatch>

Para documentos HTML que puedan contener información privada, sin embargo, se debería bloquear completamente el almacenamiento local aunque se pierda la capacidad de respuesta 304 Not Modified:

Header set Cache-Control "max-age=0, private, no-store, no-cache, must-revalidate"

Por último, os dejo con este documento de Google Developers dónde explican todo esto y otras muchas cosas interesantes: Almacenar HTTP en caché. Mas información sobre cache...