2012-01-05 8 views
7

Estaba buscando Chirpy para css/js minificar, comprimir, etc. Me di cuenta de que no soporte de almacenamiento en caché. No tiene ninguna lógica para el envío de encabezados caducados, etags, etc.¿Por qué y cómo los navegadores saben almacenar el contenido (html, css, js, etc.) cuando no se lo indica explícitamente

La ausencia de esta característica me hizo cuestionar si el contenido del almacenamiento en caché no es tan preocupante; YSlow! califica esto, así que estoy un poco confundido. Ahora estoy investigando el almacenamiento en caché y no puedo explicar por qué este archivo css, SuperFish.css, se está recuperando de la memoria caché.

  1. Visita http://www.weirdlover.com (desarrollador de Chirpy)

  2. mirada a la pista red inicial. Aviso, no hay encabezado de vencimiento para SuperFish.css.

    First pull

  3. vuelve a visitar la página e inspeccione la traza de red de nuevo. Ahora SuperFish.css se recupera de la memoria caché.

    Cached image

¿Por qué el SuperFish.css obtenidos del caché al volver a visitar la página? Esto sucede incluso cuando cierro todas las instancias de Chrome y luego vuelvo a visitar la página.

+0

Es por eso que usted ve los anuncios de compañías de navegación ... Toda la velocidad que muestran, en realidad proviene de estas técnicas de almacenamiento en caché solamente. Los desarrolladores de navegadores se han asegurado de que el almacenamiento en caché ocurra incluso si el servidor no lo dice. –

Respuesta

4

Esto parece estar dentro de la especificación HTTP.

13.4 Response Cacheability

A menos que específicamente limitada por una cache-control (sección 14.9) Directiva, un sistema de almacenamiento en caché siempre pueden almacenar una respuesta satisfactoria (véase la sección 13.8) como una entrada de caché, puede devolverla sin validación si es fresco

13.2.2 Heuristic Expiration

Desde los servidores de origen no siempre proporcionan explícita de expiración veces, los cachés HTTP típicamente asignan tiempos de caducidad heurística, empleando algoritmos que usan otros valores de encabezado (como el tiempo de Última modificación) para estimar un tiempo de caducidad plausible.

Parecería que no se proporciona un encabezado de control de caché, y dejando fuera el encabezado caduca, el cliente es libre de usar una heurística para generar una fecha de caducidad y luego almacena en caché la respuesta en función de eso.

La presencia de un etag no tiene ningún efecto sobre esto ya que el etag se usa para validar una entrada de caché expirada, y en este caso chrome considera que la entrada en caché es nueva (lo mismo aplica a last-modified), por lo tanto, aún no ha expirado.

El principio general es que si el servidor de origen se refiere a la frescura debe indicarlo explícitamente.

+0

Si alguien tiene curiosidad, la solicitud contiene un encabezado Cache-Control pero la respuesta no: los encabezados Cache-Control en las solicitudes HTTP les permiten a los clientes controlar cómo funcionan los cachés posteriores. En API como XMLHttpRequest, también se pueden usar para controlar cómo funciona el caché local (es decir, en el navegador). http://www.mnot.net/javascript/xmlhttprequest/cache.html –

+0

De hecho, traté de usar eso para mejorar el control de caché en el cliente solo para descubrir que la mayoría de los navegadores no admiten cosas como max-stale, o max- edad con un valor distinto de max-age = 0 –

0

En este caso (cuando el servidor no devuelve el encabezado Expires), el navegador debe realizar una solicitud HTTP con el encabezado If-Modified-Since, y si el servidor devuelve HTTP 304 No modificado, el navegador obtiene los datos del caché . Pero, como veo, en la actualidad los navegadores no hacen ninguna solicitud cuando los datos están en la caché. Creo que se comportan de esta manera para un mejor tiempo de respuesta.

Cuestiones relacionadas