Esta regla se activa cuando PageSpeed ????Insights detecta que las respuestas de su servidor no contienen encabezados de almacenamiento en caché explícitos o que ciertos recursos están especificados para almacenarse en caché solo durante un corto período de tiempo.

El almacenamiento en caché del navegador de activos estáticos puede ahorrar tiempo a los usuarios si visitan su sitio varias veces. Los encabezados de caché deben aplicarse a todos los recursos estáticos almacenables en caché, no solo a un peque?o subconjunto de recursos estáticos (por ejemplo, imágenes). Los recursos almacenables en caché incluyen archivos JS y CSS, archivos de imagen y otros archivos de objetos binarios (archivos multimedia, archivos PDF, etc.). En general, HTML no es un recurso estático y no debe considerarse almacenable en caché de forma predeterminada. Debe considerar qué políticas de almacenamiento en caché se aplican al HTML de su sitio.

Habilite el almacenamiento en caché del navegador para su servidor. Los activos estáticos deben tener al menos una semana de validez de caché. Los activos de terceros, como anuncios o widgets, también deben tener una vida útil de caché de al menos un día. Para todos los recursos almacenables en caché, recomendamos la siguiente configuración:

• VoluntadVenceFijar una fecha en el futuro, al menos una semana y como máximo un a?o (solemos fijarVence, sin ajusteControl de caché: edad máxima, ya que el primero cuenta con un mayor apoyo). No lo establezca en una fecha de más de un a?o en el futuro, ya que esto viola las pautas RFC.
• Si sabe exactamente cuándo cambiará el recurso, puede establecer una fecha de vencimiento más corta. Sin embargo, si cree que es "probable que un recurso cambie" pero no sabe cuándo, debe establecer una fecha de vencimiento larga y utilizar la huella digital de URL (que se describe a continuación).

Estos encabezados se utilizan para especificar el período de tiempo durante el cual un navegador puede usar un recurso almacenado en caché sin buscar en el servidor web una versión más reciente del recurso. Estos encabezados de almacenamiento en caché son potentes y no tienen restricciones de aplicación. Una vez configurados estos encabezados y descargado el recurso, el navegador no emitirá ninguna solicitud GET para el recurso a menos que expire la fecha de vencimiento o se alcance el tiempo máximo, o que el usuario borre el caché.

Estos encabezados se pueden utilizar para especificar cómo el navegador debe determinar si los archivos utilizados para el almacenamiento en caché son los mismos. existirúltima modificaciónLa fecha se especifica en el encabezado y eletiqueta ETEn el encabezado se puede especificar cualquier valor que identifique de forma única el recurso (normalmente una versión de archivo o un hash de contenido).última modificaciónes un encabezado de almacenamiento en caché "más débil" porque los navegadores usan heurísticas para determinar si necesitan recuperar contenido del caché.

Estos encabezados permiten a los navegadores actualizar eficazmente sus recursos almacenados en caché realizando solicitudes GET condicionales cuando el usuario recarga explícitamente la página. Las solicitudes GET condicionales no devuelven una respuesta completa a menos que cambie el recurso en el lado del servidor, por lo que tienen menos latencia que las solicitudes GET completas.

Para todos los recursos almacenables en caché, especifique unVenceoEdad máxima del control de cachéy unúltima modificaciónoetiqueta ETmuy importante. No es necesario especificar tambiénVenceyControl de caché: edad máxima; o especificar ambosúltima modificaciónyetiqueta ET.

Para los recursos que cambian ocasionalmente, podemos dejar que el navegador almacene en caché el recurso correspondiente hasta que el recurso cambie en el servidor, y el servidor notifique al navegador que hay una nueva versión disponible en ese momento. Podemos hacer esto dándole a cada versión del recurso una URL única. Por ejemplo, supongamos que tenemos un recurso llamado "my_stylesheet.css". Podemos cambiar el nombre del archivo a "my_stylesheet_fingerprint.css". Cuando un recurso cambia, su huella digital cambia y la URL correspondiente cambia en consecuencia. Cambiar la URL obligará al navegador a volver a buscar el recurso. Con las huellas digitales, incluso podemos establecer fechas de vencimiento futuras para recursos que cambian con más frecuencia.

Un método común de toma de huellas digitales es utilizar un número hexadecimal de 128 bits que codifica un hash del contenido del archivo.

Otra estrategia es simplemente crear un nuevo directorio de versión para la nueva versión de la aplicación y colocar todos los recursos para cada versión en el directorio de versión. La desventaja de esto es que si el recurso no ha cambiado entre las versiones, su URL seguirá cambiando, lo que obligará a volver a descargarlo. El uso de hash de contenido no sufre este problema, pero este método es un poco más complicado.

?

Salvo que se indique lo contrario, el contenido de esta página tiene licencia bajo laLicencia Creative Commons Atribución 3.0y los ejemplos de código tienen licencia bajo laLicencia Apache 2.0Para más detalles, consulte nuestraPolíticas del sitio.