Como forçar o navegador a recarregar arquivos CSS / JS em cache?

Percebi que alguns navegadores (em particular, Firefox e Opera) são muito zelosos ao usar cópias em cache de arquivos .css e .js , mesmo entre as sessões do navegador. Isso causa um problema quando você atualiza um desses arquivos, mas o navegador do usuário continua usando a cópia em cache.

A questão é: qual é a maneira mais elegante de forçar o navegador do usuário a recarregar o arquivo quando ele foi alterado?

Idealmente, a solução não forçaria o navegador a recarregar o arquivo em todas as visitas à página. Vou postar minha própria solução como resposta, mas estou curioso para saber se alguém tem uma solução melhor e deixarei seus votos decidirem.

Atualização:

Depois de permitir a discussão aqui por um tempo, achei a sugestão de John Millikin e da5id útil. Acontece que existe um termo para isso: versão automática .

Publiquei uma nova resposta abaixo, que é uma combinação da minha solução original e da sugestão de John.

Outra idéia sugerida pelo SCdF seria anexar uma string de consulta falsa ao arquivo. (Algum código Python para usar automaticamente o registro de data e hora como uma string de consulta falsa foi enviado por pi .). No entanto, há alguma discussão sobre se o navegador armazenará ou não um arquivo em cache com uma string de consulta. (Lembre-se de que queremos que o navegador armazene em cache o arquivo e use-o em futuras visitas. Queremos que apenas busque o arquivo novamente quando ele tiver sido alterado.)

Como não está claro o que acontece com uma string de consulta falsa, não estou aceitando essa resposta.

Atualização: reescrita para incorporar sugestões de John Millikin e da5id . Esta solução é escrita em PHP, mas deve ser facilmente adaptada a outras linguagens.

Atualização 2: Incorporando comentários de Nick Johnson de que o .htaccessregex original pode causar problemas com arquivos como json-1.3.js. A solução é reescrever apenas se houver exatamente 10 dígitos no final. (Como 10 dígitos abrange todos os carimbos de data e hora de 9/9/2001 a 20/11/2286.)

Primeiro, usamos a seguinte regra de reescrita em .htaccess:

RewriteEngine on
RewriteRule ^(.*)\.[\d]{10}\.(css|js)$ $1.$2 [L]

Agora, escrevemos a seguinte função PHP:

/**
 *  Given a file, i.e. /css/base.css, replaces it with a string containing the
 *  file's mtime, i.e. /css/base.1221534296.css.
 *  
 *  @param $file  The file to be loaded.  Must be an absolute path (i.e.
 *                starting with slash).
 */
function auto_version($file)
{
  if(strpos($file, '/') !== 0 || !file_exists($_SERVER['DOCUMENT_ROOT'] . $file))
    return $file;

  $mtime = filemtime($_SERVER['DOCUMENT_ROOT'] . $file);
  return preg_replace('{\\.([^./]+)$}', ".$mtime.\$1", $file);
}

Agora, onde quer que você inclua seu CSS, altere-o a partir deste:

<link rel="stylesheet" href="/css/base.css" type="text/css" />

Para isso:

<link rel="stylesheet" href="<?php echo auto_version('/css/base.css'); ?>" type="text/css" />

Dessa forma, você nunca precisará modificar a tag do link novamente, e o usuário sempre verá o CSS mais recente. O navegador poderá armazenar em cache o arquivo CSS, mas quando você fizer alterações no CSS, o navegador o verá como um novo URL, portanto, não usará a cópia em cache.

Isso também pode funcionar com imagens, ícones favoritos e JavaScript. Basicamente, qualquer coisa que não seja gerada dinamicamente.

Técnica simples do lado do cliente

Em geral, o armazenamento em cache é bom. Portanto, existem algumas técnicas, dependendo se você está solucionando o problema por conta própria ao desenvolver um site ou se está tentando controlar o cache em um ambiente de produção.

