Sim, este post tratará sobre estes três assuntos: HTML5 + CSS3 (+Javascript), interoperabilidade entre sistemas Java e .NET (não necessariamente C#) e Windows Phone 7, mas não, não serão ao mesmo tempo, hehehe. Neste final de ano o pessoal da Microsoft Brasil resolveu suar a camisa e nos entregar uma série de treinamentos gratuitos para capacitar os desenvolvedores de suas plataformas melhor. O post é breve, afinal ninguém quer ficar lendo nerdices em plena véspera de Natal, exceto eu é claro...

HTML5 &  Javascript Center

A Microsoft criou um hotsite chamado HTML5 & Javascript Center, onde dão muitas informações sobre como utilizar HTML5, CSS3 e Javascript juntos para criar páginas web ainda melhores. O site já contém muito material, incluindo tutoriais simples como uso da tag Áudio e Vídeo até coisas mais complexas como manipulação da tag Canvas (o canivete suíço do HTML5). Além disso, boa parte desse material está em Português, e mesmo o material em inglês é fácil de entender (afinal HTML é HTML em qualquer idioma...). O site também contém links de referências e está muito bem organizado por categoprias. Vale a pena conferir no http://msdn.microsoft.com/pt-br/hh442325.

Interoperabilidade entre Java e .NET

Desde que venho acompanhando a comunidade em torno da Microsoft Brasil em 2008, pude notar que uma postura que se instaurou na cia. é a de interoperabilidade de plataformas. Ultimamente a Microsoft tem lançado cada vez mais soluções interoperáveis, como seu Hyper-V e SCVMM para Linux, WebMatrix para PHP, TFS para Eclipse, Azure para PHP, Java, etc; material dedicado a HTML5 + CSS3 (existe algo mais interoperável que uma página HTML?), disponibilização de fontes para o pessoal do projeto Mono e Moonlight e por aí vai. Isto foi uma atitude muito inteligente do novo CEO Steve Ballmer, que tem atraído mais união entre os desenvolvedores de diferentes plataformas.

Dentro desta mesma linha, recentemente a Microsoft Brasil colocou no ar uma nova página dentro de seu famoso Centro de Treinamento (que eu já citei em outro post): Interoperabilidade entre Java e .NET. Todo mundo que está no mercado a alguns anos e já trabalhou em algumas empresas diferentes sabe que hoje Java e .NET são os bam-bam-bams do mercado mundial de software. As maiores cias. de software do mundo desenvolvem em tais tecnologias e os maiores salários do mercado são ofertados para analistas e desenvolvedores das mesmas. Parece que esse panorama não irá mudar nem mesmo com a crescente das aplicações móveis, uma vez que você pode continuar usando Java e .NET para programar para Android e iOS.

Mas voltando ao assunto da página, acesse http://msdn.microsoft.com/pt-br/hh314025, lá você encontra tutoriais em português sobre o funcionamento das arquiteturas (que são muuuito parecidas), sobre como fazer serviços Java conversarem com .NET e o inverso, como utilizar WCF e Glassfish e inclusive como colocar JEE na nuvem do Azure!

Windows Phone 7

E a minha notícia favorita de final de ano: uma página novinha em folha no Centro de Treinamento somente sobre Windows Phone 7 e 100% em português! Lembram-se de meu post anterior sobre Windows Phone 7, onde falei sobre os vídeos existentes no Channel 9, com o Bob Tabor? Pois é, agora temos a nossa versão tupiniquim e com ótimo conteúdo. Acesse http://msdn.microsoft.com/pt-br/hh230679 e veja uma gama completa de conteúdos como instalação do ambiente, Silverlight, XNA, deploy, debug, app lifeycle, gestos, orientação, themes, globalization, SQL Server Compact (toma SQLite!), GPS e por aí vai.

Resta saber se a parceria Microsoft + Nokia vai emplacar o WP7 na terra do Blanka, uma vez que nossa carga tributária é altíssima e fica difícil concorrer com o Android, que possui aparelhos em torno de R$500. Mas já é bom ir se adiantando, não é mesmo?

O post de hoje é algo que muitos desenvolvedores não fazem nem idéia que é possível: conectar e utilizar planilhas Excel como se fosse um banco de dados, e não estou falando de CSV. Sim, isso mesmo, ao invés de ficar armazenando em flat-files (os populares TXT com marcações) você pode utilizar o Excel para trabalhar como se fosse um autêntico banco de dados...Ok, eu é que não vou ficar fazendo apologia ao uso de Excel ao invés de um SGBD de verdade. O real intuito deste post é ensinar como consumir os dados existentes em uma planilha de terceiros. Muitas vezes há a necessidade de utilizar dados de planilhas legadas para importar em sua base de verdade, ou então você pode precisar desenvolver um sistema que agregue dados de planilhas diferentes em um único banco e por aí vai.

A Conexão

Obviamente, o primeiro passo é se conectar na dita planilha. E é aqui onde a maioria dos desenvolvedores se quebra pois esta etapa possui algumas particuliaridades. Em primeiro lugar, como toda conexão com base de dados você precisará utilizar classes do ADO.NET, o framework de acesso a dados da plataforma .NET. No caso do Excel, a melhor opção é utilizarmos uma conexão OLE DB. Para quem não sabe, OLE DB (Object Linking and Embedding DataBase) é uma API desenvolvida pela Microsoft para acesso a dados de forma nativa no Windows, via COM. Pois bem, através de OLE DB, podemos acessar dados em Access e Excel. Quando o assunto é Access, a melhor alternativa é utilizar ODBC, mas com Excel, OLEDB é uma boa opção. Como de praxe, você precisará importar a biblioteca System.Data e instanciar um OleDbConnection conforme mostrado abaixo:

using System.Data;
var _conexao = new OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;Data Source=planilha.xls;Extended Properties='Excel 8.0;HDR=YES;'");
_conexao.Open();

A string de conexão determina o provedor a ser utilizado na conexão (no meu exemplo, a API OLE DB versão 4.0, nativa do Windows), a fonte dos dados (basicamente o caminho completo até a planilha, no meu exemplo, ela se encontra na mesma pasta do programa) e algumas propriedades específicas da conexão, como a versão do Excel a (8.0) e se a planilha possui cabeçalho (HDR = Header = Cabeçalho). A string de conexão OLE DB é muito sensível, então muita atenção à sua escrita, erros comuns incluem escrever 'DataSource' ao invés de 'Data Source', ou então usar uma versão de Excel errada. Outro erro muito comum é colocar a propriedade de cabeçalho fora da string 'Extended Properties' (note que a versão do Excel e a informaçãod e cabeçalhos existentes estão entre aspas). Qualquer erro em sua string de conexão irá gerar o erro "Não foi possível encontrar ISAM instalável." que é algo extremamente genérico e sem muita utilidade.

 

A Consulta

Uma vez que a consulta foi instanciada, agora podemos executar comandos sobre a planilha à qual nos conectamos. Você já deve ter utilizado mais de uma planilha em uma mesma pasta do Excel, não é mesmo? E como você fazia para se organizar? Colocava nomes nas planilhas, certo? É isso mesmo! Imagine a sua pasta do Excel como seu "banco de dados" e cada planilha dentro da pasta como suas "tabelas". E como você faria uma consulta no SQL Server sobre uma tabela do seu banco? 'SELECT * FROM Tabela'? E é isso mesmo que você vai fazer! Dê uma olhada no código abaixo, onde usamos o OleDbCommand para realizar consultas no banco:

var cmd = new OleDbCommand("SELECT * FROM [tabela$]", _conexao);
var dt = new DataTable();
dt.Load(cmd.ExecuteReader());

O código acima é auto-explicativo, é simplesmente a instanciação de um OleDbCommand passando um comando pseudo-SQL (na verdade o nome disso é MS Query) e a conexão instanciada no passo anterior. As linhas seguintes já são corriqueiras a todo programador que já tenha utilizado ADO.NET para se conectar a um banco de dados, a consulta é executada retornando um DataReader, que por sua vez é carregado em um DataTable, para posterior utilização. Preste apenas atenção no fato de que a "tabela" do Excel é delimitada entre colchetes e SEMPRE deve terminar com um cifrão. Não me pergunte o porquê, eu realmente não sei, hehehehe.

Sistema de Exemplo

Logo abaixo você encontra um link para download de um sistema de exemplo, onde criei uma classe Excel, que encapsula toda a lógica de acesso à planilhas, abstraindo do desenvolvedor a necessidade de conhecer detalhes específicos de sua implementação. Use do jeito que quiser, afinal este código eu montei com base em outros da Internet mesmo, hehehehe. Neste mesmo ZIP você encontrará uma planilha de exemplo para usar em seus testes (algum gamer de plantão reconhece os dados da planilha?) e um sisteminha desktop feito em .NET 4 que permite a você conectar em sua planilha preferida e realizar consultas sobre ela, vendo os resultados em um DataGrid. A idéia não era criar um "Excel Management Studio" ou algo do gênero, por isso a aplicação não é laáááá muito útil, mas serve para seu propósito que é ilustrar a utilização de Excel como base de dados e completar o post. Espero que seja útil!

ExcelConnection.zip (50,33 kb)

Já me deparei com esse erro algumas vezes durante meus anos de experiência com web e quase sempre ele traz consigo uma confusão tremenda pois à nível de protocolo HTTP, ele pode siginificar uma infinidade de coisas. Entretanto, quando estamos falando de sites dinâmicos que rodam no lado do servidor, como ASP.NET, as causas são mais simples (e infelizmente mais comuns do que se imagina) de serem mitigadas e não devem causar espanto em programadores de qualquer nível, bastando um pouco de atenção aos detalhes.

O que é?

O browser cliente estava conectado com o servidor e por algum motivo esta conexão foi interrompida subitamente, seja por decisão de um lados ou uma falha no meio de comunicação.

O que tem a ver com meu código?

Quando você desenvolve código que derruba a pilha de memória do processo que está executando sua aplicação, esse erro ocorre pois o servidor não esperava por isso e o processo é encerrado.

Como resolvo?

Basta reescrever o código que está causando o estouro da pilha. Simples assim. Ok, como eu não sou tão sádico, aqui vão algumas dicas para ajudar a tornar esta tarefa mais fácil:

Em primeiro lugar, qual foi a última alteração que você realizou no código antes desse problema começar a acontecer? Qualquer coisa, por mais inofensiva que pareça pode ocasionar isso, principalmente aqueles códigos que você escreveu e colocou direto no ar, sem testar, porque eram muito triviais.

Enumere as alterações que fez e uma a uma, e vá revisando seu código. Você deve revisar principalmente os algoritmos que envolvem um ou mais casos abaixo:

• algoritmos recursivos (i.e. métodos que chamam eles mesmos)
• laços de repetição (principalmente while, que é mais fácil de dar problema)
• sobrecarga de operadores (muito úteis para objetos, mas perigosos também)
• palavra reservada "goto" (evite usar, afinal não estamos programando em Assembly...)
• tratamento de erros (try/catch) que tentam refazer a tarefa que deu errado

Essas dicas cobrem mais de 90% dos casos mais comuns de "Connection reset by peer" causados por mau funcionamento de código.

Como prevenir?

Pode parecer óbvio, mas para alguns programadores não é: teste. Nunca mande nada para produção sem testar antes, e de preferência, de forma unitária, isto é, somente o método que foi alterado, de forma independente do restante do sistema. Obviamente se você usar TDD, será muito fácil identificar os problemas logo que eles são desenvolvidos e antes de ir para o ar, pois esse tipo de erro não passaria nos testes automatizados.

Espero ter ajudado, e se alguém salvou o seu pescoço por causa desse post, não me importo se agradecerem nos comentários!

Antes de me tornar desenvolvedor (amador) de Lua com Corona SDK eu já desenvolvi em diversas outras linguagens, como Java, C#, VB.NET, C/C++ e por aí vai. Uma das coisas que prezo muitos nas linguagens que escolho para trabalhar (principalmente as que compõem a plataforma .NET) é a produtividade. As linguagens de programação são criadas para facilitar a vida do desenvolvedor e não para complicá-la, caso contrário todos programaríamos em Assembly, ou até mesmo em binário!!! Entretanto, mesmo a mais humana das linguagens de programação se torna extremamente complicada de utilizar, principalmente nos estágios iniciais, sem uma boa IDE, uma ferramenta de desenvolvimento com editor de código e geralmente função autocomplete, aquele famoso recurso da IDE lhe sugerir funções existentes na API conforme a palavra que você digitou (conhecido entre o pessoal do .NET como Intellisense). O post de hoje é curto mas tenho certeza que vai ajudar muita gente que está dando os primeiros passos com Lua + Corona SDK e até mesmo os desenvolvedores mais veteranos que buscam mais produtividade no desenvolvimento de seus games para iPhone, iPad e Android.

Primeiro Passo: Baixe e instale o interpretador Lua e o Corona SDK

Eu já escrevi um post sobre esse assunto, então não serei repetitivo. Leia-o antes de continuar.

Segundo Passo: Baixe e instale o IntelliJ Community Edition

O IntelliJ é uma IDE semelhante ao Eclipse, permitindo aos desenvolvedores utilizarem-no para várias linguagens, sendo extensível assim como seu concorrente. Ele pode ser encontrado para download no site do fabricante, a JetBrains.

No site da JetBrains você terá duas opções de download, a paga e a gratuita. Sinceramente não sei as diferenças, mas a gratuita está me dando benefícios que meu editor de código Lua anterior, o Scite, nem sonhava em me proporcionar. Então, baixe a gratuita mesmo.

Depois de baixar, instale-o normalmente.

Terceiro Passo: Baixe e configure o plugin do Lua

Como eu mencionei anteriormente, o IntelliJ é extensível através de plugins. Alguma alma caridosa desenvolveu um plugin para o intelliJ suportar o Lua. Este plugin pode ser baixado no site oficial do IntelliJ.

Este plugin não é um executável, é um zip que deve ser extraído. Copie a pasta IDLua para dentro da pasta de plugins do IntelliJ, localizada normalmente em C:\Arquivos de Programas\JetBrains\IntelliJ IDEA Community Edition xxx\plugins\.

Para configurar o plugin é simples: basta abrir o IntelliJ pelo menu Iniciar, ir no menu File, opção Settings e na esquerda vá em IDe Settings -> clique em Lua (irá aparecer somente se você colou a pasta no lugar certo). Na direita marque as duas opções.

Quarto Passo: Configurando o IntelliJ para usar o Corona SDK

Os passos anteriores permitiram que você pudesse desenvolver em Lua no IntelliJ. Mas mais do que isso, queremos usar a ferramenta para aumentar a nossa produtividade no desenvolvimento de games para iOS e para o sistema móvel do Google. Ou seja, ainda temos de configurar o IntelliJ para suportar o Corona SDK! Através de ferramentas fornecidas pelo própria Ansca, fabricante do Corona, a mesma alma caridosa que desenvolveu o plugin (ainda bem que o mundo tem uma meia dúzia delas!) mapeou a Api do Corona e criou uma biblioteca para o IntelliJ suportar nosso SDK mobile favorito! O pseudônimo desta alma caridosa é sylvanaar2 e o link para download do mapeamento da API está no BitBucket (a interface desse site é uma porcaria, então clique em "Get Source", na direita da página para fazer download no formato zip).

Uma vez que tenha baixado a API do Corona para o intelliJ, extraia o zip para uma pasta do seu computador que você saiba que não será apagada. uma boa idéia é copiar para dentro da pasta do IntelliJ, afinal, você sempre irá usar os dois juntos. Já, já vamos usar essa API dentro do IntelliJ, porém esta configuração deve ser feita para cada projeto (ou eu fui burro o suficiente para não descobrir outra forma).

Último Passo: Criando seu primeiro projeto Corona no IntelliJ

Toda vez que você for criar um novo game/app para dispositivos móveis com o IntelliJ, basta criar um novo projeto (File -> New Project) no IntelliJ, selecionar o plugin do Lua e, depois que o projeto for criado, clique com o botão direito do mouse sobre o ícone da raiz do projeto e vá em "Open Module Settings" (pode atalhar apertando F4) para ir nas configurações do projeto. Vá em SDKs e clique na direita para adicionar um novo classpath ao seu projeto, bastando navegar pelas pastas do seu computador e marcar a pasta baixada no passo anterior, comumente com o nome "sylvanaar2-idlua-sdk-corona-alguma-coisa". Cliquem em Apply e Ok.

Pronto, agora você está preparado para desenvolver seus jogos para as principais plataformas mobile do mercado com muito mais produtividade e capacidade de gerenciamento do projeto. Para os novatos, a tarefa de dominar o SDK se tornará muito simples também, graças ao recurso de auto-completar do IntelliJ. Outra dica quando se trabalha em grandes equipes é utilizar algum sistema de versionamento de código, como o Subversion por exemplo, mas isto fica para outro post :)

