Ajuda com cache JavaScript agressivo

Question

Encontrei um problema em que faço alterações em alguns arquivos JavaScript referenciados em um arquivo HTML, mas o navegador não vê as alterações.Ele mantém a cópia armazenada em cache no navegador, mesmo que o servidor web tenha uma versão mais recente.

Só depois de forçar o navegador a limpar o cache é que vejo as alterações.

Esta é uma configuração de servidor web?Preciso configurar meus arquivos JavaScript para nunca armazenar em cache?Eu vi algumas técnicas interessantes no Kit de ferramentas da Web do Google onde eles realmente criam um novo Nome do arquivo JavaScript sempre que uma atualização é feita.Acredito que isso evita que proxies e navegadores mantenham versões antigas dos arquivos JavaScript com os mesmos nomes.

Existe uma lista de práticas recomendadas em algum lugar?

Answer 1

Anexamos um número de compilação do produto ao final de todo Javascript (e CSS, etc.), assim:

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

Os navegadores ignoram tudo após o ponto de interrogação, mas as atualizações causam um novo URL, o que significa recarga de cache.

Isso tem o benefício adicional de poder definir cabeçalhos HTTP que significam "nunca armazenar em cache!"

Answer 2

Ele mantém a cópia armazenada em cache no navegador, mesmo que o servidor web tenha uma versão mais recente.

Provavelmente, isso ocorre porque os cabeçalhos HTTP Expires/Cache-Control estão definidos.

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

Escrevi sobre isso aqui:

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

Este não é um mau conselho, por si só, mas pode causar enormes problemas se você errar.No IIS da Microsoft, por exemplo, o cabeçalho Expires está sempre desativado por padrão, provavelmente por esse motivo.Ao definir um cabeçalho Expires em recursos HTTP, você está dizendo ao cliente para nunca verifique novas versões desse recurso - pelo menos não até a data de expiração no cabeçalho Expires. Quando digo nunca, estou falando sério: o navegador nem sequer perguntar para uma nova versão;ele apenas assumirá que sua versão em cache está pronta até que o cliente limpe o cache ou o cache atinja a data de expiração. O Yahoo observa que eles alteram o nome do arquivo desses recursos quando precisam atualizá-los.

Tudo o que você realmente está economizando aqui é o custo do cliente fazer ping no servidor para uma nova versão e obter um cabeçalho 304 não modificado de volta, no caso comum de o recurso não ter sido alterado.Isso não é muita sobrecarga..a menos que você seja o Yahoo.Claro, se você tiver um conjunto de imagens ou scripts que quase nunca mudam, explore definitivamente o cache do cliente e ative o cabeçalho Cache-Control.O cache é fundamental para o desempenho do navegador;todo desenvolvedor web deve ter um conhecimento profundo de como funciona o cache HTTP.Mas use-o apenas de forma cirúrgica e limitada para pastas ou arquivos específicos que podem ser beneficiados.Para qualquer outra coisa, o risco supera o benefício.Certamente não é algo que você deseja ativar como padrão geral para todo o seu site.a menos que você goste de alterar os nomes dos arquivos sempre que o conteúdo for alterado.

Answer 3

@Jason e Darren

IE6 trata qualquer coisa com uma string de consulta como impossível de armazenar em cache.Você deve encontrar outra maneira de inserir o número da versão na URL, como um diretório falso:

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

e apenas remova o primeiro nível de diretório após js no lado do servidor antes de atender à solicitação.

EDITAR:Desculpe a todos;é o Squid, não o IE6, que não armazena em cache uma string de consulta.Mais informações aqui.

Answer 4

Escrevi uma postagem no blog sobre como superamos esse problema aqui:

Evitando problemas de cache de folhas de estilo JavaScript e CSS no ASP.NET

Basicamente, durante o desenvolvimento, você pode adicionar um número aleatório a uma string de consulta após o nome do arquivo CSS.Quando você cria uma versão, o código passa a usar o número de revisão do seu assembly.Isso significa que em seu ambiente de produção, seus clientes podem armazenar em cache a folha de estilo, mas sempre que você lançar uma nova versão do site, eles serão forçados a recarregar o arquivo.

Answer 5

Eu também adoro o método de apenas renomear as coisas.Nunca falha e é bastante fácil de fazer.

Answer 6

o seu servidor da web está enviando os cabeçalhos corretos para informar ao navegador que ele tem uma nova versão?Também adicionei a data à string de consulta antes.ou seja, myscripts.js?date=4/14/2008 12:45:03 (apenas a data seria codificada)

Answer 7

@Darren O problema de cache ocorreu no IIS 6 e no Apache 2 prontos para uso.Não tenho certeza se a resolução adequada é modificar os cabeçalhos de resposta HTTP, mas sim seguir a rota de renomeação descrita em algumas das respostas aqui.

@Chris Boa dica.Achei que a abordagem da string de consulta era boa, mas parece que um arquivo ou nome de diretório exclusivo é necessário para cobrir todos os casos.

Answer 8

A cada versão, simplesmente acrescentamos um número inteiro crescente monotonicamente ao caminho raiz de todos os nossos ativos estáticos, o que força o cliente a recarregar (já vimos o método da string de consulta quebrar no IE6 antes).Por exemplo:

• Lançamento 1:http://www.foo.com/1/js/foo.js
• Lançamento 2:http://www.foo.com/2/js/foo.js

É necessário reorganizar os links a cada versão, mas criamos funcionalidades para alterar automaticamente os links em nossas ferramentas de implantação.

Depois de fazer isso, você pode usar os cabeçalhos Expires/Cache-Control que permitem ao cliente armazenar em cache os recursos JS "para sempre", já que o caminho muda a cada versão, o que eu acho que é o que @JasonCohen queria dizer.

Answer 9

Algumas técnicas muito úteis em aqui mesmo se você não estiver planejando usar o PowerShell para automatizar a implantação.

Answer 10

Pelo que vale a pena, eu vi deviantART site, bastante grande, exibindo seus arquivos JS como 54504.js.Acabei de verificar e vi que agora eles os servem como v6core.css?-5855446573 v6core_jc.js?4150339741 etc.

Se o problema da string de consulta vier do servidor, suponho que você possa controlar isso mais ou menos.