Estava eu ontem, todo *feliz*, analisando as estatísticas de acesso de uns sites feitos (e hospedados) na empresa pra qual trabalho. Bacana, vendo acessos de browsers, horas de pico, resolução de tela, tráfego de arquivos e…
Perae! 45% do tráfego mensal era de javascript. Num site sem absolutamente nada de ajax ou efeitos ou coisas do gênero.
Encafifei: o quê estaria acontecendo?
Simples: esqueceram de ligar o filtro de compressão gzip para arquivos css/javascript.
Vejo por aí que muita gente não conhece isso, e fica proecupado em tirar todos os tabs e espaços dos arquivos html, css e javascript. Usa aqueles aplicativos que diminuem o código javascript, colocando tudo na mesma linha. E acabam com qualquer tabulação no CSS.
Tudo isso era válido 5 anos atrás. Hoje em dia, existe uma forma mais adequada de fazer diminuir o consumo de banda quando arquivos desse gênero são requisitados.
Explicando como os browsers funcionam: ao fazer uma solicitação de um URL, quando essa chega no servidor de destino, a primeira coisa a acontecer é passar pelo webserver. Esse cara tenta pegar os arquivos requisitados (html, imagens, css, js, etc…) e, em caso de sucesso (status 200) devolve pra quem os requisitou.
*isso tudo é uma simplificação beeem simplificada do fluxo, conforme pode-se ver no diagrama abaixo:
Bem, um novo passo nesse fluxo foi adicionado com a evolução tanto dos browsers, quanto dos webservers quanto do protocolo HTTP.
Os browsers hoje em dia, bem como o webserver, têm a capacidade de comprimir e descomprimir dados usando o gzip (como se fosse um .zip). Quando o browser faz uma solicitação de uma URL, ele manda um header com dados referentes à solicitação e a ele mesmo (qual a versão, tipo, etc…). Com isso, o webserver consegue saber se esse browser suporta compressão de arquivos. Se o webserver estiver configurado, ele pode fazer a compressão de arquivos html, css, js, ou de qualquer outro formato de arquivo.
Fazendo testes aqui, a diferença de tamanho de arquivo para html/css/js chegou a 90% em alguns casos. Imagine que se você usa algum framework js (a jQuery tem uns 100kB, a Prototype está com 120), a cada requisição de um usuário que não está com esses arquivos no cachê pode ser de 90kB – okey, vamos arredondar para 80kB. Se 100 pessoas acessam por dia, dá 8mB; ou, 240mB por mês.
Agora, imagine num site com milhares de pageviews…
Na net, existem muitos links explicando como configurar o seu webserver (ISS, Apache) para cada tipo de arquivo, como esses aqui:
Compressão de html com o Apache: http://betterexplained.com/articles/how-to-optimize-your-site-with-gzip-compression/
Compressão de CSS/js com o Apache: http://blog.joshuaeichorn.com/archives/2007/01/10/compressing-javascript-and-css/
Verificar a taxa de compressão: http://www.gidnetwork.com/tools/gzip-test.php
Enjoy 😉