recommended página las htaccess expires evitar control contenido con cachear cache cabeceras age caching browser http-headers mod-expires

caching - página - http cache



Detener navegador para realizar solicitudes HTTP para imágenes que deben permanecer en caché-mod_expires (10)

Después de leer muchos artículos y algunas preguntas aquí, finalmente logré activar el mod_expires Apache para decirle al navegador que DEBE almacenar en caché las imágenes durante 1 año .

<filesMatch "/.(ico|gif|jpg|png)$"> ExpiresActive On ExpiresDefault "access plus 1 year" Header append Cache-Control "public" </filesMatch>

Y afortunadamente las respuestas del servidor parecen ser correctas:

HTTP/1.1 200 OK Date: Fri, 06 Apr 2012 19:25:30 GMT Server: Apache Last-Modified: Tue, 26 Jul 2011 18:50:14 GMT Accept-Ranges: bytes Content-Length: 24884 Cache-Control: max-age=31536000, public Expires: Sat, 06 Apr 2013 19:25:30 GMT Connection: close Content-Type: image/jpeg

Bueno, pensé que esto detendría la descarga del navegador e incluso consultaría al servidor sobre las imágenes durante 1 año. Pero es parcialmente cierto: porque si cierras y vuelves a abrir el navegador, el navegador NO descargará más las imágenes del servidor, pero el navegador aún indaga al servidor con una solicitud HTTP para cada imagen .

¿Cómo obligo al navegador a dejar de hacer solicitudes HTTP para cada imagen? Incluso si estas solicitudes HTTP no son seguidas por una imagen que se está descargando, ¡todavía son solicitudes hechas al servidor que aumentan la latencia sin precedentes y ralentizan la representación de la página!

¡Ya le dije al navegador que DEBE mantener las imágenes en caché durante 1 año! ¿Por qué el navegador sigue preguntando al servidor por cada imagen (incluso si no descarga la imagen)?

Mirando gráficos de red en FireBug (menú FireBug> Net> Imágenes) puedo ver diferentes comportamientos de caché (obviamente comencé con el caché del navegador completamente vacío, forcé una eliminación de caché en el navegador usando "Borrar todo el historial"):

  • Cuando la página se carga por primera vez, se descargan todas las imágenes (y sucede lo mismo si fuerzo la recarga de una página haciendo clic en el botón de la página de recarga del navegador). ¡Esto tiene sentido!

  • Cuando navego por el sitio y vuelvo a la misma página, las imágenes no se descargan del todo y el navegador NO pregunta al servidor por ninguna de las imágenes. Esto tiene sentido (¡y me gustaría ver este comportamiento también cuando el navegador está cerrado)!

  • Cuando cierro el navegador y lo vuelvo a abrir en la misma página, el tonto navegador hace de todos modos una solicitud HTTP al servidor una vez por imagen: NO degrada la imagen, pero aún hace una solicitud HTTP, es como si el navegador preguntara al servidor sobre la imagen (el servidor responde con 200 OK). ¡Este es el que me irrita!

También adjunto los gráficos a continuación si está interesado:

EDITAR: acaba de probar ahora también con FireFox 11.0 solo para asegurarme de que no era un problema que mi Firefox 3.6 fuera demasiado viejo. Lo mismo pasa !!! También probé el sitio de Google y el sitio Stackoverflow , ambos envían Cache-Control: max-age=... pero el navegador aún realiza una solicitud HTTP al servidor para cada imagen una vez que el navegador se cierra y se abre nuevamente en el mismo página , después de la respuesta del servidor, el navegador NO descarga la imagen (como expliqué anteriormente), pero todavía hace que la maldita solicitud que aumenta el tiempo para ver la página.

EDIT2: y eliminar el encabezado Last-Modified como se sugiere here , no resuelve el problema, no hace ninguna diferencia.

El comportamiento que está viendo es el previsto (ver RFC7234 para más detalles), comportamiento especificado:

Todos los navegadores modernos enviarán solicitudes HTTP al servidor por cada elemento de página que se muestre, independientemente del estado de la memoria caché. Esta fue una decisión de diseño realizada a pedido de los servicios web (especialmente las redes publicitarias) para garantizar que los servidores HTTP pudieran mantener registros de cada visualización de cada elemento.

