¿Cuáles son las reglas duras y rápidas para el control de caché?

Confesión : los sitios que mantengo tienen diferentes reglas para el Control de caché, principalmente basadas en la configuración predeterminada del servidor, seguidas de recomendaciones de los complementos Page Speed & Y-Slow Firefox y la vista Recursos de red en Speed Tracer de Google . Cache-Control está configurado como privado / público dependiendo de lo que digan que hacer, los encabezados de ETag / Last-Modified solo se modifican si Y-Slow sugiere que hay algo mal y parece que Vary-Accept-Encoding es necesario cuando gzipea manualmente archivos para Amazon CloudFront.

Al leer el material sobre las diferentes opciones y lo que hacen, parece haber información contradictoria, reglas para proxies rotos y configuraciones de culto de carga . Cualquier información oficial proporcionada por las herramientas de análisis mencionadas anteriormente es bastante inaccesible ya que trata cada tema individualmente en lugar de una estrategia unificada (por lo que no hay referencias cruzadas de técnicas).

Por ejemplo, parece no tener sentido que las herramientas de análisis de velocidad califiquen un sitio con ETag como un sitio sin ellos si están destinados a ayudar con el almacenamiento en caché.

¿Cuáles son las reglas estrictas y rápidas para una estrategia de control de caché independiente de la plataforma?

EDITAR:

Un enlace a través del artículo de Jeff Atwood explica el almacenamiento en caché con una profundidad excelente.

Para el registro, aunque aquí están las reglas duras y rápidas:

Si el archivo se Comprime usando GZIP, etc. - use "cache-control: private" ya que un proxy puede devolver la versión comprimida a un cliente que no lo admite (la memoria caché del navegador contendrá los archivos marcados de esta manera). También recuerde incluir un "Vary: Accept-Encoding" para decir que es compresible.

Use Last-Modified junto con ETag : el uso de correas y brackets proporciona ambos validadores, mientras que ETag se basa en el contenido del archivo en lugar del tiempo de modificación solo, usando ambas cubiertas en todas las bases. NOTA: PageTest de AOL tiene un enfoque de carta blanca contra ETags por alguna razón. Si está utilizando Apache en más de un servidor para alojar el mismo contenido, elimine el inodo declarado implícitamente de ETags excluyéndolo de la directiva FileETag (es decir, "Tamaño de Fileimet MTime") a menos que esté realmente utilizando el mismo sistema de archivos en vivo.

Utilice "control de caché: público" siempre que pueda ; esto significa que los servidores proxy (y el caché del navegador) devolverán su contenido incluso si el resto de la página necesita autenticación HTTP, etc.

cache-control

— Metalshark
fuente

Respuestas:

Primero, no se deshaga del ETag como dice Yahoo, a menos que esté usando una granja / clúster de servidores. Mientras el mismo archivo siempre devuelva el mismo ETag cuando no ha cambiado, entonces es una directiva muy útil.

En cuanto a otros encabezados, las mejores prácticas de Yahoo sugieren establecer un Expiresencabezado en el futuro lejano para los archivos estáticos, Cache-Controlpara el contenido dinámico. Sin embargo, Cache-controlestá perfectamente bien para contenido estático (prácticamente no hay diferencia entre ellos).

Cuando cambie los archivos estáticos en caché, deberá cambiar el nombre del archivo o agregar un parámetro único al final, por ejemplo example.com/styles.css?v=2. Sin embargo, se prefiere cambiar el nombre de archivo real, como se señala en los comentarios a continuación.

Por cierto, puede editar las reglas de YSlow a su gusto, para eliminar la regla de Etag y agregar su propio dominio como CDN. Este artículo también es una buena lectura: los problemas de Yahoo no son tus problemas

— Cabra descontento
fuente

El ETag tenía sentido en Apache al hacer "FileETag MTime Size" en lugar del valor predeterminado que incluye el inodo (por FS no tan confiable) en Y-Slow. Sin embargo, las recomendaciones sobre las mejores prácticas de Yahoo son un poco confusas en comparación con las de Page Speed. Por ejemplo, dice que use Cache-Control solo en páginas dinámicas (como usted también sugiere), pero Google sugiere usar Cache-Control: público en CSS estático y Cache-Control: privado en archivos Amazon Cloudfront GZipped manualmente.

— Metalshark

Es difícil saber qué hacer con ese consejo para representantes. Google solo dice "Algunos representantes públicos tienen errores ..." pero no dice qué tan frecuente es esto. Se recomienda configurar el encabezado Vary: Accept-Encoding, consulte la parte inferior de code.google.com/speed/page-speed/docs/caching.html

— DisgruntledGoat

Agregar un parámetro de consulta deshabilita el almacenamiento en caché de ese archivo por completo en algunos navegadores. Por lo tanto, es posible que desee ir con el enfoque de "cambiar el nombre del archivo" en su lugar, comoexample.com/style_v2.css

— Evgeny

@Evgeny: ¿Qué navegadores? Escuché esto antes, pero nunca he visto un navegador que en realidad no almacena en caché el archivo (especialmente si tiene los encabezados correctos).

— DisgruntledGoat

@DisgruntledGoat en realidad, después de algunas excavaciones, parece que es una reliquia de la era http / 1.0 donde era parte de la especificación que en realidad dicho agente de usuario no debe almacenar en caché los activos que tienen cadenas de consulta. Por otro lado, code.google.com/speed/page-speed/docs/caching.html establece que son los proxies (squid <3.0) los que no almacenarán en caché los activos y, por lo tanto, se desaconseja el uso de cadenas de consulta para el almacenamiento en caché.

— Evgeny

Cambie los encabezados de solicitud de sus recursos para usar el almacenamiento en caché Para la mayoría de las personas, la forma de almacenamiento en caché ebable es agregar algún código a un archivo llamado .htaccess en su servidor / servidor web.

Esto significa ir al administrador de archivos (o donde quiera que vaya para agregar o cargar archivos) en su webhost.

El archivo .htaccess controla muchas cosas importantes para su sitio. Si no está familiarizado con el archivo .htaccess, lea mi artículo sobre cómo trabajar con .htaccess para saber cómo hacerlo antes de cambiarlo.

El siguiente código le dice a los navegadores qué almacenar en caché y cuánto tiempo "recordarlo". Debe agregarse a la parte superior de su archivo .htaccess.

## EXPIRES CACHING ##
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType text/html "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType text/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 1 month"
</IfModule>
## EXPIRES CACHING ##

Guarde el archivo .htaccess y luego actualice su página web.

Fuente:
https://varvy.com/pagespeed/leverage-browser-caching.html

— Nomib Nomib
fuente

Casi todos los ejemplos de ExpiresByTypedirectivas que veo incluyen el tipo mime text/x-javascript: ¿su servidor realmente responde con este tipo de contenido? (Un ejemplo de copia oculta / pegar IMO.)

— MrWhite