Comentem suas experiências com o IntelliJ, dicas de produtividade, quais ferramentas que vocês utilizam para programar em Lua, etc. Vamos trocar idéias!

Andei meio sumido, mas para compensar, o post de hoje traz inúmeras dicas de como aumentar a performance dos seus sites, independentes de qual plataforma eles executam ou em qual linguagem eles são desenvolvidos. No final das contas tudo vira HTML e a comunicação é feita via protocolo HTTP. Existem muito mais dicas do que as apresnetadas aqui, listei apenas as de uso mais comum e que se aplicam à maioria dos sites. Muitas destas dicas somente fazem efeito quando seu site possui um número expressivo de acessos, então não espere que seu blog desconhecido mostre sinais de super desempenho ao utilizar quaisquer das dicas abaixo. As dicas estão divididas em categorias:

Reduza as requisições HTTP

80% do tempo de resposta ao usuário final é gasto na apresentação do site (front-end). A maioria deste tempo é peridod baixando todos os componentes na página: imagens, folhas de estilo, scripts, Flash, etc. Reduzindo o número de componentes reduz por sua vez o número de requisições HTTP necessárias para renderizar a página. Esta é a chave para páginas mais velozes.

Uma vez que você reduza o número de componentes na página você estará simplificando o projeto da mesma. Mas existe alguma maneira de criar páginas com conteúdo rico enquanto mantém tempos curtos de resposta? Existem algumas técnicas para reduzir o número de requisições HTTP, enquanto se preserva os projetos de páginas ricas.

