Como forçar os clientes a atualizar arquivos JavaScript?

No momento, estamos trabalhando em uma versão beta privada e ainda estamos no processo de fazer alterações razoavelmente rápidas, embora, obviamente, à medida que o uso esteja começando a acelerar, estaremos desacelerando esse processo. Dito isso, um problema que estamos enfrentando é que, após enviar uma atualização com novos arquivos JavaScript, os navegadores clientes ainda usam a versão em cache do arquivo e não veem a atualização. Obviamente, em uma chamada de suporte, podemos simplesmente informá-los a fazer uma ctrlF5atualização para garantir que eles obtenham os arquivos atualizados do servidor, mas seria preferível lidar com isso antes desse período.

Nosso pensamento atual é simplesmente anexar um número de versão ao nome dos arquivos JavaScript e, quando forem feitas alterações, incrementar a versão no script e atualizar todas as referências. Isso definitivamente faz o trabalho, mas a atualização das referências em cada versão pode ser complicada.

Como tenho certeza de que não somos os primeiros a lidar com isso, pensei em jogá-lo para a comunidade. Como você garante que os clientes atualizem seu cache ao atualizar seu código? Se você estiver usando o método descrito acima, está usando um processo que simplifica a alteração?

Tanto quanto sei, uma solução comum é adicionar um ?<version>ao link src do script.

Por exemplo:

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

Presumo que, neste momento, não exista uma maneira melhor do que encontrar e substituir para incrementar esses "números de versão" em todas as tags de script?

Você pode ter um sistema de controle de versão para isso? A maioria dos sistemas de controle de versão tem uma maneira de injetar automaticamente o número da revisão no check-in, por exemplo.

Seria algo como isto:

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

Obviamente, sempre existem soluções melhores como esta .

Anexar o horário atual ao URL é realmente uma solução comum. No entanto, você também pode gerenciar isso no nível do servidor da web, se desejar. O servidor pode ser configurado para enviar diferentes cabeçalhos HTTP para arquivos javascript.

Por exemplo, para forçar o armazenamento em cache do arquivo por mais de um dia, você deve enviar:

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

Para a versão beta, se você deseja forçar o usuário a sempre obter as últimas, use:

Cache-Control: no-cache, must-revalidate

Velocidade da página do Google: não inclua uma string de consulta no URL para recursos estáticos. A maioria dos proxies, principalmente o Squid up pela versão 3.0, não armazena em cache os recursos com um "?" na URL deles, mesmo que um cabeçalho de controle de cache: público esteja presente na resposta. Para habilitar o cache de proxy para esses recursos, remova as cadeias de consulta das referências a recursos estáticos e, em vez disso, codifique os parâmetros nos nomes dos arquivos.

Nesse caso, você pode incluir a versão no URL ex: http://abc.com/ v1.2 /script.js e usar o apache mod_rewrite para redirecionar o link para http://abc.com/script.js . Quando você altera a versão, o navegador do cliente atualiza o novo arquivo.

Este uso foi preterido: https://developer.mozilla.org/en-US/docs/Web/HTML/Using_the_application_cache

Esta resposta está com apenas 6 anos de atraso, mas não a vejo em muitos lugares ... O HTML5 introduziu o Cache de Aplicativo, que é usado para resolver esse problema. Eu estava descobrindo que o novo código do servidor que estava escrevendo estava travando o javascript antigo armazenado nos navegadores das pessoas, então eu queria encontrar uma maneira de expirar o javascript deles. Use um arquivo de manifesto parecido com este:

CACHE MANIFEST
# Aug 14, 2014
/mycode.js

NETWORK:
*

e gere esse arquivo com um novo registro de data e hora sempre que você desejar que os usuários atualizem seu cache. Como observação lateral, se você adicionar isso, o navegador não será recarregado (mesmo quando um usuário atualizar a página) até que o manifesto solicite.

Que tal adicionar o tamanho do arquivo como um parâmetro de carregamento?

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

Portanto, toda vez que você atualiza o arquivo, o parâmetro "filever" é alterado.

Que tal quando você atualiza o arquivo e sua atualização resulta no mesmo tamanho de arquivo? Quais são as hipóteses?

Nem todos os navegadores armazenam arquivos em cache com '?' iniciar. O que fiz para garantir que fosse armazenado em cache o máximo possível, incluí a versão no nome do arquivo.

Então, ao invés de stuff.js?123, eu fizstuff_123.js

Eu usei mod_redirect(eu acho) no apache have stuff_*.jspara irstuff.js

Para páginas ASP.NET, estou usando o seguinte

ANTES

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

DEPOIS (força recarregar)

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

Adicionar o DateTime.Now.Ticks funciona muito bem.

Para o ASP.NET, suponho que a próxima solução com opções avançadas (modo de depuração / versão, versões):

Arquivos Js ou Css incluídos desta maneira:

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

Global.JsPostfix e Global.CssPostfix são calculados da seguinte maneira em 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();
    }
    ...
}

Atualmente, a prática comum é gerar um código de hash de conteúdo como parte do nome do arquivo para forçar o navegador, especialmente o IE, a recarregar os arquivos javascript ou css.

Por exemplo,

fornecedor. a7561fb0e9a071baadb9 .js
main. b746e3eb72875af2caa9 .js

Geralmente, é o trabalho das ferramentas de construção, como o webpack. Aqui estão mais detalhes se alguém quiser experimentar se você estiver usando o webpack.

Se você estiver gerando a página que vincula aos arquivos JS, uma solução simples anexará o carimbo de data e hora da última modificação do arquivo aos links gerados.