Os visitantes gerais do seu site não terão a mesma experiência que você está tendo ao desenvolver o site. Como o visitante médio acessa o site com menos frequência (talvez apenas algumas vezes por mês, a menos que você seja um Google ou hi5 Networks), é menos provável que eles tenham seus arquivos em cache, e isso pode ser suficiente. Se você deseja forçar uma nova versão no navegador, sempre pode adicionar uma sequência de consultas à solicitação e aumentar o número da versão ao fazer grandes alterações:

<script src="/myJavascript.js?version=4"></script>

Isso garantirá que todos obtenham o novo arquivo. Funciona porque o navegador verifica a URL do arquivo para determinar se ele possui uma cópia no cache. Se o servidor não estiver configurado para fazer qualquer coisa com a sequência de consultas, ele será ignorado, mas o nome parecerá um novo arquivo para o navegador.

Por outro lado, se você estiver desenvolvendo um site, não deseja alterar o número da versão sempre que salvar uma alteração na sua versão de desenvolvimento. Isso seria entediante.

Portanto, enquanto você estiver desenvolvendo seu site, um bom truque seria gerar automaticamente um parâmetro de string de consulta:

<!-- Development version: -->
<script>document.write('<script src="/myJavascript.js?dev=' + Math.floor(Math.random() * 100) + '"\><\/script>');</script>

Adicionar uma sequência de consultas à solicitação é uma boa maneira de versão de um recurso, mas para um site simples, isso pode ser desnecessário. E lembre-se, o cache é uma coisa boa.

Também é importante notar que o navegador não é necessariamente mesquinho para manter os arquivos em cache. Os navegadores têm políticas para esse tipo de coisa e geralmente estão seguindo as regras estabelecidas na especificação HTTP. Quando um navegador faz uma solicitação a um servidor, parte da resposta é um cabeçalho EXPIRES. Uma data que informa ao navegador quanto tempo deve ser mantido em cache. Na próxima vez em que o navegador encontrar uma solicitação para o mesmo arquivo, ele verá que possui uma cópia no cache e procurará a data EXPIRES para decidir se deve ser usado.

Então, acredite ou não, na verdade, é o seu servidor que está tornando o cache do navegador tão persistente. Você pode ajustar as configurações do servidor e alterar os cabeçalhos EXPIRES, mas a pequena técnica que escrevi acima é provavelmente uma maneira muito mais simples de você fazer isso. Como o armazenamento em cache é bom, geralmente você deseja definir essa data no futuro (um "Cabeçalho de expiração do futuro distante") e usar a técnica descrita acima para forçar uma alteração.

Se você estiver interessado em obter mais informações sobre HTTP ou sobre como essas solicitações são feitas, um bom livro é "Sites de alto desempenho", de Steve Souders. É uma introdução muito boa ao assunto.

O plug- in mod_pagespeed do Google para apache fará a versão automática para você. É realmente liso.

Ele analisa o HTML ao sair do servidor da web (funciona com PHP, rails, python, HTML estático - qualquer coisa) e reescreve links para arquivos de imagem CSS, JS, para que incluam um código de identificação. Ele serve os arquivos nos URLs modificados com um controle de cache muito longo. Quando os arquivos mudam, os URLs são alterados automaticamente para que o navegador os busque novamente. Basicamente, funciona, sem nenhuma alteração no seu código. Ele também reduzirá seu código na saída.

Em vez de alterar a versão manualmente, recomendo que você use um hash MD5 do arquivo CSS real.

Portanto, seu URL seria algo como

http://mysite.com/css/[md5_hash_here]/style.css

Você ainda pode usar a regra de reescrita para remover o hash, mas a vantagem é que agora você pode definir sua política de cache como "cache para sempre", pois se a URL for a mesma, isso significa que o arquivo permanece inalterado.

Em seguida, você pode escrever um script de shell simples que calcule o hash do arquivo e atualize sua tag (você provavelmente deseja movê-lo para um arquivo separado para inclusão).

Basta executar esse script toda vez que o CSS mudar e você for bom. O navegador apenas recarregará seus arquivos quando eles forem alterados. Se você fizer uma edição e depois desfazê-la, não há problema em descobrir em qual versão você precisa retornar para que seus visitantes não façam o download novamente.