Si los navegadores no hacen estas solicitudes, nunca se notificará al servidor que se ha mostrado una imagen al usuario. Para redes publicitarias, esto sería catastrófico. Desde el principio, las redes publicitarias ''piratearon'' su camino alrededor de esto al servir la misma imagen publicitaria usando nombres generados al azar (por ejemplo, ''coke_ad_1_98719283719283.gif''). Sin embargo, para los ISP esta práctica causó un gran aumento en las transferencias de datos, ya que cada uno de sus usuarios estaba volviendo a descargar estas imágenes de anuncios idénticos, pasando por alto cualquier servidor proxy / caché que su ISP estaba operando.

Así que se llegó a una tregua: los navegadores siempre enviarían solicitudes HTTP, incluso para elementos caché no caducados. Los servidores responderían con códigos de estado HTTP 304 ("no modificado"). Esto permite a los servidores registrar el hecho de que la imagen se mostró al cliente. Como resultado, las redes publicitarias generalmente dejaron de usar nombres de imágenes aleatorias para eludir los servidores de caché de red.

Esto le dio a las redes publicitarias lo que querían, un registro de cada imagen mostrada, y le dio a los ISP lo que querían: imágenes en caché y contenido estático.

Es por eso que no hay mucho que pueda hacer para evitar que los navegadores envíen solicitudes HTTP para elementos de página en caché.

Pero si observa otras soluciones disponibles del lado del cliente que vinieron con html5, existe un alcance para evitar la carga de recursos

  1. Caché Manifiesto (a pesar de sus errores)
  2. IndexedDB (buenas características asincrónicas, permite el almacenamiento de blobs)
  3. Almacenamiento local (no asincrónico)

Esta pregunta tiene una mejor respuesta https://webmasters.stackexchange.com/questions/25342/headers-to-prevent-304-if-modified-since-head-requests en webmasters stack-exchange site.

Más información, que también se cita en el enlace de arriba, está en httpwatch

De acuerdo con el artículo:

Hay una serie de situaciones en las que Internet Explorer necesita comprobar si una entrada almacenada en caché es válida:

  • La entrada en caché no tiene fecha de vencimiento y se está accediendo al contenido por primera vez en una sesión del navegador
  • La entrada almacenada en caché tiene una fecha de caducidad pero ha expirado

  • El usuario ha solicitado una actualización de página haciendo clic en el botón Actualizar o presionando F5

    Ingresa el código aquí

Estabas usando la herramienta incorrecta para analizar las solicitudes.

Recomiendo los encabezados HTTP Live Attaon realmente útiles para que pueda ver lo que realmente está sucediendo en la red.

Y para estar seguro, puede ssh / putty su servidor y hacer algo como

tail -f /var/log/apache2/access.log

Hay una diferencia entre "volver a cargar" y "refrescar". Simplemente navegar a una página con los botones Atrás y Adelante por lo general no inicia nuevas solicitudes HTTP, pero presionar F5 específicamente para "actualizar" la página hará que el navegador compruebe dos veces su caché. Esto depende del navegador pero parece ser la norma para FF y Chrome (es decir, los navegadores que tienen la capacidad de ver fácilmente el tráfico de red). Al presionar F6, ingrese debe enfocar la barra de dirección URL y luego "ir" a ella, que debería vuelva a cargar la página pero no vuelva a verificar los recursos en la página.

Actualización : aclaración del comportamiento de navegación de ida y vuelta. Se llama "Back Forward Cache" o BFCache en los navegadores. Cuando navega con los botones atrás / adelante, la intención es mostrarle exactamente como estaba la página cuando la vio en su propia línea de tiempo. No se realizan solicitudes al servidor cuando se utiliza el avance y el reenvío, incluso si el encabezado de la memoria caché del servidor indica que un elemento en particular expiró.

Si ve (200 OK BFCache) en su panel de red de desarrollador, entonces el servidor nunca fue golpeado, incluso para preguntar si-modificado-desde.

http://www.softwareishard.com/blog/firebug/firebug-tip-what-the-heck-is-bfcache/

Lo que describes aquí no refleja mi experiencia. Si el contenido se sirve con una directiva sin tienda o realiza una actualización explícita, entonces sí, esperaría que vuelva al servidor de origen; de lo contrario, debería almacenarse en caché en todos los reinicios del navegador (suponiendo que esté permitido y pueda escribir un archivo de caché).

Si observa sus cascadas con más detalle (lo cual es complicado porque son un poco pequeñas y borrosas), el navegador parece estar haciendo exactamente lo que debería ( tiene entradas para las imágenes), pero estas solo están cargando desde el caché local no desde el servidor de origen: verifique el encabezado ''Fecha'' en la respuesta (¿por qué cree que está tomando milisegundos en lugar de segundos?). Es por eso que están coloreados de manera diferente.