Arquivos combinados são uma maneira de reduzir o número de requisições HTTP combinando todos os scripts em um único arquivo de scripts, e similarmente combinando todos os CSS em uma única folha de estilos. Combinar arquivos é bem desafiador quando os scripts e folhas de estilo variam de página para página, mas fazê-lo antes de lançar seu site vai melhorar o tempo de resposta das páginas.

CSS Sprites são o método preferido para reduzir o número de imagens requisitadas. Combine suas imagens de fundo em uma única imagem e use as propriedades de CSS background-image e background-position para exibir o segmento desejado da imagem.

Image maps combinam múltiplas imagens em uma única imagem. O tamanho total será o mesmo, mas reduzirá o número de requisições HTTP, acelerando a página. Image maps somenete funcionam se as imagens são contíguas na página, como uma barra de navegação. Definir as coordenadas de image maps pode ser monótona e com chance de erro. Usar image maps para navegação não é acessível também, logo não é recomendado.

Inline images usam o esquema data: URL para embutir os dados da imagem na página atual. Isto pode aumentar o tamanho de seu HTML. Combinar inline images dentro de suas folhas de estilo (armazenadas em cache) é uma maneira de reduzir as requisições HTTP e prevenir o aumento de tamanho de suas páginas. Inline images tamabém não são suportadas na maioria dos browsers.

