¿Cómo puedo forzar a los clientes a actualizar archivos JavaScript?

Actualmente estamos trabajando en una versión beta privada, por lo que todavía estamos en el proceso de realizar cambios bastante rápidos, aunque obviamente a medida que el uso comienza a aumentar, estaremos ralentizando este proceso. Dicho esto, un problema con el que nos estamos encontrando es que después de lanzar una actualización con nuevos archivos JavaScript, los navegadores del cliente aún usan la versión en caché del archivo y no ven la actualización. Obviamente, en una llamada de soporte, simplemente podemos informarles que realicen una ctrlF5actualización para garantizar que obtengan los archivos actualizados del servidor, pero sería preferible manejar esto antes de ese momento.

Nuestro pensamiento actual es simplemente adjuntar un número de versión al nombre de los archivos JavaScript y luego, cuando se realicen cambios, incremente la versión en el script y actualice todas las referencias. Esto definitivamente hace el trabajo, pero actualizar las referencias en cada versión podría ser engorroso.

Como estoy seguro de que no somos los primeros en lidiar con esto, pensé que lo tiraría a la comunidad. ¿Cómo se asegura de que los clientes actualicen su caché cuando actualiza su código? Si está utilizando el método descrito anteriormente, ¿está utilizando un proceso que simplifica el cambio?

Hasta donde yo sé, una solución común es agregar un ?<version>enlace src del script.

Por ejemplo:

<script type="text/javascript" src="myfile.js?1500"></script>

¿Asumo en este punto que no hay una mejor manera que encontrar-reemplazar para incrementar estos "números de versión" en todas las etiquetas de script?

¿Podría tener un sistema de control de versiones que lo haga por usted? La mayoría de los sistemas de control de versiones tienen una forma de inyectar automáticamente el número de revisión en el registro, por ejemplo.

Se vería algo así:

<script type="text/javascript" src="myfile.js?$$REVISION$$"></script>

Por supuesto, siempre hay mejores soluciones como esta .

Agregar la hora actual a la URL es de hecho una solución común. Sin embargo, también puede administrar esto en el nivel del servidor web, si lo desea. El servidor se puede configurar para enviar diferentes encabezados HTTP para archivos javascript.

Por ejemplo, para forzar el almacenamiento en caché del archivo por no más de 1 día, debe enviar:

Cache-Control: max-age=86400, must-revalidate

Para la versión beta, si desea obligar al usuario a obtener siempre la última versión, usaría:

Cache-Control: no-cache, must-revalidate

Velocidad de página de Google: no incluya una cadena de consulta en la URL para recursos estáticos. La mayoría de los servidores proxy, especialmente Squid hasta la versión 3.0, no almacenan en caché los recursos con un "?" en su URL incluso si un encabezado público de control de caché está presente en la respuesta. Para habilitar el almacenamiento en caché del proxy para estos recursos, elimine las cadenas de consulta de las referencias a los recursos estáticos y, en su lugar, codifique los parámetros en los propios nombres de archivo.

En este caso, puede incluir la versión en la URL, por ejemplo: http://abc.com/ v1.2 /script.js y usar apache mod_rewrite para redirigir el enlace a http://abc.com/script.js . Cuando cambie la versión, el navegador del cliente actualizará el nuevo archivo.

Este uso ha quedado en desuso: https://developer.mozilla.org/en-US/docs/Web/HTML/Using_the_application_cache

Esta respuesta tiene solo 6 años de retraso, pero no veo esta respuesta en muchos lugares ... HTML5 ha introducido Application Cache que se utiliza para resolver este problema. Estaba descubriendo que el nuevo código de servidor que estaba escribiendo estaba bloqueando el antiguo JavaScript almacenado en los navegadores de las personas, por lo que quería encontrar una manera de expirar su JavaScript. Use un archivo de manifiesto que se vea así:

CACHE MANIFEST
# Aug 14, 2014
/mycode.js

NETWORK:
*

y genere este archivo con una nueva marca de tiempo cada vez que desee que los usuarios actualicen su caché. Como nota al margen, si agrega esto, el navegador no se volverá a cargar (incluso cuando un usuario actualice la página) hasta que el manifiesto se lo indique.

¿Qué tal agregar el tamaño del archivo como parámetro de carga?

<script type='text/javascript' src='path/to/file/mylibrary.js?filever=<?=filesize('path/to/file/mylibrary.js')?>'></script>

Entonces, cada vez que actualiza el archivo, el parámetro "filever" cambia.

¿Qué tal cuando actualiza el archivo y sus resultados de actualización en el mismo tamaño de archivo? ¿Cuáles son las probabilidades?

No todos los navegadores almacenan archivos en caché con '?' en eso. Lo que hice para asegurarme de que estaba en caché tanto como fue posible, incluí la versión en el nombre del archivo.

Así que en lugar de stuff.js?123hacerlostuff_123.js