Lo que está viendo en Chrome no es un registro de las solicitudes HTTP reales, es un registro de solicitudes de activos. Chrome hace esto para mostrarle que la página está solicitando realmente un activo. Sin embargo, esta vista realmente no indica realmente si se está realizando la solicitud. Si un activo se almacena en caché, Chrome nunca creará la solicitud HTTP subyacente.

También puede confirmar esto al pasar el mouse sobre los segmentos morados en la línea de tiempo. Los recursos (from cache) en caché tendrán un (from cache) en la información sobre herramientas.

Para ver las solicitudes HTTP reales, debe buscar en un nivel inferior. En algunos navegadores, esto se puede hacer con un complemento (como los encabezados de Live HTTP).

Sin embargo, en realidad, para verificar que las solicitudes no se realicen realmente, debe verificar los registros de su servidor o usar un proxy de depuración como Charles o Fiddler. Esto funcionará en un nivel HTTP para asegurarse de que las solicitudes no estén realmente sucediendo.

Si forzo una actualización usando F5 o F5 + Ctrl, se envía una solicitud. Sin embargo, si cierro el navegador e ingreso la url nuevamente, NO se envía ningún requerimiento. La forma en que probé si se envía o no una solicitud fue mediante el uso de puntos de interrupción en la solicitud de inicio en el servidor, incluso cuando una solicitud no se envía, todavía aparece en Firebug como una espera de 7 ms, así que ten cuidado con esto.

Si se trata de una cuestión de vida o muerte (si desea optimizar la carga de la página de esta manera o si desea reducir la carga en el servidor tanto como sea posible, no importa qué), existe una solución alternativa.

Utilice el almacenamiento local HTML5 para almacenar en caché las imágenes después de que se solicitaron por primera vez.

  • [+] Puede evitar que el navegador envíe solicitudes HTTP, que en un 99% devolvería 304 (No modificado), sin importar cuánto lo intente el usuario (F5, ctrl + F5, simplemente revisando páginas, etc.)

  • [-] Tienes que poner algunos esfuerzos adicionales en soporte de JavaScript para esto.

  • [-] Las imágenes se almacenan en base64 (no podemos almacenar datos binarios), por eso se decodifican cada vez en el lado del cliente. Lo cual generalmente es bastante rápido y no es gran cosa, pero todavía hay algo de uso de CPU adicional en el lado del cliente y debe tenerse en cuenta.

  • [-] El almacenamiento local es limitado. Puede apuntar a usar ~ 5mb de datos por dominio (Nota: base64 agrega ~ 30% al tamaño original de la imagen).

  • [?] Compatible con la mayoría de los navegadores. http://caniuse.com/#search=localstorage

Example

Test

Validación de caché y la respuesta 304

Hay una serie de situaciones en las que Internet Explorer necesita comprobar si una entrada almacenada en caché es válida:

  • La entrada en caché no tiene fecha de vencimiento y se está accediendo al contenido por primera vez en una sesión del navegador

  • La entrada almacenada en caché tiene una fecha de caducidad pero ha expirado

  • El usuario ha solicitado una actualización de página haciendo clic en el botón Actualizar o presionando F5

Si la entrada en caché tiene una última fecha de modificación, IE lo envía en el encabezado If-Modified-Since de un mensaje de solicitud GET:

GET /images/logo.gif HTTP/1.1 Accept: */* Referer: http://www.google.com/ Accept-Encoding: gzip, deflate If-Modified-Since: Thu, 23 Sep 2004 17:42:04 GMT User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;) Host: www.google.com

El servidor comprueba el encabezado If-Modified-Since y responde en consecuencia. Si el contenido no se ha modificado desde la fecha / hora especificada, responde con un código de estado de 304 y un mensaje de respuesta que solo contiene encabezados:

HTTP/1.1 304 Not Modified Content-Type: text/html Server: GWS/2.1 Content-Length: 0 Date: Thu, 04 Oct 2004 12:00:00 GMT

La respuesta puede descargarse rápidamente porque no contiene contenido y hace que IE lea los datos que requiere de la memoria caché. En efecto, es como una redirección a la memoria caché del navegador local.

Si el objeto solicitado realmente ha cambiado desde la fecha / hora en el encabezado If-Modified-Since, el servidor responde con un código de estado de 200 y suministra la versión modificada del recurso.