Reduzir o número de requisições HTTP na sua página é a primeira coisa a se fazer quando o assunto é performance. É a parte mais importante de uma otimização de desempenho quando estamos falando de visitantes de primeira viagem. Os números de diversas pesquisas indicam que 40-60% dos visitantes diários de seu site estão com o cache vazio. Tornar a sua página rápida para estes visitantes de primeira viagem é a chave para uma melhor experiência do usuário.

Utilize os cabeçalhos Expires e Cache-Control

Existem dois aspectos para esta regra:

• Para componentes estáticos: implemente a política "Never expire" configurando o cabeçalho Expires para um futuro distante
• Para componentes dinâmicos: use um cabeçalho Cache-Control apropriado para ajudar o browser com requisições condicionais

Projetos de Web pages estão se tornando cada vez mais ricos, o que significa mais scripts, folhas de estilo, imagens e animações na página. Um visitante de primeira viagem que chegar na sua página terá de realizar diversas requisições HTTP, porém utilizando o cabeçalho Expires você pode tornar estes componentes armazenáveis em cache. Isto previne requisições HTTP desnecessárias em visualizações de página subsequentes. Os cabeçalhos Expires são muitas vezes utilizados com imagens, mas eles devem ser usados em todos componentes incluindo scripts, folhas de estilo e componentes Flash.

