Esse pequeno tutorial-guia faz parte do material dos meus cursos de Javascript e Ajax e serve para deixar um histórico acessível aos alunos e fácil para leitores que por ventura precisem.

Preparei um ambiente de execução com todas as dependências no projeto Remendux onde vocês podem fazer checkout e rodar o build ant localmente como um projeto do eclipse – estou usando o plugin para o SVN Subclipse.

Montei um script ant padrão bem simples de ser entendido por iniciantes:

<?xml version="1.0" encoding="UTF-8"?>
<project name="jsmin" default="main" basedir=".">
	<!-- Propriedades para definir nomes de pastas que usaremos -->
	<property name="js" value="js"/>
	<property name="build" value="build"/>
	<property name="lib" value="lib"/>
	<property name="output" value="output"/>
	<!-- Propriedades para definir nomes os arquivos necessários -->
	<property name="yui-compressor.jar"
		location="${lib}/yuicompressor-2.4.2.jar" />
	<property name="yui-compressor-ant-task.jar" 
		location="${lib}/yui-compressor-ant-task-0.3.jar" />
	<!-- Incluir as libs necessárias no classpath -->
	<path id="task.classpath">
		<pathelement location="${yui-compressor.jar}" />
		<pathelement location="${yui-compressor-ant-task.jar}" />
	</path>
	<!-- Definição da task para o Ant reconhecer -->
	<taskdef name="yui-compressor" 
