Evitando o cache no cliente

HTML e CSS nunca foram meu forte, eu sei o que preciso saber para sobreviver, já que trabalho com desenvolvimento web. Não da pra esperar que eu consiga montar uma apresentação fantástica usando HTML5 e CSS3 e ainda por cima pensando fortemente em semântica, organização e melhores práticas, fato!

Não estou aqui criticando HTML e CSS, eu entendo perfeitamente a importância de tudo isso, mas não posso negar que nunca me dediquei muito para aprende-las, até porque nunca tive a necessidade de ser o responsável por esse trabalho. Exatamente por isso eu aprendi algo babacamente simples esses dias, porém extremamente eficiente.

Imagine mudar o CSS, subir pra produção e o cliente simplesmente ver o seu site totalmente quebrado? Pior, mudar uma imagem (um banner ou qualquer outra imagem) e o cliente continuar recebendo a imagem antiga. Quem trabalha com sistemas web e nunca passou por isso?

É muito comum alterarmos qualquer coisa estática como CSS, imagens e até JavaScript e essas alterações não serem interpretadas pelo navegador. O jeito é limpar (ou desligar) o cache do navegador, dar uns 3 ou mais refreshs ou apelar pro CTRL+F5, isso é o que fazemos desenvolvendo. Mas e quando isso acontece em produção, vamos dizer pro usuário/cliente ‘limpar o cache’? Claro que não, temos que dar um jeito então do navegador do cliente reconhecer as alterações logo na primeira visita.

Isso ocorre pois o navegador faz cache local destes recursos e os utiliza quando julga ser a melhor opção. A mesma coisa ocorre com proxy de redes, que também podem fazer cache. O jeito para descartar esse cache é fazer algum malabarismo no servidor web, mas nem sempre isso é possível, então precisamos recorrer à aplicação, onde – geralmente – temos maior domínio.

O cache no navegador tem uma regra básica super simples: o nome do recurso estático. Se mudarmos o nome de um arquivo CSS ou imagem, por exemplo, não teremos problema algum com cache. Se você puder fazer isso na sua aplicação, ótimo, problema resolvido.

Mas se não puder, temos outra opção simples e eficiente, podemos anexar algum parâmetro falso no nome do recurso, por exemplo:

[cce lang=’html4strict’ ]<link rel=”stylesheet” type=”text/css” href=”/css/estilo.css” />[/cce]

Ao atualizar propriedades desta folha de estilo as alterações não serão perceptíveis no navegador enquanto o cache (do navegador) não for atualizado. E isso ou o cliente faz explicitamente ou nós faremos por ele. Então, vamos fazer a nossa parte, vejam:

[cce lang=’html4strict’ ]<link rel=”stylesheet” type=”text/css” href=”/css/estilo.css?1″ />[/cce]

O simples parâmetro [cci]?1[/cci] cuida disso pra nós. O navegador vai encarar que se trata de uma nova folha de estilos e fará o download do servidor, utilizando esta nova versão no lugar da que ele tem em cache, na próxima visita o [cci]?1[/cci] não vai fazer mais nada, já que o navegador já tem a folha de estilo com o [cci]?1[/cci] em cache. O parâmetro [cci]?1[/cci] pode ser atualizado toda vez que for preciso fazer alguma alteração na folha de estilo, desta forma o cliente terá sempre a versão correta toda vez que ela for atualizada.

Outra saída é usar um parâmetro que nunca será o mesmo, por exemplo: usar a data completa (dia, mês, ano, hora, minuto e segundo). Só que isso fará com que o cliente faça o download do recurso no servidor toda vez que acessar o site, o que pode causar um grande tráfego no servidor, impactando diretamente na performance da sua aplicação. Num captcha faz sentido, mas em outros casos é bom pensar bastante antes.

É isso, dica simples e fácil (e talvez boba), mas que me salvou um dia desses.