Browsers (e proxies) usam cache para reduzir o número e tamanho das requisições HTTP, tornando o carregamento das páginas mais rápido. Um webserver utiliza o cabeçalho Expires na resposta HTTP para dizer ao cliente por quanto tempo um componente pode ser armazenado em cache. Este é um cabeçalho com expiração muito distante, dizendo ao browser que esta resposta não deve ser removida de cache até 15 de abril de 2012.

      Expires: Sun, 15 Apr 2012 20:00:00 GMT

Se o seu servidor é Apache, use a diretiva ExpiresDefault para definir uma data de expiração relativa à data atual. Este exemplo de diretiva ExpiresDefault define a data de expiração para daqui a 10 anos, a partir do instante da requisição.

      ExpiresDefault "access plus 10 years"

Tenha em mente, se você usar um cabeçalho para expiração futura você terá de trocar o nome do arquivo do componente toda vez que o componente for alterado. Geralmente as empresas o fazem como parte do processo de lançamento de uma nova versão do site: um número de versão do arquivo é incluído no nome do arquivo, por exemplo, luiztools_2.0.6.js.

Usar um cabeçalho de expiração futura afeta somente as visualizações de página feitas depois da primeira visita do usuário ao seu site. Não há efeito algum quando o usuário visita seu site pela primeira vez e o cache do browser está vazio. Entretanto o impacto desta melhoria de performance depende de quantas vezes os usuários acessam suas páginas com o cache cheio. Através do uso do cabeçalho Expires, você aumenta o número de componentes que são armazenados em cache pelo browser e re-utiliza em subsequentes visualizações de página sem enviar um único byte através da conexão de Internet.