classname="net.noha.tools.ant.yuicompressor.tasks.YuiCompressorTask">
	<classpath refid="task.classpath"/>
	</taskdef>
 
	<target name="clean">
		<delete dir="build"/>
		<delete dir="output"/>
		<mkdir dir="build"/>
		<mkdir dir="output"/>
	</target>
 
	<target name="main" depends="clean">
		<!-- Tag do Ant para concatenar arquivos 
		[ http://ant.apache.org/manual/CoreTasks/concat.html] 
		os arquivos são unidos na sequência de definição 
		no fileset
		-->
		<concat destfile="${output}/remendux.js" force="no">
			<fileset file="${js}/util.js" />
			<fileset file="${js}/remendux.js" />
		</concat>
		<!-- Task do yui-compressor -->
		 <yui-compressor warn="false"  munge="true"  
				preserveallsemicolons="false" 
				fromdir="${output}" todir="${build}">
		</yui-compressor>
	</target>
 
</project>

Após a importação, para executar o script – que chamei de build-yui.xml – basta apenas executar com o ant pelo eclipse – vide imagem abaixo – ou em linha de comando. Estou usando o Ant 7.1 com java 6u10 e Eclipse 3.4, portanto caso haja um erro atente para a versão das ferramentas usadas.

Após executar, observe a redução de tamanho na versão minificada [../build/remendux-min.js] para a versão concatenada [../output/remendux.js ]. A versão final ficou com 30% do tamanho com documentação e identação.

Buildfile: C:\workspace\remendux\build-yui.xml
     [echo] Building output
clean:
    [mkdir] Created dir: C:\workspace\remendux\build
    [mkdir] Created dir: C:\workspace\remendux\output
main:
[yui-compressor]
 [30%] remendux.js [5775] ---> remendux-min.js [1734]
[yui-compressor]
 [JavaScript] Compressed 1 files to 30% (5KB to 1KB, saving 4KB)
[yui-compressor]
 [CSS] No files to compress, or all files already up to date
[yui-compressor]
 Compressed 1 files to 30% (5KB to 1KB, saving 4KB)
BUILD SUCCESSFUL
Total time: 12 seconds

Fábio Kung publicou no blog da Caelum sobre os problemas enfrentados pelo GUJ (maior e melhor fórum sobre Java e arquitetura de software do Brasil) de quedas e lentidão. Há poucos dias o Diego Plentz também publicou sobre experiência recente, até citando o artigo do Kung e dando explicações sobre as mudanças necessárias que teve que realizar nas aplicações durante a mudança do Tomcat para o Jetty.

Na Java Magazine desse mês, edição 61, o autor OSVALDO PINALI DOEDERLEIN – no artigo denominado “WTP 3.0 – Novidades do Ganymede para desenvolvimento Java EE” – escreveu no quadro: “Glassfish? Por que não Tomcat ou JBoss?”, o seguinte sobre o Tomcat:

O projeto Apache Tomcat não me parece ir bem. O Tomcat 6 (versão atual) só teve dois builds estáveis: o release inicial de 2007 e um único update. Houve defecção de colaboradores importantes “como pessoal da Sun, realocado para o Glassfish quando este começou a levantar vôo, e para outros projetos como o LWUIT. Tecnologicamente o Tomcat parou no tempo há um par de anos. Fez a opção de reusar o APR (biblioteca de código nativo do Apache HTTPD), ao invés de investir forte no caminho “puro Java” de APIs como java.nio – opção que o Glassfish provou ser superior. Não tem havido atualizações de correção & segurança com a regularidade que considero necessária para software dessa natureza. Continuo considerando o Tomcat uma boa opção apenas para ambientes onde toda a comunicação HTTP tem que passar pelo Apache HTTPD.

….

É interessante observar que o Tomcat é o container web embutido no JBoss, e o JBoss é outro colaborador importante do projeto Tomcat. O que possivelmente indica que as dificuldades de ambos os projetos possam estar relacionadas.

Com a onda crescente do Jetty sobre a base instalada do Tomcat é possível que nos próximos meses os retardatários movam seus sistemas jogando a última pá de terra.

E vocês? Já estão usando o Jetty em alternativa ao Tomcat?

<script … src=”script1.js”></script>
<script … src=”script2.js”></script>
<script … src=”script3.js”></script>

Nesse caso teremos 3 requisições além da página e sofreremos um aumento de até 50% no tempo de renderização. Isso porque apesar do tamanho dos arquivos serem o mesmo se fossem internos, as múltiplas requisições provocam um overhead.

Ao invés dessa abordagem, se os scripts fossem internos, existiria uma única requisição HTTP e o tempo de renderização seria mais rápido.

O problema na abordagem de scripts internos é que não nos beneficiamos do cache.

Combinando os scripts

Uma alternativa é combinar todos os scripts para forçar apenas uma requisição e se beneficiar do cache.

Aliando a minificação do código, você reduz consideravelmente o tamanho do download do script. Observe que frameworks como o Extjs usam essa técnica, existe um arquivo ext-all.js que combina todos os componentes.

Para páginas que combinam um grande número de componentes e sofrem de elevado “Page Views“, é crucial o cache desses elementos em um único arquivo se beneficiando de poucas requisições HTTP e do uso do cache.

O problema nessa abordagem é que existem regiões com elevado “Page Views” que usam poucos componentes e tem que baixar todo o arquivo de uma só vez.

Download sob demanda

O melhor dos dois mundos é usar a estratégia de “Post-Onload Download” para os casos onde não há necessidade de baixar um script externo com todos os componentes. Nesse caso usamos a estratégia de Script tag e baixamos apenas os módulos necessários a determinada região do sistema. O código do sistema será dividido em módulos.

var head = document.getElementsByTagName("head")[0];
var script = document.createElement('script');
script.id = 'ScriptOnDemand';
script.type = 'text/javascript';
script.src = url;
head.appendChild(script);

Lembrando que essa técnica provoca uma aumento não só do esforço no desenvolvimento (porque você terá que administrar as dependências entre os componentes manualmente) como do tempo de manutenção no código (por dividir os scripts em módulos apropriados).

Conclusão

Faça poucas requisições HTTP para uma mesma página. Diminua sempre o número de requisições unindo todos os scripts em um único arquivo.

Caso o arquivo seja grande para uma página, adote a estratégia de subir os arquivos sob demanda.

A recomendação da estratégia adotada vai depender da métrica de cada região do seus sitema e do custo de esforço na administração desse código.