Solía mod_redirect(creo) en apache have stuff_*.jspara irstuff.js

Para las páginas ASP.NET estoy usando lo siguiente

ANTES DE

<script src="/Scripts/pages/common.js" type="text/javascript"></script>

DESPUÉS (fuerza de recarga)

<script src="/Scripts/pages/common.js?ver<%=DateTime.Now.Ticks.ToString()%>" type="text/javascript"></script>

Agregar DateTime.Now.Ticks funciona muy bien.

Para ASP.NET, supongo que la próxima solución con opciones avanzadas (modo de depuración / liberación, versiones):

Archivos Js o Css incluidos de esta manera:

<script type="text/javascript" src="Scripts/exampleScript<%=Global.JsPostfix%>" />
<link rel="stylesheet" type="text/css" href="Css/exampleCss<%=Global.CssPostfix%>" />

Global.JsPostfix y Global.CssPostfix se calcula de la siguiente manera en Global.asax:

protected void Application_Start(object sender, EventArgs e)
{
    ...
    string jsVersion = ConfigurationManager.AppSettings["JsVersion"];
    bool updateEveryAppStart = Convert.ToBoolean(ConfigurationManager.AppSettings["UpdateJsEveryAppStart"]);
    int buildNumber = System.Reflection.Assembly.GetExecutingAssembly().GetName().Version.Revision;
    JsPostfix = "";
#if !DEBUG
    JsPostfix += ".min";
#endif      
    JsPostfix += ".js?" + jsVersion + "_" + buildNumber;
    if (updateEveryAppStart)
    {
        Random rand = new Random();
        JsPosfix += "_" + rand.Next();
    }
    ...
}

La práctica común hoy en día es generar un código hash de contenido como parte del nombre del archivo para obligar al navegador, especialmente IE, a recargar los archivos javascript o css.

Por ejemplo,

vendedor. a7561fb0e9a071baadb9 .js
main. b746e3eb72875af2caa9 .js

Generalmente es el trabajo de las herramientas de compilación como webpack. Aquí hay más detalles si alguien quiere probar si está usando webpack.

Si está generando la página que enlaza con los archivos JS, una solución simple es agregar la marca de tiempo de la última modificación del archivo a los enlaces generados.

Esto es muy similar a la respuesta de Huppie, pero funciona en sistemas de control de versiones sin sustitución de palabras clave. También es mejor que agregar la hora actual, ya que eso evitaría el almacenamiento en caché incluso cuando el archivo no cambiara en absoluto.

La función jQuery getScript también se puede utilizar para garantizar que se cargue un archivo js cada vez que se carga la página.

Así es como lo hice:

$(document).ready(function(){
    $.getScript("../data/playlist.js", function(data, textStatus, jqxhr){
         startProgram();
    });
});

Verifique la función en http://api.jquery.com/jQuery.getScript/

Por defecto, $ .getScript () establece la configuración de caché en falso. Esto agrega un parámetro de consulta con marca de tiempo a la URL de solicitud para garantizar que el navegador descargue el script cada vez que se solicite.

En PHP :

function latest_version($file_name){
    echo $file_name."?".filemtime($_SERVER['DOCUMENT_ROOT'] .$file_name);
}

En HTML :

<script type="text/javascript" src="<?php latest_version('/a-o/javascript/almanacka.js'); ?>">< /script>

Cómo funciona:

En HTML, escriba el filepathnombre y el nombre como lo haría, pero solo en la función. PHP obtiene el filetimearchivo y devuelve el filepath+name+"?"+timeúltimo cambio

Hemos estado creando un SaaS para los usuarios y proporcionándoles un script para adjuntar en la página de su sitio web, y no fue posible adjuntar una versión con el script ya que el usuario adjuntará el script a su sitio web para funcionalidades y no puedo forzarlos para cambiar la versión cada vez que actualizamos el script

Entonces, encontramos una manera de cargar la versión más nueva del script cada vez que el usuario llama al script original

el enlace del script proporcionado al usuario

<script src="https://thesaasdomain.com/somejsfile.js" data-ut="user_token"></script>

el archivo de script

if($('script[src^="https://thesaasdomain.com/somejsfile.js?"]').length !== 0) {
   init();
} else {
   loadScript("https://thesaasdomain.com/somejsfile.js?" + guid());
}

var loadscript = function(scriptURL) {
   var head = document.getElementsByTagName('head')[0];
   var script = document.createElement('script');
   script.type = 'text/javascript';
   script.src = scriptURL;
   head.appendChild(script);
}

var guid = function() {
    return 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx'.replace(/[xy]/g, function(c) {
        var r = Math.random() * 16 | 0, v = c == 'x' ? r : (r & 0x3 | 0x8);
        return v.toString(16);
    });
}

var init = function() {
    // our main code
}

Explicación:

El usuario ha adjuntado el script que se le proporcionó en su sitio web y verificamos si el token único adjunto con el script existe o no utilizando el selector jQuery y, de lo contrario, lo cargamos dinámicamente con un token (o versión) más nuevo

Esto se llama el mismo script dos veces, lo que podría ser un problema de rendimiento, pero realmente resuelve el problema de obligar al script a no cargarse de la memoria caché sin poner la versión en el enlace del script real dado al usuario o cliente

Descargo de responsabilidad: no lo use si el rendimiento es un gran problema en su caso.

En asp.net mvc puede usar @ DateTime.UtcNow.ToString () para el número de versión del archivo js. El número de versión cambia automáticamente con la fecha y obliga al navegador del cliente a actualizar automáticamente el archivo js. Estoy usando este método y esto funciona bien.

<script src="~/JsFilePath/[email protected]()"></script>

location.reload (verdadero);

ver https://www.w3schools.com/jsref/met_loc_reload.asp

Llamo dinámicamente a esta línea de código para asegurarme de que javascript se haya recuperado del servidor web en lugar de la memoria caché del navegador para evitar este problema.

Una solución es agregar una cadena de consulta con una marca de tiempo a la URL al recuperar el recurso. Esto aprovecha el hecho de que un navegador no almacenará en caché los recursos obtenidos de las URL con cadenas de consulta en ellos.

Sin embargo, probablemente no desee que el navegador no almacene en caché estos recursos; es más probable que desee almacenarlos en caché, pero desea que el navegador obtenga una nueva versión del archivo cuando esté disponible.

La solución más común parece ser incrustar una marca de tiempo o un número de revisión en el nombre del archivo. Esto es un poco más de trabajo, porque su código debe modificarse para solicitar los archivos correctos, pero significa que, por ejemplo, la versión 7 de su snazzy_javascript_file.js(es decir, snazzy_javascript_file_7.js) se almacena en caché en el navegador hasta que lance la versión 8, y luego su código cambia a buscar en su snazzy_javascript_file_8.jslugar.

La ventaja de usar un file.js?V=1sobre unfileV1.js es que no necesita almacenar varias versiones de los archivos JavaScript en el servidor.

El problema que veo con file.js?V=1 es que puede tener un código dependiente en otro archivo JavaScript que se rompe al usar la nueva versión de las utilidades de la biblioteca.

En aras de la compatibilidad con versiones anteriores, creo que es mucho mejor usarlo jQuery.1.3.jspara sus nuevas páginas y dejar que las páginas existentes lo usen jQuery.1.1.js, hasta que esté listo para actualizar las páginas más antiguas, si es necesario.

Use una GETvariable de versión para evitar el almacenamiento en caché del navegador.

Agregar ?v=AUTO_INCREMENT_VERSIONal final de su URL evita el almacenamiento en caché del navegador, evitando todos los scripts almacenados en caché.

Mi colega acaba de encontrar una referencia a ese método justo después de publicar (en referencia a css) en http://www.stefanhayden.com/blog/2006/04/03/css-caching-hack/ . Es bueno ver que otros lo están usando y parece funcionar. ¿Asumo en este punto que no hay una mejor manera que encontrar-reemplazar para incrementar estos "números de versión" en todas las etiquetas de script?

Aunque es un marco específico, Django 1.4 tiene esta funcionalidad que funciona de manera similar al enlace al sitio 'greenfelt' en la respuesta anterior.

Cache Busting en ASP.NET Core a través de un asistente de etiquetas lo manejará por usted y permitirá que su navegador mantenga scripts / css en caché hasta que el archivo cambie. Simplemente agregue la etiqueta ayudante asp-append-version = "true" a su script (js) o etiqueta de enlace (css):

<link rel="stylesheet" href="~/css/site.min.css" asp-append-version="true"/>

Dave Paquette tiene un buen ejemplo y una explicación del almacenamiento en caché aquí (parte inferior de la página) Almacenamiento en caché

¿La solución más simple? No permita que el navegador se almacene en caché. Agregue la hora actual (en ms) como una consulta.

(Todavía está en versión beta, por lo que podría presentar un caso razonable para no optimizar el rendimiento. Pero YMMV aquí).

Una forma simple Editar htaccess

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} \.(jpe?g|bmp|png|gif|css|js|mp3|ogg)$ [NC]
RewriteCond %{QUERY_STRING} !^(.+?&v33|)v=33[^&]*(?:&(.*)|)$ [NC]
RewriteRule ^ %{REQUEST_URI}?v=33 [R=301,L]

A continuación funcionó para mí:

<head>
<meta charset="UTF-8">
<meta http-equiv="cache-control" content="no-cache, must-revalidate, post-check=0, pre-check=0" />
<meta http-equiv="cache-control" content="max-age=0" />
<meta http-equiv="expires" content="0" />
<meta http-equiv="expires" content="Tue, 01 Jan 1980 1:00:00 GMT" />
<meta http-equiv="pragma" content="no-cache" />
</head>