evitar cache attribute javascript html css apache caching

javascript - cache - Almacenamiento en caché de archivos: ¿Cadena de consulta frente a Última modificación?



title html css (2)

TL; DR

¿Por qué tantos sitios web usan el método de "cadena de consulta", en lugar de dejar que el encabezado modificado por última vez haga su trabajo?

Al cambiar la cadena de consulta, se cambia la URL y se garantiza que el contenido esté "actualizado".

¿Debería desactivar el encabezado Last-modified y simplemente trabajar con strings de consulta?

No. Aunque esa es casi la respuesta correcta.

Hay tres estrategias básicas de almacenamiento en caché utilizadas en la web:

  • Sin almacenamiento en caché o almacenamiento en caché deshabilitado
  • Usar validación / solicitudes condicionales
  • Almacenamiento en caché para siempre

Para ilustrar los tres, considere la siguiente situación:

Un usuario accede a un sitio web por primera vez, carga diez páginas y se va. Cada página carga el mismo archivo css. Para cada una de las estrategias de almacenamiento en caché anteriores, ¿cuántas solicitudes se realizarían?

Sin almacenamiento en caché: 10 solicitudes

En este escenario, debe quedar claro que no hay nada más que influya en el resultado, 10 solicitudes para el archivo css resultarían en que se envíe al cliente (navegador) 10 veces.

Ventajas

  • Contenido siempre fresco
  • Sin esfuerzo / gestión requerida

Desventajas

  • Menos eficiente, el contenido siempre se transfiere

Solicitudes de validación: 10 solicitudes

Si se utiliza Last-Modified o Etag , también habrá 10 solicitudes. Sin embargo, 9 de ellos serán solo los encabezados y no se transferirá ningún cuerpo. Los clientes usan solicitudes condicionales para evitar volver a descargar algo que ya tiene. Tomemos por ejemplo el archivo css para este sitio.

La primera vez que se solicita el archivo, sucede lo siguiente:

$ curl -i http://cdn.sstatic.net/stackoverflow/all.css HTTP/1.1 200 OK Server: cloudflare-nginx Date: Mon, 12 May 2014 07:38:31 GMT Content-Type: text/css Connection: keep-alive Set-Cookie: __cfduid=d3fa9eddf76d614f83603a42f3e552f961399880311549; expires=Mon, 23-Dec-2019 23:50:00 GMT; path=/; domain=.sstatic.net; HttpOnly Cache-Control: public, max-age=604800 Last-Modified: Wed, 30 Apr 2014 22:09:37 GMT ETag: "8026e7dfc064cf1:0" Vary: Accept-Encoding CF-Cache-Status: HIT Expires: Mon, 19 May 2014 07:38:31 GMT CF-RAY: 1294f50b2d6b08de-CDG .avatar-change:hover{backgro.....Some KB of content

Una solicitud posterior para la misma URL se vería así:

$ curl -i -H "If-Modified-Since:Wed, 30 Apr 2014 22:09:37 GMT" http://cdn.sstatic.net/stackoverflow/all.css HTTP/1.1 304 Not Modified Server: cloudflare-nginx Date: Mon, 12 May 2014 07:40:11 GMT Content-Type: text/css Connection: keep-alive Set-Cookie: __cfduid=d0cc5afd385060dd8ba26265f0ebf40f81399880411024; expires=Mon, 23-Dec-2019 23:50:00 GMT; path=/; domain=.sstatic.net; HttpOnly Cache-Control: public, max-age=604800 Last-Modified: Wed, 30 Apr 2014 22:09:37 GMT ETag: "8026e7dfc064cf1:0" Vary: Accept-Encoding CF-Cache-Status: HIT Expires: Mon, 19 May 2014 07:40:11 GMT CF-RAY: 1294f778e75d04a3-CDG

Tenga en cuenta que no hay cuerpo, y la respuesta es un 304 No modificado . Esto le indica al cliente que el contenido que ya tiene (en la memoria caché local) para esa url aún está actualizado.

Eso no quiere decir que este es el escenario óptimo. El uso de herramientas como la pestaña de red de las herramientas de desarrollo de Chrome le permite ver exactamente cuánto tiempo y qué hace una solicitud:

Debido a que la respuesta no tiene cuerpo, el tiempo de respuesta será mucho menor porque hay menos datos para transferir. Pero todavía hay una respuesta. y todavía hay toda la sobrecarga de conexión al servidor remoto.

Ventajas

  • Contenido siempre fresco
  • Solo se envió una solicitud "Completa"
  • Nueve solicitudes son mucho más delgadas y solo contienen encabezados
  • Más eficiente

Desventajas

  • Aún emite el número máximo de solicitudes
  • Aún incurre en búsquedas DNS
  • Aún necesita establecer una conexión con el servidor remoto
  • No funciona sin conexión
  • Puede requerir la configuración del servidor

Almacenamiento en caché para siempre: 1 solicitud

Si no hay etags, no hay un último encabezado modificado y solo un encabezado caducado establecido en el futuro, solo el primer acceso a una url dará lugar a cualquier comunicación con el servidor remoto. Este es un conocido? mejor práctica para un mejor rendimiento frontend . Si este es el caso, para las solicitudes posteriores, un cliente leerá el contenido de su propia memoria caché y no se comunicará con el servidor remoto.

Esto tiene claras ventajas de rendimiento, que son especialmente importantes en dispositivos móviles donde la latencia puede ser significativa (por decirlo suavemente).

Ventajas

  • Más eficiente, el contenido solo se transfiere una vez

Desventajas

  • La URL debe cambiar para evitar que los visitantes existentes carguen versiones obsoletas en caché
  • Mayor esfuerzo para configurar / administrar