Não sei por que vocês estão sofrendo tanto para implementar esta solução.

Tudo o que você precisa fazer se obter o carimbo de data / hora modificado do arquivo e anexá-lo como uma string de consulta ao arquivo

No PHP, eu faria isso como:

<link href="mycss.css?v=<?= filemtime('mycss.css') ?>" rel="stylesheet">

filemtime é uma função PHP que retorna o carimbo de data / hora modificado do arquivo.

Você pode simplesmente colocar ?foo=1234no final de sua importação de css / js, alterando 1234 para o que quiser. Dê uma olhada na fonte SO html para um exemplo.

A idéia de que é isso? de qualquer maneira, os parâmetros são descartados / ignorados na solicitação e você pode alterar esse número ao lançar uma nova versão.

Nota: Há algum argumento sobre exatamente como isso afeta o armazenamento em cache. Eu acredito que a essência geral disso é que as solicitações GET, com ou sem parâmetros, devem ser alteráveis, portanto a solução acima deve funcionar.

No entanto, cabe ao servidor da web decidir se deseja aderir à parte da especificação e ao navegador que o usuário usa, pois ele pode seguir em frente e solicitar uma versão nova de qualquer maneira.

Eu ouvi isso chamado "versionamento automático". O método mais comum é incluir o mtime do arquivo estático em algum lugar da URL e removê-lo usando manipuladores de reescrita ou confs de URL:

Veja também:

• Versão automática de ativos no Django
• Versão automática dos arquivos CSS e JavaScript

As cerca de 30 respostas existentes são ótimos conselhos para um site de cerca de 2008. No entanto, quando se trata de um aplicativo moderno de página única (SPA), talvez seja hora de repensar algumas suposições fundamentais ... especificamente a idéia de que é desejável que o servidor da Web sirva apenas a versão única e mais recente de um Arquivo.

Imagine que você é um usuário que possui a versão M de um SPA carregada no seu navegador:

1. Seu pipeline de CD implementa a nova versão N do aplicativo no servidor
2. Você navega dentro do SPA, que envia um XHR ao servidor para obter /some.template
   • (Seu navegador não atualizou a página, você ainda está executando a versão M )
3. O servidor responde com o conteúdo de /some.template- você deseja que ele retorne a versão M ou N do modelo?

Se o formato /some.templatemudou entre as versões M e N (ou o arquivo foi renomeado ou o que for), você provavelmente não deseja que a versão N do modelo seja enviada ao navegador que está executando a versão antiga M do analisador . †

Os aplicativos da Web enfrentam esse problema quando duas condições são atendidas:

• Os recursos são solicitados de forma assíncrona em algum momento após o carregamento inicial da página
• A lógica do aplicativo pressupõe coisas (que podem mudar em versões futuras) sobre o conteúdo do recurso

Depois que o aplicativo precisar exibir várias versões em paralelo, a solução do cache e do "recarregamento" se tornará trivial:

1. Instale todos os arquivos do site em diretórios versionados: /v<release_tag_1>/…files…,/v<release_tag_2>/…files…
2. Defina cabeçalhos HTTP para permitir que os navegadores armazenem em cache os arquivos para sempre
   • (Ou melhor ainda, coloque tudo em uma CDN)
3. Atualizar todos <script>e <link>etiquetas, etc. para apontar para esse arquivo em um dos diretórios versionados

Essa última etapa parece complicada, pois pode exigir a chamada de um construtor de URL para cada URL no código do servidor ou do cliente. Ou você pode fazer um uso inteligente da <base>tag e alterar a versão atual em um só lugar.

† Uma maneira de contornar isso é ser agressivo ao forçar o navegador a recarregar tudo quando uma nova versão for lançada. Porém, para permitir a conclusão de qualquer operação em andamento, ainda pode ser mais fácil oferecer suporte a pelo menos duas versões em paralelo: v-current e v-previous.