Componentes GZip

O tempo de transferir uma requisição e uma resposta HTTP pela rede pode ser significativamente reduzido por decisões feitas no front-end do webmaster. É verdade que a largura de banda do usuário-final, provedor de Internet, proximidade dos roteadores, etc. estão além do controle do time de desenvolvimento. mas há outras variáveis que afetam os tempos de resposta. A compressão reduz os tempos de resposta diminuindo o tamanho da resposta HTTP.

Iniciando com HTTP/1.1, os clientes web indicam suporte à compressão com o cabeçalho Accept-Encoding na requisição HTTP.

 

Accept-Encoding: gzip, deflate

Se o servidor web vê este cabeçalho na requisição, ele pode comprimir a resposta usando um dos métodos listados pelo cliente. O servidor web notifica o cliente web disto via cabeçalho Content-Encoding na resposta.

 

      Content-Encoding: gzip

Gzip é o método de compressão mais popular e efetivo atualmente. Ele foi desenvolvido pelo projeto GNU e padronizado pela RFC 1952. Outro método de compressão existente é o deflate, mas ele é menos eficiente e menos popular.

Gzipar geralmente reduz o tamanho da resposta em cerca de 70%. Aproximadamente 90% do tráfico atual de Internet que viaja através dos browsers suportam gzip. Se você usa Apache, o módulo de configuração do gzip depende de sua versão: Apache 1.3 usa mod_gzip enquanto Apache 2.x usa mod_deflate.

Existem problemas conhecidos com browsers e proxyies que podem causar problemas com compressão HTTP, felizmente estes problemas estão restritor à usuários de browsers antigos.

Servidores escolhem o que será comprimido, baseado no tipo de arquivo. tipicamente eles são bem limitados e a maioria dos sites somente zipa seus documentos HTML. Também é possível zipar seus scripts e stylesheets, mas muitos sites perdem essa oportunida. Na verdade é possível comprimir qualquer texto incluindo XML e JSON. Imagens e arquivos PDF não devem ser zipados porque eles já estão em formatos comprimidos. Tentar diminuir ainda mais seu tamanho não somente irá gastar CPU à toa como pode aumentar o tamanho dos arquivos.

Gzipar todos os arquivos possíveis é uma maneira fácil de reduzir o peso das páginas e acelerar a experiência do usuário..

Folhas de Estilo no Início

Colocar as folhas de estilo no HEAD  do documento faz com que as páginas pareçam estar carregando mais rápido. Isto se deve ao fato de que colocando as folhas de estilo no topo da página permite que ela se renderize progressivamente.

Especialistas em front-end que cuidam de eprformance querem que uma página carregue progressivamente; isto é, nós queremos que o browser exiba algum conteúdo o mais rápido possível. isto é especialmente importante para páginas com um monte de conteúdo e para usuários com internet ruim. A importância de dar aos usuários um feedback visual, como indicadores de progresso, é largamente pesquisada e documentada. No caso de páginas web, a própria renderização da página é o melhor indicador de progresso! Quando o browser carrega a página progressivamente o usuário vai assistindo sua construção: o cabeçalho, a barra de navegação, o logo, etc. tudo serve como feedback visual para o usuário que está esperando pela página. Isto melhora bastante a experiência do usuário.