No use cadenas de consulta para el almacenamiento en memoria caché

Es para eludir el caché de un cliente que los sitios usen un argumento de consulta. Cuando el contenido cambia (o si se publica una nueva versión del sitio), el argumento de la consulta se modifica y, por lo tanto, se solicitará una nueva versión de ese archivo a medida que la URL haya cambiado. Esto es menos trabajo / más conveniente que renombrar el archivo cada vez que cambia, sin embargo no tiene problemas,

El uso de cadenas de consulta previene el caché de proxy , en la cita siguiente, el autor demuestra que una solicitud del navegador <-> servidor de caché proxy <-> no utiliza el caché de proxy:

Cargar mylogo.gif? V = 1.2 dos veces (borrar el caché entre ellos) da como resultado estos encabezados:

>> GET http://stevesouders.com/mylogo.gif?v=1.2 HTTP/1.1 << HTTP/1.0 200 OK << Date: Sat, 23 Aug 2008 00:19:34 GMT << Expires: Tue, 21 Aug 2018 00:19:34 GMT << X-Cache: MISS from someserver.com << X-Cache-Lookup: MISS from someserver.com >> GET http://stevesouders.com/mylogo.gif?v=1.2 HTTP/1.1 << HTTP/1.0 200 OK << Date: Sat, 23 Aug 2008 00:19:47 GMT << Expires: Tue, 21 Aug 2018 00:19:47 GMT << X-Cache: MISS from someserver.com << X-Cache-Lookup: MISS from someserver.com

Aquí está claro que la segunda respuesta no fue atendida por el proxy: los encabezados de respuesta de caché dicen MISS, los valores de Fecha y Vencimiento cambian, y el seguimiento del registro de acceso de stevesouders.com muestra dos hits.

Esto no debe tomarse a la ligera: cuando se accede a un sitio web físicamente ubicado al otro lado del mundo, los tiempos de respuesta pueden ser muy lentos. Obtener una respuesta de un servidor proxy ubicado a lo largo de la ruta puede significar la diferencia entre un sitio web utilizable o no: en el caso de los recursos almacenados en caché significa que la primera carga de una URL es lenta, en el caso de usar solicitudes de validación significa que todo el sitio será lento.

En cambio, los activos de control de versiones

La "mejor" solución es la de los archivos de control de versiones, de modo que siempre que el contenido cambie también lo haga la url. Normalmente eso se automatizaría como parte del proceso de compilación.

Sin embargo, un compromiso cercano a eso es implementar una regla de reescritura como

# ------------------------------------------------------------------------------ # | Filename-based cache busting | # ------------------------------------------------------------------------------ # If you''re not using a build process to manage your filename version revving, # you might want to consider enabling the following directives to route all # requests such as `/css/style.12345.css` to `/css/style.css`. # To understand why this is important and a better idea than `*.css?v231`, read: # http://stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring <IfModule mod_rewrite.c> RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.+)/.(/d+)/.(js|css|png|jpe?g|gif)$ $1.$3 [L] </IfModule>

De esta forma, el servidor procesa una solicitud de foo.123.css como foo.css ; tiene todas las ventajas de utilizar un parámetro de consulta para la prevención de almacenamiento en memoria caché, pero sin el problema de deshabilitar el almacenamiento en memoria caché de proxy.

Estaba bromeando con las formas de almacenar en caché los recursos de mi sitio web y noté que la mayoría de los sitios web eran similares a las cadenas de consulta de uso de minas para anular el almacenamiento en caché (por ejemplo: /css/style.css?v=124942823)

Después, noté que cada vez que guardaba mi archivo style.css, los encabezados modificados por última vez se "actualizaban", lo que hacía innecesaria la cadena de consulta.

Entonces me pregunto:

  • ¿Por qué tantos sitios web usan el método de "cadena de consulta", en lugar de dejar que el encabezado modificado por última vez haga su trabajo?
  • ¿Debería desactivar el encabezado Last-modified y simplemente trabajar con strings de consulta? (¿Hay alguna ventaja particular en esto?)

¡Gracias!

El encabezado Last-Modified se aplica de manera diferente en los navegadores, pero generalmente el navegador emitirá una solicitud GET condicional a la que el servidor debe responder si es necesario actualizar el caché. Por ejemplo, en Firefox ...

El encabezado de respuesta "Last-Modified" se puede usar como un validador débil. Se considera débil porque solo tiene una resolución de 1 segundo. Si el encabezado "Última modificación" está presente en una respuesta, el cliente puede emitir un encabezado de solicitud "If-Modified-Since" para validar el documento en caché.

Cuando se realiza una solicitud de validación, el servidor puede ignorar la solicitud de validación y la respuesta con un OK normal 200, o puede devolver 304 No modificado para indicarle al navegador que use su copia en caché. La última respuesta también puede incluir encabezados que actualizan el tiempo de caducidad del documento en caché.

Al establecer una marca de tiempo (o huella digital), le informa explícitamente al navegador cuándo necesita actualizar su caché y luego puede establecer tiempos de caducidad muy largos.

Puede valer la pena señalar que la documentación sobre la canalización de activos de rieles ( http://guides.rubyonrails.org/asset_pipeline.html ) cita 3 ventajas para la toma de huellas dactilares en lugar de una marca de tiempo de la cadena de consulta:

  • No todas las memorias caché almacenan de forma fiable el contenido donde el nombre del archivo solo difiere según los parámetros de consulta
  • El nombre del archivo puede cambiar entre nodos en entornos de varios servidores.
  • Demasiada invalidación de caché

Para obtener más detalles y mejores prácticas sobre el almacenamiento en caché: https://developers.google.com/speed/docs/best-practices/caching