Não use foo.css? Version = 1! Os navegadores não devem armazenar em cache URLs com variáveis ​​GET. De acordo com http://www.thinkvitamin.com/features/webapps/serving-javascript-fast , embora o IE e o Firefox ignorem isso, o Opera e o Safari não! Em vez disso, use foo.v1234.css e use regras de reescrita para remover o número da versão.

No Laravel (PHP), podemos fazê-lo da seguinte maneira clara e elegante (usando o timestamp de modificação de arquivo):

<script src="{{ asset('/js/your.js?v='.filemtime('js/your.js')) }}"></script>

E semelhante para CSS

<link rel="stylesheet" href="{{asset('css/your.css?v='.filemtime('css/your.css'))}}">

Exemplo de saída html ( filemtimetempo de retorno como carimbo de data e hora do Unix )

<link rel="stylesheet" href="assets/css/your.css?v=1577772366">

O RewriteRule precisa de uma pequena atualização para arquivos js ou css que contêm uma versão de notação de ponto no final. Por exemplo, json-1.3.js.

Adicionei uma classe de negação de ponto [^.] Ao regex, para .number. é ignorado.

RewriteRule ^(.*)\.[^.][\d]+\.(css|js)$ $1.$2 [L]

Para o ASP.NET 4.5 e superior, você pode usar o agrupamento de scripts .

A solicitação http://localhost/MvcBM_time/bundles/AllMyScripts?v=r0sLDicvP58AIXN_mc3QdyVvVj5euZNzdsa2N1PKvb81é para o pacote configurável AllMyScripts e contém um par de cadeias de consulta v = r0sLDicvP58AIXN_mc3QdyVvVj5euZNzdsa2N1PKvb81. A sequência de consultas v possui um token de valor que é um identificador exclusivo usado para armazenamento em cache. Desde que o pacote não seja alterado, o aplicativo ASP.NET solicitará o pacote AllMyScripts usando esse token. Se algum arquivo do pacote for alterado, a estrutura de otimização do ASP.NET gerará um novo token, garantindo que as solicitações do navegador para o pacote tenham o pacote mais recente.

Existem outros benefícios no pacote, incluindo desempenho aprimorado em carregamentos de primeira página com minificação.

Aqui está uma solução JavaScript pura

(function(){

    // Match this timestamp with the release of your code
    var lastVersioning = Date.UTC(2014, 11, 20, 2, 15, 10);

    var lastCacheDateTime = localStorage.getItem('lastCacheDatetime');

    if(lastCacheDateTime){
        if(lastVersioning > lastCacheDateTime){
            var reload = true;
        }
    }

    localStorage.setItem('lastCacheDatetime', Date.now());

    if(reload){
        location.reload(true);
    }

})();

O item acima procurará a última vez que o usuário visitou seu site. Se a última visita foi antes do lançamento do novo código, ele será usado location.reload(true)para forçar a atualização da página do servidor.

Normalmente, eu tenho esse como o primeiro script dentro <head>dele, por isso é avaliado antes que qualquer outro conteúdo seja carregado. Se uma recarga precisar ocorrer, dificilmente será percebida pelo usuário.

Estou usando o armazenamento local para armazenar o carimbo de data e hora da última visita no navegador, mas você pode adicionar cookies à mistura se desejar oferecer suporte a versões mais antigas do IE.

Postagem interessante. Depois de ler todas as respostas aqui combinadas com o fato de que nunca tive problemas com cadeias de consulta "falsas" (o que não sei por que todos relutam em usar isso), acho que a solução (que elimina a necessidade de regras de reescrita do apache como na resposta aceita) é calcular um HASH curto do conteúdo do arquivo CSS (em vez da data e hora do arquivo) como uma string de consulta falsa.

Isso resultaria no seguinte:

<link rel="stylesheet" href="/css/base.css?[hash-here]" type="text/css" />

É claro que as soluções datetime também fazem o trabalho no caso de editar um arquivo CSS, mas acho que é sobre o conteúdo do arquivo css e não sobre o datetime do arquivo, então por que misturá-los?

Para o meu desenvolvimento, acho que o chrome tem uma ótima solução.

