Controle de Cache e Versionamento Css/Javascript

Front-end
#1

Olá,

Na minha aplicação estou usando Vraptor 3 e Tomcat 7.0.27.0.

Nesta aplicação estou tentando adicionar Cache para aumentar o desempenho, mas tenho algumas dúvidas.

A 1ª delas, seria qual a melhor forma para adicionar o controle de Cache.

Até agora nos meus testes estou utilizando alguns filters no WEB-INF/web.xml, encontrei essa solução no site do Tomcat http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#Expires_Filter.

Estou fazendo dessa maneira:

[code]
<!-- Expires headers (for better cache control) -->
    
<filter>
    <filter-name>ExpiresFilter</filter-name>
    <filter-class>org.apache.catalina.filters.ExpiresFilter</filter-class>
    <init-param>
        <param-name>ExpiresByType image</param-name>
        <param-value>access plus 10 minutes</param-value>
    </init-param>
    <init-param>
        <param-name>ExpiresByType text/css</param-name>
        <param-value>access plus 10 minutes</param-value>
    </init-param>
    <init-param>
        <param-name>ExpiresByType application/javascript</param-name>
        <param-value>access plus 10 minutes</param-value>
    </init-param>
</filter>

<filter-mapping>
    <filter-name>ExpiresFilter</filter-name>
    <url-pattern>/*</url-pattern>
    <dispatcher>REQUEST</dispatcher>
</filter-mapping>
[/code]

O Cache das Imagens, Css e Javascript está funcionando normalmente. Porém, pesquisando no fórum, achei este post http://www.guj.com.br/java/266614 onde uma outra solução é apresentada.

Entre essas 2 soluções, qual seria a mais adequada?

Minha 2ª dúvida é em relação ao versionamento dos CSS e Javascript.

Quando houver alguma alteração nesses arquivos o Browser deve entender que estes foram modificados e carregá-los do servidor e não mais da Cache do Browser. Pesquisando sobre esse assunto, encontrei em uma das vídeo aulas de Chris Coyier, uma solução proposta por Derek Gathright, onde são utilizados timestamp, algumas configurações no .htaccess e uma função PHP, segue o post http://derek.io/blog/2009/auto-versioning-javascript-and-css-files/. Porém, eu não consegui converter essa solução para o meu caso. Alguém sabe alguma forma de fazer esse versionamento com Tomcat e Vraptor?

Muito obrigado.

#2

Uma solução muito simples seria adicionar um parametro no import do css

Considerando o css:

 <link rel="stylesheet" href="/css/style.css" type="text/css" media="screen" />

Caso tenha feita uma alteração no CSS para forçar o navegador dos usuário recarregar você pode adicionar um parametro:

 <link rel="stylesheet" href="/css/style.css?p=1" type="text/css" media="screen" />

O nome do parametro p pode ser mudado para qualquer coisa e o valor que ele recebe (1) também. Assim caso tenha mudado novamente mude o parametro para 2, 3, etc…

#3

Olá, ayslanms

estava estudando essa solução e encontrei na documentação do html5boilerplate que fica no github deles https://github.com/h5bp/html5-boilerplate/blob/master/doc/htaccess.md um texto dizendo para não usar query string (?v=1) no controle de versão, a explicação está no blog do Steve Souders http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/. Resumindo, no seu blog ele fala sobre o Squid, um proxy popular que não faz cache de arquivos com query string e aponta como melhor solução o timestamp no nome do arquivo.

Por isso, gostaria de manter a solução do meu problema com algo parecido com o apresentando por Derek Gathright, no post http://derek.io/blog/2009/auto-versioning-javascript-and-css-files/, onde são utilizados timestamp, algumas configurações no .htaccess e uma função PHP. Só que aplicando isso no Vraptor 3 e Tomcat 7.

Obrigado!

#4

Ola dhukke, no site do w3eschools.com nao tem que diz respeito a isso?

#5

pesquisei bastante tambem sobre isso e nao encontrei nada!!!

#6

Olá douglascst90,

procurei no site da http://www.w3schools.com/ e só encontrei textos relacionados ao cache com uso do manifest, aqui http://www.w3schools.com/html/html5_app_cache.asp e aqui http://www.w3schools.com/tags/att_html_manifest.asp. Este recurso não é aceito por todos os Browsers mais utilizados, portanto, acredito que não seja uma boa ideia usá-lo.

Obrigado.

#7