Isso é muito semelhante à resposta de Huppie, mas funciona em sistemas de controle de versão sem substituição de palavra-chave. Também é melhor do que acrescentar a hora atual, pois isso impediria o armazenamento em cache mesmo quando o arquivo não foi alterado.

A função jQuery getScript também pode ser usada para garantir que um arquivo js seja realmente carregado toda vez que a página for carregada.

Foi assim que eu fiz:

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

Verifique a função em http://api.jquery.com/jQuery.getScript/

Por padrão, $ .getScript () define a configuração do cache como false. Isso anexa um parâmetro de consulta com registro de data e hora ao URL da solicitação para garantir que o navegador faça o download do script toda vez que for solicitado.

Em PHP :

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

Em HTML :

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

Como funciona:

Em HTML, escreva o filepathnome e como você faria, mas apenas na função. O PHP obtém o filetimearquivo e retorna as filepath+name+"?"+timealterações mais recentes

Criamos um SaaS para usuários e fornecemos a eles um script para anexar na página do site deles, e não foi possível anexar uma versão com o script, pois o usuário anexará o script ao site para funcionalidades e não posso forçá-los para alterar a versão cada vez que atualizamos o script

Então, encontramos uma maneira de carregar a versão mais recente do script sempre que o usuário chama o script original

o link do script fornecido ao usuário

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

o arquivo 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
}

Explicação:

O usuário anexou o script fornecido a eles em seu site e verificamos se o token exclusivo anexado ao script existe ou não usando o seletor jQuery e, se não estiver, carregue-o dinamicamente com o token (ou versão mais recente)

Isso é chamado o mesmo script duas vezes, o que pode ser um problema de desempenho, mas realmente resolve o problema de forçar o script a não carregar do cache sem colocar a versão no link de script real fornecido ao usuário ou cliente

Isenção de responsabilidade: não use se o desempenho for um grande problema no seu caso.

No asp.net mvc, você pode usar @ DateTime.UtcNow.ToString () para o número da versão do arquivo js. O número da versão é alterado automaticamente com a data e você força o navegador dos clientes a atualizar automaticamente o arquivo js. Eu estou usando esse método e isso funciona bem.

<script src="~/JsFilePath/JsFile.js?v=@DateTime.UtcNow.ToString()"></script>

location.reload (true);

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

Eu chamo dinamicamente essa linha de código para garantir que o javascript tenha sido recuperado do servidor da Web em vez do cache do navegador para evitar esse problema.

Uma solução é anexar uma string de consulta com um carimbo de data / hora no URL ao buscar o recurso. Isso tira vantagem do fato de um navegador não armazenar em cache os recursos buscados nos URLs com as cadeias de consulta.

Você provavelmente não deseja que o navegador não armazene em cache esses recursos; é mais provável que você os queira em cache, mas deseja que o navegador busque uma nova versão do arquivo quando ele estiver disponível.

A solução mais comum parece ser incorporar um carimbo de data / hora ou número de revisão no próprio nome do arquivo. Isso é um pouco mais trabalhoso, porque seu código precisa ser modificado para solicitar os arquivos corretos, mas significa que, por exemplo, a versão 7 do seu snazzy_javascript_file.js(ie snazzy_javascript_file_7.js) é armazenada em cache no navegador até o lançamento da versão 8 e, em seguida, seu código muda para buscar em seu snazzy_javascript_file_8.jslugar.

A vantagem de usar um file.js?V=1over a fileV1.jsé que você não precisa armazenar várias versões dos arquivos JavaScript no servidor.

O problema que vejo file.js?V=1é que você pode ter um código dependente em outro arquivo JavaScript que é interrompido ao usar a nova versão dos utilitários da biblioteca.

Por uma questão de compatibilidade com versões anteriores, acho muito melhor usar jQuery.1.3.jssuas novas páginas e permitir que as páginas existentes sejam usadas jQuery.1.1.jsaté que você esteja pronto para atualizar as páginas mais antigas, se necessário.

Use uma GETvariável de versão para impedir o cache do navegador.

Anexar ?v=AUTO_INCREMENT_VERSIONao final do seu URL impede o cache do navegador, evitando todo e qualquer script em cache.

Meu colega acabou de encontrar uma referência a esse método logo depois que eu postei (em referência ao css) em http://www.stefanhayden.com/blog/2006/04/03/css-caching-hack/ . É bom ver que outras pessoas estão usando e parece funcionar. Presumo que, neste momento, não exista uma maneira melhor do que localizar e substituir para incrementar esses "números de versão" em todas as tags de script?

Embora seja específico da estrutura, o Django 1.4 tem essa função, que funciona de maneira semelhante ao link para o site 'greenfelt' na resposta acima.

A invasão de cache no ASP.NET Core por meio de um auxiliar de marca tratará disso para você e permitirá que seu navegador mantenha os scripts em cache / css até que o arquivo seja alterado. Basta adicionar a tag helper asp-append-version = "true" à sua tag de script (js) ou link (css):

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

Dave Paquette tem um bom exemplo e explicação do bloqueio de cache aqui (na parte inferior da página) Cache rebentando

Solução mais simples? Não deixe o navegador em cache. Anexe a hora atual (em ms) como uma consulta.

(Você ainda está na versão beta, portanto, você poderia argumentar razoavelmente por não otimizar o desempenho. Mas YMMV aqui.)

Uma maneira simples. 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]

Abaixo trabalhou para mim:

<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>