https://developer.chrome.com/devtools/docs/tips-and-tricks#hard-reload

Com as ferramentas do desenvolvedor abertas, basta clicar e clicar no botão Atualizar e soltar quando passar o mouse sobre "Esvaziar o cache e recarregar".

Este é meu melhor amigo e é uma maneira super leve de conseguir o que você quer!

Agradecemos a Kip por sua solução perfeita!

Eu o estendi para usá-lo como um Zend_view_Helper. Como meu cliente executou sua página em um host virtual, eu também a estendi para isso.

Espero que ajude outra pessoa também.

/**
 * Extend filepath with timestamp to force browser to
 * automatically refresh them if they are updated
 *
 * This is based on Kip's version, but now
 * also works on virtual hosts
 * @link http://stackoverflow.com/questions/118884/what-is-an-elegant-way-to-force-browsers-to-reload-cached-css-js-files
 *
 * Usage:
 * - extend your .htaccess file with
 * # Route for My_View_Helper_AutoRefreshRewriter
 * # which extends files with there timestamp so if these
 * # are updated a automatic refresh should occur
 * # RewriteRule ^(.*)\.[^.][\d]+\.(css|js)$ $1.$2 [L]
 * - then use it in your view script like
 * $this->headLink()->appendStylesheet( $this->autoRefreshRewriter($this->cssPath . 'default.css'));
 *
 */
class My_View_Helper_AutoRefreshRewriter extends Zend_View_Helper_Abstract {

    public function autoRefreshRewriter($filePath) {

        if (strpos($filePath, '/') !== 0) {

            // path has no leading '/'
            return $filePath;
        } elseif (file_exists($_SERVER['DOCUMENT_ROOT'] . $filePath)) {

            // file exists under normal path
            // so build path based on this
            $mtime = filemtime($_SERVER['DOCUMENT_ROOT'] . $filePath);
            return preg_replace('{\\.([^./]+)$}', ".$mtime.\$1", $filePath);
        } else {

            // fetch directory of index.php file (file from all others are included)
            // and get only the directory
            $indexFilePath = dirname(current(get_included_files()));

            // check if file exist relativ to index file
            if (file_exists($indexFilePath . $filePath)) {

                // get timestamp based on this relativ path
                $mtime = filemtime($indexFilePath . $filePath);

                // write generated timestamp to path
                // but use old path not the relativ one
                return preg_replace('{\\.([^./]+)$}', ".$mtime.\$1", $filePath);
            } else {

                return $filePath;
            }
        }
    }

}

Saúde e obrigado.

Não encontrou a abordagem DOM do lado do cliente criando o elemento nó do script (ou css) dinamicamente:

<script>
    var node = document.createElement("script"); 
    node.type = "text/javascript";
    node.src = 'test.js?'+Math.floor(Math.random()*999999999);
    document.getElementsByTagName("head")[0].appendChild(node);
</script>

o google chrome tem a opção Recarregar com disco rígido , bem como a opção Cache vazio e Recarregar disco rígido. Você pode clicar e segurar o botão recarregar (no modo de inspeção) para selecionar um.

Você pode forçar um "cache em toda a sessão" se adicionar o ID da sessão como um parâmetro espúrio do arquivo js / css:

<link rel="stylesheet" src="myStyles.css?ABCDEF12345sessionID" />
<script language="javascript" src="myCode.js?ABCDEF12345sessionID"></script>

Se você deseja um armazenamento em cache em toda a versão, adicione um código para imprimir a data do arquivo ou similar. Se você estiver usando Java, poderá usar uma tag personalizada para gerar o link de uma maneira elegante.

<link rel="stylesheet" src="myStyles.css?20080922_1020" />
<script language="javascript" src="myCode.js?20080922_1120"></script>

Digamos que você tenha um arquivo disponível em:

/styles/screen.css

você pode anexar um parâmetro de consulta com informações de versão no URI, por exemplo:

/styles/screen.css?v=1234

ou você pode anexar informações da versão, por exemplo:

/v/1234/styles/screen.css

