Existem várias formas de se aumentar a performance de uma aplicação web, e quando eu falo aplicação web o mesmo se aplica a sites. Uma das formas mais eficientes de lidar com performance é concentrar esforços para aumentar a sensação de carregamento instantâneo da sua aplicação.

Steve Souders escreveu um livro excelente chamado: High Performance Websites e nele, Steve, falou algo que me chamou muita atenção:

“Na maior parte da minha carreira em Internet, fui engenheiro de back-end. Como tal, eu diligentemente atacava cada projeto de performance como um exercício em otimização de back-end, me concentrando em opções de compilação, índices de bases de dados, gerenciamento de memória, etc. Existe muita atenção e vários livros dedicados a otimização performance nessas áreas, então é nelas que a maioria das pessoas emprega seu tempo, procurando melhorias. Na realidade, para a maioria das páginas de Internet, menos de 10% a 20% do tempo de resposta experimentado pelos usuários finais é gasto trazendo o documento HTML do servidor para o browser. Se você quer redurzir dramaticamente os tempos de resposta de suas páginas, tem de se concentrar nos restantes 80% a 90% da experiência do usuário final. No que sesses 80% a 90% são empregados?”

Umas das regras para se otimizar o carregamento de uma interface web, talvez uma das mais importantes, é diminuindo o número de requisições HTTP que esta interface está fazendo.

Existem diversas técnicas para se reduzir o número de requisições HTTP de uma aplicação web, porém, a que vamos abordar hoje é somente um pequeno pedaço deste trabalho, porém, uma parte muito importante dele.

A negligência e o cache.

Existe uma negligência muito grande por parte dos programadores e engenheiros com relação ao cache. Não podemos simplesmente cachear tudo e todos. Existe um nível de importancia que deve ser empregado para cada tipo de mídia que estamos cacheando. Vai de negócio para negócio, Na aplicação X os arquivos javascript podem não ser muito importante mas os arquivos mp3 são importantíssimos e vice-versa. É muito importante darmos o tempo certo de vida para cada tipo de mídia sempre olhando para o nosso negócio.

Botando a negligência de lado, por quê o cache é importante? para evitar que o usuário pague o preço. Para que ele baixe somente o que é necessário.

Diretivas .htaccess para cache

# 1 ANO
<FilesMatch "\.(ico|pdf|flv)$">
Header set Cache-Control "max-age=29030400, public"
</FilesMatch>
# 1 SEMANA
<FilesMatch "\.(jpg|jpeg|png|gif|swf)$">
Header set Cache-Control "max-age=604800, public"
</FilesMatch>
# 2 DIAS
<FilesMatch "\.(xml|txt|css|js)$">
Header set Cache-Control "max-age=172800, proxy-revalidate"
</FilesMatch>
# 1 MINUTO
<FilesMatch "\.(html|htm|php)$">
Header set Cache-Control "max-age=60, private, proxy-revalidate"
</FilesMatch>

Veja que é possível darmos um tempo de “vida” do cache de um arquivo de acordo com a sua extensão. É importante ressaltar que os tempos que foram dados no exemplo acima é somente um exemplo. Como eu disse acima, é importante você colocar na balança o que é mais importante para o seu negócio.

.htaccess Time Cheatsheet

# TIME CHEAT SHEET
#      300   5 MIN
#      600  10 MIN
#      900  15 MIN
#     1800  30 MIN
#     2700  45 MIN
#
#     3600   1 HR
#     7200   2 HR
#    10800   3 HR
#    14400   4 HR
#    18000   5 HR
#    36000  10 HR
#    39600  11 HR
#    43200  12 HR
#    46800  13 HR
#    50400  14 HR
#    54000  15 HR
#    86400  24 HR
#
#    86400   1 DAY
#   172800   2 DAY
#   259200   3 DAY
#   345600   4 DAY
#   432000   5 DAY
#   518400   6 DAY
#   604800   7 DAY
#
#   604800   1 WEEK
#  1209600   2 WEEK
#  1814400   3 WEEK
#  2419200   4 WEEK
#
#  2419200   1 MONTH
#  4838400   2 MONTH
#  7257600   3 MONTH
#  9676800   4 MONTH
# 12096000   5 MONTH
# 14515200   6 MONTH
# 16934400   7 MONTH
# 19353600   8 MONTH
# 21772800   9 MONTH
# 24192000  10 MONTH
# 26611200  11 MONTH
# 29030400  12 MONTH

Se este snipet não funcionar (o que é bem improvável) você pode utilizar este snipet em conjunto com a extensão mod_expires do apache.

<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault A300
ExpiresByType image/x-icon A2592000
ExpiresByType application/x-javascript A3600
ExpiresByType text/css A3600
ExpiresByType image/gif A604800
ExpiresByType image/png A604800
ExpiresByType image/jpeg A604800
ExpiresByType text/plain A300
ExpiresByType application/x-shockwave-flash A604800
ExpiresByType video/x-flv A604800
ExpiresByType application/pdf A604800
ExpiresByType text/html A300
</IfModule>

O legal de se utilizar o mod_expires é que ele trata o a questão do cache de acordo com o mime-type de cada arquivo e não somente pela extensão.

Tá, mais, é o ideal gerenciar desta forma?

Não. Existem formas mais inteligentes de gerenciar as mudanças dos seus arquivos e fazer com que eles sejam baixados novamente pelo navegador do usuário somente quando ele realmente for atualizado, porém, esta é uma forma um pouco mais “custosa” e eu certamente irei falar com mais profundidade sobre isso em um próximo post.

Conclusão

Podemos minimizar o número de requisições HTTP de nossa aplicação gerenciando de forma mais inteligente os arquivos que estamos incorporando dentro de nossa aplicação web utilizando recursos simples e nativos do nosso apache, como o exemplificado aqui. Esta não é a forma mais eficiente, mas com certeza, vai ajudar muito a minimizar o número de requisições HTTP que sua aplicação web fará nas nas próximas paginas que seu usuário for navegar.

javascript freak, php lover, zend certified engineer, ruby programmer wannabe, ruby developer at Editora Abril, musician and skater at free time.

Twitter LinkedIn 


Posts Relacionados:

  • Nenhum post relacionado!