O problema em colocar as folhas de estilo próximas ao rodapé do documento é que isto proíbe a renderização progressiva em muitos browsers, incluindo o Internet Explorer. estes browsers bloqueiam a renderização para redefinir o redesenho de elementos na página, caso seus estilos sejam alterados. O usuário fica vendo uma tela em branco.

A especificação HTML claramente diz que as folhas de estilo devem ser incluídas no HEAD da página: "Diferente de A, [LINK] deve somente aparecer na seção HEAD de um documento, embora ele possa aparecer inúmeras vezes." Obter uma tela branca ou fazer a tela piscar sem estilo não valem este risco. A melhor solução é seguir a especificação HTML e carregar suas folhas de estilo no HEAD do documento.

Scripts no Final

O problema dos scripts é que eles bloqueiam downloads paralelos. A especificação HTTP/1.1 sugere que os browsers não baixem mais de dois componentes em paralelo por hostname. Se você obtém suas imagens de múltiplos hostnames, você pode obter mais de dois downloads simultâneos. Entretanto, quando um script está sendo baixado, o browser não pode iniciar outros downloads, mesmo em diferentes servidores.

Em algumas situações não é fácil mover os scripts para o final da página. Se, por exemplo, o script usar document.write para inserir parte do conteúdo da página, ele não pode ser movido para baixo da mesma. Podem existir problemas de escopo também. Em muitos casos, existem maneiras para contonrar esta situação.

Uma sugestão alternativa é utilizar scripts deferidos (deferred). O atributo DEFER indica que o script não contém document.write, e é uma dica aos browsers para que eles continuem renderizando. Infelizmente, o Firefox não suporta o atributo DEFER. No Internet Explorer, o script pode ser deferido, mas não tanto quanto desejado. Se o script puder ser deferido, ele também pode ser movido para o final da página. Isto faz com que suas páginas carreguem mais rápido..

Use CSS e Javascript externos

Muitas dessas regras de performance lidam com como os componentes externos são gerenciados. Entretanto, antes dessas considerações surgirem você deve perguntar uma questão ainda mais básica: o Javascript e CSS devem estar em arquivos externos ou na própria página?

Usar arquivos externos no mundo real geralmente produz páginas mais rápidas porque estes arquivos são mantidos em cache pelo browser. JavaScript e CSS que estão escritos no HTML são baixados cada vez que o documento é requisitado. Isto reduz o número de requisições HTTP que são necessárias, mas aumenta o tamanho do documento HTML. Por outro lado, se o JavaScript e o CSS estão em arquivos externos em cache no browser, o tamanho do HTML é reduzido sem aumentar o número de requisições HTTP.

A chave, então, é a frequência cujos componentes externos são mantidos em cache relativo ao número de documentos HTML requisitados. Este fator, embora difícil de quantificar, pode ser analisado usando várias métricas. Se os usuários de seu site tem muitos pageviews por sessão e muitas de suas páginas reusam os mesmos scripts e estilos, há um grande potencial de ser beneficiado pelo cache de arquivos externos.

Muitos web sites caem no meio dessas métricas. Para estes sites, a melhor solução geralmente é usar JavaScript e CSS em arquivos externos. A única exceção fica para as home pages, onde escrever o código JS e CSS é preferível. Home pages que possuem poucos (quase sempre um) page view por sessão pode encontrar resultados mais rápidos escrevendo JS e CSS no próprio HTML.

Minimize Javascript e CSS

Minificação é a prática de remover caracteres desnecessários do código para reduzir seu tamanho, melhorando tempos de carregamento. Quando o código é minificado todos os comentários são removidos, bem como espaços em branco desnecessários. No caso de JavaScript, isto melhora a performance porque seu tamanho é reduzido e consequentemente o tempo de download também. Duas ferramentas populares para minificar JavaScript são JSMin e YUI Compressor. O YUI Compressor também pode minificar CSS.

Ofuscação é uma alternativa de otimização que pode ser aplicada ao código fonte. Ela é mais complexa que minificação e algumas vezes gera bugs como resultado da ofuscação. Em uma pesquisa americana notou-se que códigos minificados obtém 21% de redução d etamanho, contra 25% da ofuscação. Embora a ofuscação mostre um desempenho melhor, minificar o JS tem menos risco.