IMHO, o segundo método é melhor para arquivos CSS, pois eles podem se referir a imagens usando URLs relativos, o que significa que, se você especificar background-imageo seguinte:

body {
    background-image: url('images/happy.gif');
}

seu URL será efetivamente:

/v/1234/styles/images/happy.gif

Isso significa que, se você atualizar o número da versão usada, o servidor tratará isso como um novo recurso e não usará uma versão em cache. Se você basear seu número de versão no Subversion / CVS / etc. revisão significa que as alterações nas imagens referenciadas nos arquivos CSS serão notadas. Isso não é garantido com o primeiro esquema, ou seja, o URL images/happy.gifrelativo a /styles/screen.css?v=1235é/styles/images/happy.gif que não contém nenhuma informação de versão.

Eu implementei uma solução de armazenamento em cache usando essa técnica com servlets Java e simplesmente lide com solicitações /v/*com um servlet que delega para o recurso subjacente (ou seja /styles/screen.css). No modo de desenvolvimento que defina o cache cabeçalhos que informam ao cliente para sempre verificar o frescor do recurso com o servidor (isso normalmente resulta em um 304 se você delegar Tomcat de DefaultServleteo .css, .jsetc. arquivo não foi alterado), enquanto no modo de implantação Defino cabeçalhos que dizem "cache para sempre".

Você pode simplesmente adicionar algum número aleatório com o URL CSS / JS como

example.css?randomNo=Math.random()

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();
    }
    ...
}

Eu recentemente resolvi isso usando Python. Aqui o código (deve ser fácil de adotar para outros idiomas):

def import_tag(pattern, name, **kw):
    if name[0] == "/":
        name = name[1:]
    # Additional HTML attributes
    attrs = ' '.join(['%s="%s"' % item for item in kw.items()])
    try:
        # Get the files modification time
        mtime = os.stat(os.path.join('/documentroot', name)).st_mtime
        include = "%s?%d" % (name, mtime)
        # this is the same as sprintf(pattern, attrs, include) in other
        # languages
        return pattern % (attrs, include)
    except:
        # In case of error return the include without the added query
        # parameter.
        return pattern % (attrs, name)

def script(name, **kw):
    return import_tag("""<script type="text/javascript" """ +\
        """ %s src="/%s"></script>""", name, **kw)

def stylesheet(name, **kw):
    return import_tag('<link rel="stylesheet" type="text/css" ' +\
        """%s href="/%s">', name, **kw) 

Esse código basicamente anexa o carimbo de data / hora dos arquivos como um parâmetro de consulta ao URL. A chamada da seguinte função

script("/main.css")

vai resultar em

<link rel="stylesheet" type="text/css"  href="/main.css?1221842734">

A vantagem, é claro, é que você nunca precisará alterar seu html novamente. Tocar no arquivo CSS acionará automaticamente uma invalidação de cache. Funciona muito bem e a sobrecarga não é perceptível.

Se você estiver usando git + PHP, poderá recarregar o script do cache sempre que houver uma alteração no repositório git, usando o seguinte código:

exec('git rev-parse --verify HEAD 2> /dev/null', $gitLog);
echo '  <script src="/path/to/script.js"?v='.$gitLog[0].'></script>'.PHP_EOL;

Se você é um desenvolvedor que deseja evitar o armazenamento em cache, a guia rede do Chrome desativou a opção de cache. Caso contrário, você poderá fazê-lo sem uma estrutura de renderização do servidor usando duas tags de script.

<script type="text/javascript">
    document.write('<script type="text/javascript" src="myfile.js?q=' + Date.now() + '">
    // can't use myfile.js stuff yet
</script>')
<script type="text/javascript">
    // do something with myfile.js
</script>

Esta pergunta é super antiga e aparece logo que alguém procura no Google esse problema. Esta não é uma resposta para a pergunta da maneira que o op quer, mas uma resposta para os desenvolvedores com esse problema durante o desenvolvimento e o teste. E não consigo postar uma nova pergunta sobre este tópico, pois ela será marcada como duplicada.

Como muitos outros, eu só queria remover o cache brevemente.

"keep caching consistent with the file" .. é muito aborrecido ..

De um modo geral, não me importo de carregar mais - mesmo carregar novamente arquivos que não foram alterados - na maioria dos projetos - é praticamente irrelevante. Durante o desenvolvimento de um aplicativo - estamos carregando principalmente do disco, por diante localhost:port -, esse increase in network trafficproblema não é uma questão de quebra de negócio .

A maioria dos projetos pequenos está apenas brincando - eles nunca acabam em produção. então para eles você não precisa de mais nada ..

Portanto, se você usa as Ferramentas de desenvolvimento do Chrome , pode seguir esta abordagem de desativar cache, como na imagem abaixo:

E se você tiver problemas de cache do firefox :

Faça isso apenas no desenvolvimento, você também precisará de um mecanismo para forçar o recarregamento da produção, pois os usuários usarão módulos antigos invalidados pelo cache se você atualizar o aplicativo com freqüência e não fornecer um mecanismo de sincronização de cache dedicado, como os descritos nas respostas acima.

Sim, essas informações já estão nas respostas anteriores, mas eu ainda precisava fazer uma pesquisa no google para encontrá-las.

Espero que esta resposta seja muito clara e agora você não precisa.

Parece que todas as respostas aqui sugerem algum tipo de versão no esquema de nomenclatura, que tem suas desvantagens.

Os navegadores devem estar cientes do que armazenar em cache e do que não armazenar em cache, lendo a resposta dos servidores da web, em particular os cabeçalhos http - por quanto tempo esse recurso é válido? este recurso foi atualizado desde a última vez que o recuperei? etcetera.

Se as coisas estiverem configuradas 'corretamente', apenas a atualização dos arquivos do seu aplicativo deve (em algum momento) atualizar os caches dos navegadores. Você pode, por exemplo, configurar seu servidor da Web para dizer ao navegador para nunca armazenar em cache arquivos (o que é uma má ideia).

Uma explicação mais detalhada de como isso funciona está aqui https://www.mnot.net/cache_docs/#WORK

Simplesmente adicione este código, onde você deseja recarregar com força (forçar o navegador a recarregar arquivos CSS / JS em cache) Faça isso dentro do .load para que não seja atualizado como um loop

 $( window ).load(function() {
   location.reload(true);
});

Basta usar o código do lado do servidor para adicionar a data do arquivo ... dessa forma, ele será armazenado em cache e recarregado apenas quando o arquivo for alterado

No ASP.NET

<link rel="stylesheet" href="~/css/custom.css?d=@(System.Text.RegularExpressions.Regex.Replace(File.GetLastWriteTime(Server.MapPath("~/css/custom.css")).ToString(),"[^0-9]", ""))" />

<script type="text/javascript" src="~/js/custom.js?d=@(System.Text.RegularExpressions.Regex.Replace(File.GetLastWriteTime(Server.MapPath("~/js/custom.js")).ToString(),"[^0-9]", ""))"></script>    

Isso pode ser simplificado para:

<script src="<%= Page.ResolveClientUrlUnique("~/js/custom.js") %>" type="text/javascript"></script>

Adicionando um método de extensão ao seu projeto para estender a Página:

public static class Extension_Methods
{
    public static string ResolveClientUrlUnique(this System.Web.UI.Page oPg, string sRelPath)
    {
        string sFilePath = oPg.Server.MapPath(sRelPath);
        string sLastDate = System.IO.File.GetLastWriteTime(sFilePath).ToString();
        string sDateHashed = System.Text.RegularExpressions.Regex.Replace(sLastDate, "[^0-9]", "");

        return oPg.ResolveClientUrl(sRelPath) + "?d=" + sDateHashed;
    }
}

Sugiro implementar o seguinte processo:

• versão seus arquivos css / js sempre que você implantar, algo como: screen.1233.css (o número pode ser sua revisão SVN se você usar um sistema de controle de versão)

• reduza-os para otimizar os tempos de carregamento