Especificar caché de navegador

Esta regla se activa cuando PageSpeed Insights detecta que la respuesta de tu servidor no incluye cabeceras de caché explícitas o que se especifica que los recursos se almacenen en caché durante poco tiempo.

Información general

El almacenamiento en caché del navegador para recursos estáticos puede ahorrarle tiempo al usuario si este visita tu sitio en más de una ocasión. El almacenamiento en caché de las cabeceras debería aplicarse a todos los recursos estáticos que puedan almacenarse en caché, no solo a un pequeño conjunto (como imágenes). Entre los recursos que se pueden almacenar en caché se incluyen los archivos JS y CSS, archivos de imágenes y otros archivos de objetos binarios (archivos multimedia, archivos PDF, etc.). En general, el código HTML no es estático y no debería considerarse apto para almacenarse en caché de forma predeterminada. Debes tener en cuenta qué política de almacenamiento en caché sería la más adecuada para el código HTML de tu sitio.

Recomendaciones

Habilita el almacenamiento en caché del navegador en tu servidor. Los recursos estáticos deben tener un ciclo de vida en caché de al menos una semana. En cuanto a los recursos de terceros, como anuncios o widgets, deben tener un ciclo de vida en caché de al menos un día. Se recomienda la siguiente configuración para los recursos que se puedan almacenar en caché:

  • Establece el valor de Expires en una semana como mínimo y, preferiblemente, en un año como máximo. Nosotros preferimos Expires antes que Cache-Control: max-age porque su compatibilidad es mayor. No establezcas un máximo superior a un año, ya que infringiría las normas RFC.
  • Si sabes exactamente cuándo cambiará un recurso, puedes establecer una fecha de caducidad más cercana. Sin embargo, si crees que cambiará pronto, pero no sabes cuándo, deberías especificar una fecha de caducidad más lejana y marcar las URL con tu huella digital (véase más adelante).

Cabeceras Expires y Cache-Control: max-age

Sirven para especificar el periodo en el que el navegador puede utilizar el recurso en caché sin comprobar que haya una nueva versión disponible en el servidor web. Son cabeceras de caché prioritarias que se aplican de manera incondicional. Una vez que se establecen y el recurso se ha descargado, el navegador no enviará ninguna solicitud GET para obtener el recurso hasta que se alcance la fecha de caducidad o la edad máxima, o bien hasta que el usuario borre la memoria caché.

Cabeceras Last-Modifed y ETag

Sirven para especificar el modo en que el navegador determinará si los archivos están duplicados antes de almacenarlos en caché. En Last-Modified, debería incluirse una fecha; y en ETag, cualquier valor que identifique de forma única el recurso (normalmente, versiones de archivo o hashes de contenido). Last-Modified tiene poca prioridad como cabecera de caché, ya que el navegador aplica una heurística para determinar si debe obtener el elemento en caché o no.

Estas cabeceras permiten que el navegador actualice de manera eficiente sus recursos en caché mediante el envío de peticiones GET condicionales cuando el usuario vuelve a cargar la página intencionadamente. Las solicitudes GET condicionales no muestran todos los datos a menos que el recurso haya cambiado en el servidor y que, por lo tanto, tenga una latencia menor que los GET completos.

¿Qué cabeceras de caché debería usar?

Es importante especificar un valor para Expires o Cache-Control max-age, y otro para Last-Modified o ETag en todos los recursos que se puedan almacenar en caché. Es redundante especificar un valor tanto para Expires como para Cache-Control: max-age, o para las dos cabeceras Last-Modified y ETag.

Uso de la huella digital para URLs

En el caso de los recursos que cambian de vez en cuando, podemos hacer que el navegador almacene el recurso en caché hasta que cambie en el servidor. En ese momento, el servidor indicaría al navegador que hay una nueva versión disponible. Para ello, debemos asignar a cada versión del recurso una URL exclusiva. Por ejemplo, supongamos que tenemos un recurso llamado "my_stylesheet.css". Podríamos cambiar el nombre del archivo a "my_stylesheet_fingerprint.css". Cuando el recurso cambie, también lo hará la huella digital y, a su vez, la URL. En el momento en que cambie la URL, el navegador deberá obtener el recurso de nuevo. La huella digital nos permite establecer fechas de caducidad a largo plazo, incluso para recursos que cambian con más frecuencia que la indicada en la fecha.

Uno de los métodos más habituales de huella digital es utilizar un número hexadecimal de 128 bits que codifique el hash de los contenidos del archivo.

Otra estrategia consiste en crear un nuevo directorio para cada versión de la aplicación y, a continuación, poner todos los elementos de la versión en ese directorio. Esto tiene el inconveniente de que, si un elemento no cambia de una versión a otra, la URL cambiaría de todas maneras, y sería necesario volver a descargarlo. El uso de hashes de contenido no conlleva este problema, pero es un poco más complejo.