O webdeveloper que se preze enfia com o Google Analytics em tudo o que desenvolve; às vezes porque dá jeito, outras por questão de hábito. O que é certo, é que dá mil a zero ao AWStats (embora o AWStats, como corre na própria máquina que está a analisar, dê estatísticas de coisas que o Analytics não consegue – embora haja mais maneiras do gato ir ás filhozes).

Uma das coisas que sempre me fez espécie, é o facto do Google servir o Analytics descomprimido! E isto é mau por vários motivos:

1. Apesar do script, hoje em dia, estar quase sempre morno por ser usado tantas vezes, volta e meia lá calha visitarmos uma página nova ou, sobretudo os webdevelopers, com a cache limpa – quando isso acontece, pega lá 24 kB. Podem dizer que 24 kB, hoje em dia, não é nada, mas…
2. Mas esses 24 kB nem sempre vêm mal se chama! O lado mau do script ser tão conspícuo hoje em dia, é que os servidores do Google não têm mãos a medir para o servir a todos quanto o chamam e/ou os saltos que temos de dar até ao servidor estão entupidos. Não é incomum ver-se uma página bloqueada durante mais de 4 segundos à espera do Analytics, o que me leva ao terceiro ponto;
3. A maneira recomendada pelo Google de se inserir o script deve ser a pior prática de sempre, via document.write(). Como se já não bastasse a tag <script> bloquear a página, a própria instrução que a insere, document.write(), também bloqueia! No dia em que, por qualquer motivo, o script teimar em não vir, temos uma página a carregar para toda a eternidade. Já é a pensar nisso que é recomendada a inserção imediatamente antes do </body>, mas, seja como for, não é agradável ver a página em carregamento durante tanto tempo.

Agora que já bati que chegue, vamos à solução, se é que ainda não deu para perceber pelo título do tópico: alojar o script na mesma máquina do site.

Em primeiro lugar, temos de ir buscar o script ao Google regularmente – eu optei por ser semanalmente, embora pense que o script não deve ser mexido com tanta regularidade. Um pequenino shellscript e respectivo cronjob dão conta do recado:

#!/bin/sh

# onde guardar o script
SAVE=/caminho/para/pasta/javascript/

# url do analytics
URL=http://www.google-analytics.com/ga.js

# user-agent (eu uso o UA do Firefox, mudar à vontade)
UA="Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2"

# vamos mudar de directório para a nossa pasta
cd $SAVE

# efectuar o download
curl --header "Pragma:" -f -s -A "${UA}" -m 1800 --retry 15 --retry-delay 15 --max-redirs 8 -O $URL

# mudar as permissões - dependendo do servidor, podem ser outras
chmod 755 $SAVE/ga.js

# bye bye
exit 0;

O shellscript pode ser criado em qualquer aplicação de texto que deixe mudar o tipo de quebras de linha. Isto é muito importante: o shellscript não corre se o ficheiro tiver quebras de linha “à Windows”, tem de ser “à Unix”. Aconselha-se o TextPad.

O cronjob é criado muito facilmente no cPanel (separador Advanced » Cron jobs » Standard), é só marcar minutos, horas, dia da semana e indicar o caminho até ao ficheiro do shellscript. Quem tem o Plesk (que falta de sorte) pode seguir este tutorial: parte 1, parte 2.

Podemos agora simplificar a inserção do script nas páginas, devido ao alojamento próprio – reparem como faltam duas coisas, a detecção de ligações https (não é necessário, desde que o vosso URL de chamada seja construído respeitando eventuais ligações seguras) e o desgraçado do document.write que inseria o script:

<script src="URL_DO_JAVASCRIPT/ga.js" type="text/javascript"></script>
<script type="text/javascript">
  try{
    var pageTracker = _gat._getTracker("UA-#######-#");
    pageTracker._trackPageview();
  } catch(err) {}
</script>

Finalmente, têm várias opções para servir o ficheiro comprimido: ou definindo globalmente no servidor, ou activando a compressão para ficheiros js via htaccess ou, a minha preferida, passando-o em conjunto com outros scripts necessários pelo Minify.

As diferenças de performance serão notáveis – os vossos internautas agradecem!

Abraços!