limpiar - Ayuda con el almacenamiento en caché agresivo de JavaScript

limpiar cache chrome javascript (10)

Me encontré con un problema en el que realizo cambios en algunos archivos JavaScript a los que se hace referencia en un archivo HTML, pero el navegador no los ve. Se mantiene en la copia almacenada en caché en el navegador, aunque el servidor web tenga una versión más nueva.

No hasta que obligo al navegador a borrar el caché, veo los cambios.

¿Es esta una configuración de servidor web? ¿Debo configurar mis archivos JavaScript para que nunca se almacenen en caché? He visto algunas técnicas interesantes en Google Web Toolkit, donde en realidad crean un nuevo nombre de archivo JavaScript cada vez que se realiza una actualización. Creo que esto es para evitar que los proxies y los navegadores mantengan versiones antiguas de los archivos JavaScript con los mismos nombres.

¿Hay una lista de mejores prácticas en algún lugar?

Se mantiene en la copia almacenada en caché en el navegador, aunque el servidor web tenga una versión más nueva.

Esto es probablemente debido a que los encabezados HTTP Expires / Cache-Control están configurados.

http://developer.yahoo.com/performance/rules.html#expires

Escribí sobre esto aquí:

http://www.codinghorror.com/blog/archives/000932.html

Esto no es un mal consejo, per se, pero puede causar grandes problemas si lo haces mal. En el IIS de Microsoft, por ejemplo, el encabezado Expires siempre está desactivado de manera predeterminada, probablemente por esa misma razón. Al configurar un encabezado Expires en los recursos HTTP, le está diciendo al cliente que nunca revise las nuevas versiones de ese recurso , al menos no hasta la fecha de caducidad en el encabezado Expira. Cuando digo nunca, lo digo en serio: el buscador ni siquiera pedirá una nueva versión; simplemente asumirá que su versión almacenada en caché está lista para continuar hasta que el cliente borre la caché, o la caché alcance la fecha de caducidad. Yahoo señala que cambian el nombre de archivo de estos recursos cuando los necesitan actualizados.
Lo único que está ahorrando aquí es el costo de que el cliente haga ping al servidor para obtener una nueva versión y obtener un encabezado 304 no modificado en el caso común de que el recurso no haya cambiado. Eso no es mucha sobrecarga ... a menos que seas Yahoo. Claro, si tiene un conjunto de imágenes o scripts que casi nunca cambian, definitivamente explote el caché del cliente y encienda el encabezado Cache-Control. El almacenamiento en caché es crítico para el rendimiento del navegador; cada desarrollador web debe tener una comprensión profunda de cómo funciona el almacenamiento en caché de HTTP. Pero solo úsela de forma quirúrgica y limitada para aquellas carpetas o archivos específicos que puedan beneficiarse. Para cualquier otra cosa, el riesgo supera el beneficio. Ciertamente, no es algo que desee activar como predeterminado general para todo su sitio web ... a menos que desee cambiar los nombres de los archivos cada vez que cambie el contenido.

¿Está su servidor web enviando los encabezados correctos para decirle al navegador que tiene una nueva versión? También agregué la fecha a la cadena de consulta antes. es decir, myscripts.js? date = 4/14/2008 12:45:03 (solo la fecha sería codificada)

@Darren El problema de almacenamiento en caché se ha producido tanto en IIS 6 como en Apache 2 de fábrica. No estoy seguro de si la resolución correcta es modificar los encabezados de respuesta HTTP, sino tomar la ruta de cambio de nombre que se describe en algunas de las respuestas aquí.

@Chris Buen consejo. Pensé que el enfoque de cadena de consulta era bueno, pero parece que es necesario un nombre único de archivo o directorio para cubrir todos los casos.

@Jason y Darren

~~IE6~~ trata cualquier cosa con una cadena de consulta como incableable. Debería encontrar otra forma de obtener el número de versión en la url, como un directorio falso:

<script src="/js/version/MyScript.js"/>

y simplemente elimine ese primer nivel de directorio después de js en el lado del servidor antes de cumplir con la solicitud.

EDITAR: Lo siento todo; es Squid, no IE6, que no guardará en caché con una cadena de consulta. Más información here .

Agregamos un número de compilación del producto al final de todo el Javascript (y CSS, etc.) como sigue:

<script src="MyScript.js?4.0.8243">

Los navegadores ignoran todo después del signo de interrogación, pero las actualizaciones provocan una nueva URL que significa recargar el caché.

Esto tiene el beneficio adicional de que puedes establecer encabezados HTTP que significan "nunca caché".

Algunas técnicas muy útiles here incluso si no está planeando usar powershell para automatizar la implementación.

Con cada versión, simplemente anteponemos un número entero monótonamente creciente a la ruta raíz de todos nuestros activos estáticos, lo que obliga al cliente a volver a cargar (hemos visto que el método de cadena de consulta se rompe en IE6 antes). Por ejemplo:

Versión 1: http://www.foo.com/1/js/foo.js
Versión 2: http://www.foo.com/2/js/foo.js

Requiere volver a establecer enlaces con cada versión, pero hemos creado una funcionalidad para cambiar automáticamente los enlaces en nuestras herramientas de implementación.

Una vez hecho esto, puede usar los encabezados Expires / Cache-Control que permiten al cliente almacenar en caché los recursos de JS "para siempre", ya que la ruta cambia con cada versión, que creo que es a lo que estaba llegando @JasonCohen.

Escribí una publicación de blog sobre cómo superamos este problema aquí:

Evitar problemas de almacenamiento en caché de hojas de estilo JavaScript y CSS en ASP.NET

Básicamente, durante el desarrollo puede agregar un número aleatorio a una cadena de consulta después del nombre de archivo de su archivo CSS. Cuando realiza una versión de lanzamiento, el código cambia a usar el número de revisión de su conjunto. Esto significa que en su entorno de producción, sus clientes pueden almacenar en caché la hoja de estilo, pero cada vez que lance una nueva versión del sitio, se verán obligados a volver a cargar el archivo.

Por lo que vale, vi el sitio deviantART , bastante grande, que sirve sus archivos JS como 54504.js. Acabo de comprobar y veo que ahora los sirven como v6core.css? -5855446573 v6core_jc.js? 4150339741 etc.

Si el problema de la cadena de consulta proviene del servidor, supongo que puede controlar eso más o menos.

También soy del método de simplemente cambiar el nombre de las cosas. Nunca falla, y es bastante fácil de hacer.