Em adição à minificação de scripts e estilos, tags <script> e <style> no código também devem ser minificadas. Mesmo que você use GZip para diminuir o tamanho de seus arquivos, minificá-los ainda irá reduzir em 5% o tamanho dos mesmos, ou mais.

Evite Redirecionamentos

Redirecionamentos possuem como resposta os status 301 e 302. Aqui está um exemplo de cabeçalho HTTP de uma resposta 301:

      HTTP/1.1 301 Moved Permanently
      Location: http://exemplo.com.br/novaurl
      Content-Type: text/html


O browser automaticamente leva o usuário para a URL especificada no campo Location. Todas as informações necessárias para o redirecionamento estão nos cabeçalhos. O corpo da resposta é tipicamente vazio. A despeito de seus nomes, nem as respostas 301 ou 302 são armazenadas em cache na prática, a menos que cabeçalhos adicionais, como Expires ou Cache-Control, indiquem que ele deva ser. A tag meta refresh e JavaScript são outras maneiras de direcionar os usuários para URLs diferentes, mas se você realmente deve realizar um redirecionamento, a técnica preferida é utilizar os códigos de status padrões do HTTP 3xx, principalmente para garantir que o botão de voltar funcione.

O importante de se lembrar é que o redirecionamento diminui a experiência do usuário. Inserir um redirecionamento entre o usuário e o HTML diminui o desempenho de qualquer site pois exigirá que nada na página apareça até que o novo documento HTML chegue.

Um dos redirecionamentos mais frequentes que acontecem os desenvolvedores web nem fazem idéia do que seja, Ele ocorre toda vez que uma barra (/) não se encontra no final de uma URL. Por exemplo, acessar a URL http://astrology.yahoo.com/astrology results resultará em uma resposta 301 contendo um redirecionamento para http://astrology.yahoo.com/astrology/ (preste atenção à barra no final).

Remova Scripts duplicados

Algo que "machuca" bastante a performance de uma página é incluir duas vezes o mesmo Javascript em uma página. Isto não é tão incomum quanto parece. Uma pesquisa realizada com os dez sites americanos mais acessadosmostraram que dois deles possuem scripts duplicados. Resumindo: JS duplicados criam requisições HTTP desnecessárias e execução de JS repetido.

Requisições HTTP desnecessárias acontecem no Internet Explorer, mas não no Firefox. No IE, se um script externo é incluído duas vezes e não é guardado em cache, ele gera duas requisições HTTP durante o carregamento da página. Mesmo que o script esteja em cache, requisições extras quando o usuário recarrega a página.

Entretanto, a execução repetida de JS acontece independente de browser, o que é um grande problema.

Uma maneira de prevenir scripts repetidos é implementar um módulo de gerenciamento de scripts no seu sistema de templates. A maneira típica de incluir scripts em uma página é a seguinte.

<script type="text/javascript" src="menu_1.0.17.js"></script>

 

Uma alternativa em PHP seria criar uma função chamada inserirScript.

      <?php insertScript("menu.js") ?>

Além de prevenir que o mesmo script seja inserido múltiplas vezes, esta função pode gerenciar outros problemas com scripts, como checagem de dependência e tudo o mais que sua imaginação permitir.

 

Libere o buffer cedo

Quando um usuário requisita uma página, ela pode levar de 200 a 500ms para o servidor exibir a página HTML. Durante este tempo, o browser está ocioso e aguarda pela chegada da página. No PHP você tem a função flush() e no ASP.NET você tem o Response.Flush(). Isto permite que você envie um HTML parcial ao browser e ele já pode ir renderizando a página. O benefício é principalmente visto em backends ocupados e frontends leves.

Um bom lugar para considerar a liberação é logo depois do HEAD porque geralmente o HTML do HEAD é fácil de ser montado pelo servidor e permite que você já vá mostrando o CSS e jacascript para o browser em paralelo enquanto o backend continua processando.

Exemplo:

      ... <!-- css, js -->
    </head>
    <?php flush(); ?>
    <body>
      ... <!-- content -->

A busca do Yahoo! foi pioneira no uso desta técnica e comprovou os benefícios da mesma.

E esta foi a primeira parte das dicas retiradas e traduzidas da Internet. Aguardem os próximos posts!