Dica: Diminuindo o tempo de carregamento de uma página web através do download paralelo de arquivos

Na semana passada, o Cleber Dantas publicou em seu blog um post com uma dica bem interessante sobre o uso de cookie-free domains. Basicamente, a idéia é armazenar arquivos estáticos do site, como imagens, arquivos CSS e JavaScript, que não precisam ter acesso aos cookies, em um subdomínio diferente do site principal. Assim, quando o browser fizer as requisições desses arquivos, os cookies não serão trafegados e, consequentemente, economizaremos no consumo de banda de rede, tornando o processo mais rápido.

Além da vantagem citada no artigo do Cleber, essa abordagem possibilita outro ganho, que é paralelizar o download de arquivos que compõem uma página HTML, tornando seu carregamento mais rápido. O protocolo HTTP 1.1 especifica que os browsers devem permitir duas conexões concorrentes por hostname, no máximo. Ou seja, segundo a especificação, os browsers só poderiam fazer download de dois arquivos simultaneamente de um mesmo hostname. Apesar dessa especificação, a maioria dos browsers mais recentes estabelece valores padrões maiores para o número máximo de conexões e podem ser configurados para outros valores. De qualquer modo, existe um limite. Como uma página HTML normalmente é composta por mais arquivos (considere os arquivos de imagem, CSS, JavaScript, etc), se essa página e todos os recursos que a compõem estiverem em um mesmo hostname, quando se atinge esse limite de requisições simultâneas, o browser enfilera as requisições pendentes até que alguma requisição executada anteriormente termine, e assim possa realizar as demais requisições de forma sequencial.

Ao distribuirmos os arquivos estáticos em múltiplos subdomínios, o limite de conexões simultâneas do browser será aplicado a cada subdomínio, ou seja, se antes uma página e seus elementos ficavam armazenados em somente um hostname e o browser limitava a N conexões simultâneas, com o uso dessa técnica o número de requisições possíveis simultâneas passa a ser N multiplicado pelo número de subdomínios utilizados. Isso torna possível que mais arquivos sejam baixados em paralelo pelo browser, diminuindo assim a fila de requisições de arquivos e o tempo para carregamento da página e de todos seus recursos.

Apesar do ganho poder ser grande, deve-se tomar cuidado com o uso exagerado de subdomínios, pois múltiplas conexões concorrentes aumentam o uso de CPU pelo browser, além de ser necessário estabelecer uma conexão TCP com cada subdomínio e resolver seu nome por DNS, o que pode causar o efeito oposto ao desejado, ou seja, fazer com que a página demore mais para carregar. O número ideal depende de vários fatores e características do site, mas estudos mostram que um número entre 2 e 4 subdomínios é o indicado. Mais informações sobre os ganhos e cuidados com o uso dessa abordagem podem ser encontradas nos links de referência a seguir:

 

jQuery e Microsoft

A notícia é um pouco antiga, mas como vi pouca repercursão, acredito que vale a pena escrever a respeito. No último evento MIX, que aconteceu em março de 2010, um dos anúncios feitos foi o da Microsoft eleger o jQuery como a principal tecnologia de client-side script para aplicações ASP.NET. Desde 2008, o jQuery já é suportado oficialmente pela Microsoft. O que muda com o anúncio feito no MIX é que agora a Microsoft vai investir tempo e dinheiro para contribuir com propostas para o projeto open-source, assim como qualquer pessoa ou empresa pode fazer. Claro que essas contribuições não servirão somente para aplicações desenvolvidas com tecnologias Microsoft, mas sim para qualquer plataforma tecnlógica que venha a fazer uso do jQuery (PHP, Java, Ruby, etc).

Você pode estar se perguntando: o que acontecerá com o ASP.NET Ajax Library e com o Ajax Control Toolkit? Com a palavra, Stephen Walther, um Program Manager do time de ASP.NET:

 

"(...) We realize that the Ajax Control Toolkit is extremely popular among ASP.NET Web Forms developers and we want to continue to invest in the Ajax Control Toolkit.

If you are adding JavaScript interactivity to an ASP.NET Web Forms application, and you don’t want to write JavaScript, then we recommend that you use the server controls in the Ajax Control Toolkit. Using the Ajax Control Toolkit does not require knowledge of JavaScript and the toolkit enables you to build applications with the concepts familiar to ASP.NET Web Forms applications developers.

If, however, you are interested in creating client-side interactivity without server controls then we recommend that you use jQuery.

(...)

We are moving the ASP.NET Ajax Library into the Ajax Control Toolkit. If you currently use ASP.NET Ajax Library client templates, client data-binding, or the client script loader then you can continue to use these features by downloading the Ajax Control Toolkit.

Be aware that our focus with the Ajax Control Toolkit is server-side Ajax.  For client-side Ajax, we are shifting our focus to jQuery. For example, if you have been using ASP.NET Ajax Library client templates then we recommend that you shift to using jQuery instead. "

O que, numa livre tradução, quer dizer:

 

"(...) Nós reconhecemos que o Ajax Control Toolkit é extremamente popular entre os desenvolvedores ASP.NET que utilizam Web Forms e nós queremos continuar a investir no Ajax Control Toolkit.

Se você está adicionando interatividade com Javascript em uma aplicação ASP.NET Web Forms e você não quer escrever código Javascript, então nós recomendamos que você use os server controls do Ajax Control Toolkit. Usar o Ajax Control Toolkit não exige conhecimento de Javascript e ele permite que você construa aplicações através de conceitos familiares aos desenvolvedores ASP.NET que utilizam Web Forms.

Entretanto, se você está interessado em criar interatividade do lado cliente sem server controls, então nós recomendamos que você use jQuery.

(...)

Nós estamos movendo o ASP.NET Ajax Library para dentro do Ajax Control Toolkit. Se você usa atualmente client templates, client data-binding, ou o client script loader do ASP.NET Ajax Library, então você pode continuar a usar essas funcionalidades fazendo o download do Ajax Control Toolkit.

Esteja ciente de que nosso foco com o Ajax Control Toolkit é Ajax do lado servidor. Para Ajax do lado cliente, nós estamos mudando nosso foco para jQuery. Por exemplo, se você usa cliente templates do ASP.NET Ajax Library, nós recomendamos que você mude para jQuery."

 

O texto completo, de onde retirei o trecho acima, pode ser encontrado em Microsoft, jQuery, and Templating.

Ainda jQuery e ASP.NET

No meu último post, escrevi sobre o jQuery passar a fazer parte do ASP.NET. Relendo-o agora, percebi que talvez não tenha sido claro o suficiente e achei que valeria a pena explicar quais os benefícios desse movimento por parte da Microsoft. O que importa não é que o jQuery poderá ser usado com o ASP.NET - isso já era possível antes, e não somente para o jQuery, mas também para outras bibliotecas javascript. A grande diferença é que agora ele fará parte do ASP.NET e do Visual Studio, e isso significa que a Microsoft dará suporte a ele na abertura de chamados de seus clientes. Isso é importante, pois é uma empresa dando suporte a um projeto open-source. Vocês devem conhecer, ou pelo menos ter ouvido falar, de casos de empresas que hesitam em adotar projetos open-source em seus projetos por falta de suporte oficial, com medo de serem deixadas na mão em caso de problemas. Os mais puristas e defensores do código aberto poderiam argumentar que não há falta de suporte, pois existe uma comunidade por trás do projeto, sempre disposta a ajudar quem precisasse. O fato é que as empresas não costumam acreditar nesse tipo de ideologia (não estou dizendo que seja certo ou errado, só estou fazendo uma constatação).

Nesse tipo de situação, havia duas alternativas: aguardar a Microsoft desenvolver um projeto equivalente à alternativa open-source, para utilizar algo que poderia ser chamado de oficial, ou então assumir os riscos e utilizá-lo mesmo sem o suporte (claro, a empresa também poderia escolher não usar o projeto ou então desenvolver uma solução proprietária). Supondo que a primeira alternativa seja a escolhida e que a Microsoft efetivamente lançasse um produto equivalente ao projeto open-source, o mesmo poderia deixar de existir, pois as empresas poderiam preferir a solução oficial (vejam o que aconteceu com os projetos de AJAX para ASP.NET quando a Microsoft lançou o ASP.NET AJAX). Para as empresas clientes da Microsoft, essa seria a situação ideal, pois contariam com um produto oficial e com suporte garantido. Já para a comunidade open-source, esse seria mais um passo da Microsoft para dominar o mundo, que estaria usando sua força e poder para varrer seus concorrentes do mapa. Difícil agradar a todos...

Assim, ao adotar o jQuery como parte de sua plataforma, a Microsoft admite usar um produto de boa qualidade mesmo que não tenha sido desenvolvido por ela, fazendo com ele não deixe de existir e nem deixe de ser open-source (outras plataformas não-Microsoft continuarão a usufruir de seus benefícios, afinal, o jQuery não foi vendido). Além disso, as empresas clientes da Microsoft ganham confiança na solução, pois sabem a quem recorrer se encontrarem algum problema.

jQuery e ASP.NET

Não sei quanto a vocês, mas para mim, uma das coisas mais chatas que existem é escrever código javascript para rodar em páginas web. Pode ser que esse trauma tenha surgido quanto tive meus primeiros contatos com o desenvolvimento de aplicações web, nos primórdios da Internet. Eram vários os problemas: faltava um ambiente de desenvolvimento decente (Notepad na cabeça), havia dificuldades em debugar o código, muitos dos códigos não funcionavam da maneira esperada em todos os browsers, isso sem falar na complexidade em se fazer coisas que deveriam ser simples, o que acarretava em falta de produtividade.

Muita coisa mudou de lá para cá: o Visual Studio melhorou muito o suporte a javascript (além disso, surgiram outros editores como o Aptana Studio), o processo de debug foi facilitado (inclusive, no Internet Explorer 8 será possível debugar código javascript; isso sem falar no Firebug, uma extensão para Firefox que já existe há muito tempo e é uma mão na roda para os desenvolvedores web) e até a interoperabilidade entre os browsers melhorou (um pouco, mas melhorou). Mesmo com essa evolução, até hoje, eu sinto calafrios quando ouço falar em fazer algo muito complexo em javascript.

Nos últimos tempos, com a onda da Web 2.0 e do AJAX, surgiram muitas bibliotecas para facilitar e aumentar a produtividade no desenvolvimento de código javascript. Entre as mais famosas, posso citar o Dojo, Prototype, Ext JS, Script.aculo.us, Yahoo! UI Library e jQuery. A grande vantagem do uso dessas bibliotecas é que elas abstraem muitos aspectos de baixo nível (como por exemplo, fazer um tratamento específico para determinada versão de browser), permitindo que nosso foco esteja na resolução do problema e não em detalhes que não deveriam consumir nosso tempo.

Assim, é com bons olhos que vejo o anúncio da Microsoft em adotar o jQuery, que é open-source, no ASP.NET. Para quê reinventar a roda quando já há uma biblioteca elogiada e consagrada? Meu palpite é que o principal beneficiado dessa integração seja o ASP.NET MVC Framework, pois nesse modelo, o desenvolvedor tem muito mais contato com HTML/HTTP e o uso de javascript é mais explícito e intensivo, o que normalmente não ocorre com o modelo WebForms. Isso não quer dizer que quem desenvolve utilizando WebForms não poderá se beneficiar, afinal de contas, apesar de nesse modelo de desenvolvimento o ASP.NET fazer o trabalho sujo pelo desenvolvedor, o resultado final gerado ainda é HTML e muitas coisas só são possíveis com javascript.

Dica: Filtro de extensões de arquivos para upload

Uma dúvida que aparece freqüentemente nos fóruns do MSDN Brasil é sobre como restringir o upload a determinados tipos de arquivos. A idéia é que, por exemplo, se uma aplicação web disponibiliza a funcionalidade de upload de imagens, não se deveria deixar que fosse feito o upload de um arquivo com extensão .doc.

Podemos fazer essa verificação no servidor. O problema desta abordagem é que uma requisição deve ser feita ao servidor web para que este possa fazer a validação. O ideal seria fazer essa restrição no momento em que o usuário está escolhendo o arquivo, ainda no lado cliente da aplicação.

Apesar da especificação do HTML do W3C prever o atributo accept, que especifica uma lista de tipos permitidos para upload de arquivos, parece que nenhum browser implementou essa característica. Pesquisando na Internet, encontrei um código javascript que permite especificar as extensões de arquivos permitidas para upload. Caso o arquivo escolhido não possua uma das extensões informadas, uma mensagem de aviso é exibida e o upload não é feito.

Algumas observações sobre o script: ele não limita a escolha de arquivo às extensões pré-definidas. Ou seja, na caixa de diálogo para escolha do arquivo, pode-se escolher qualquer um. A consistência é feita somente no momento em que o formulário for submetido ao servidor. Outra ponto que deve ser notado é que, por se tratar de um script que roda no lado cliente da aplicação, não se deve confiar totalmente nele, pois pode ser burlado. Assim, é importante que a validação também seja feita no servidor. Por último, nada impediria que alguém renomeasse um arquivo qualquer para uma das extensões permitidas, mesmo que a nova extensão não tivesse nada a ver com o conteúdo do arquivo.

Também sugiro ler uma FAQ que encontrei, com as principais dúvidas relativas a upload de arquivos em aplicações web.

Entendendo os Bookmarklets

Bookmarklets são pequenos trechos de código javascript armazenados no Bookmarks, também conhecido como Favoritos no Internet Explorer. Uma vez armazenado, podemos colocar esse atalho em uma barra de ferramentas do browser e acionar o código com um único clique. O conceito, pelo que andei lendo, parece ser antigo, mas só vim a descobri-lo há pouco tempo, e achei a idéia bem interessante. Caso você não saiba, é possível executar código javascript a partir da barra de endereços do browser. Tente copiar o código abaixo na barra de endereços do seu browser, tecle ENTER e veja o alert sendo mostrado:

javascript:(function(){alert('Hello World!'); })()

Agora imagine escrever código que interaja com a página que está sendo exibida ou então que automatize uma determinada tarefa repetitiva. Pesquisei um pouco por aí e achei coisas bem interessantes. Por exemplo, um bookmarklet que faz uma pesquisa no Google sem que você tenha que passar pela página inicial:

javascript:q = "" + (window.getSelection ? window.getSelection() : document.getSelection ? document.getSelection() : document.selection.createRange().text); if (!q) q = prompt("Search terms? ... ", ""); if (q!=null) location="http://www.google.com/search?q=" + escape(q).replace(/ /g, "+"); void 0

Talvez você já tenha a barra de ferramentas do Google ou então utilize algum browser que já oferece o campo de busca integrado. Nestes casos, o bookmarklet acima não seria muito útil. Mas se você realiza buscas através do Google limitando o escopo da pesquisa em determinado site, poderia colocar essa configuração em um bookmarklet. O exemplo a seguir realiza uma pesquisa no site KB (Knowledge Base) da Microsoft através do Google:

javascript:q = "" + (window.getSelection ? window.getSelection() : document.getSelection ? document.getSelection() : document.selection.createRange().text); if (!q) q = prompt("Search terms? ... ", ""); if (q!=null) location="http://www.google.com/search?&q=site:support.microsoft.com+" + escape(q).replace(/ /g, "+"); void 0

Aproveitei a idéia e criei um bookmarklet com minha assinatura para os fóruns do MSDN Brasil. Se você constuma utilizar os fóruns, deve ter percebido que o campo de assinatura não permite código HTML. Entretanto, nada impede que você deixe este campo em branco e coloque, manualmente, sua assinatura, digamos, mais elaborada, em cada post. Isso traz alguns problemas: ou você digita sua assinatura todas as vezes ou então salva-a em um arquivo e, todas as vezes que for postar algo, abre o arquivo, copia o texto e cola. Com o bookmarklet abaixo, eu simplesmente clico no atalho, copio o texto que é mostrado e colo no post:

java script:(function(){var a='<p> </p><hr size="1" />Ricardo Oneda<br /><a href="+unescape(" target="_blank">http://thespoke.net/blogs/oneda/default.aspx </a><p> </p>';prompt("Assinatura",a); })()

Por algum motivo que não pude identificar, não consegui fazer com que a assinatura fosse adicionada automaticamente ao campo de edição da mensagem, sem a necessiadade do copiar e colar, mas mesmo assim, já ajudou. Enfim, as possibilidades são inúmeras.

Ricardo Oneda.

Dica: Passando valores de uma popup para uma página em outra janela via JavaScript


É comum termos a situação de retornar um valor selecionado em uma janela popup para a página que abriu esta popup. Isso só é possível através de JavaScript, pois são eventos que ocorrem no lado cliente. Para conseguir isso, você poderia utilizar o seguinte bloco de código JavaScript na sua popup:

<script language="javascript">
function selecionaValor(valor)
{
  window.opener.document.forms[0].NOME_CONTROLE.value = valor;
  window.close();
}
</script>


onde:
window.opener é uma referência à janela que abriu a popup;
document.forms[0] é uma referência ao formulário (neste caso, o primeiro, cujo índice é 0) da janela que abriu a popup;
NOME_CONTROLE é o nome do controle HTML do formulário da janela que abriu a popup, para o qual você vai passar o valor selecionado;
valor é o novo valor que será atribuído ao controle da página que abriu a popup;
 
E para chamar a função:
 

<a href="javascript:selecionaValor('novo valor');">seu link</a>

Obs: a palavra "java script" acima deve ser escrita sem espaços; o theSpoke está bloqueando este tipo de escrita, provavelmente por questões de segurança, o que me obrigou a escrevê-la com um espaço em branco no meio. É por essas e outra que tem tanta gente abandonando o theSpoke...

Ricardo Oneda

ASP.NET x JavaScript

Com o ASP.NET ficou mais fácil e produtivo desenvolver aplicações Web, pois ele já fornece vários controles que antes tínhamos que desenvolver e com os quais gastávamos muito tempo. Além disso, o ASP.NET deixou o processo de se desenvolver uma aplicação web bem mais parecido com o processo de se desenvolver uma aplicação desktop. Isso quer dizer que podemos ignorar o JavaScript e o HTML (ou DHTML), pois só o ASP.NET e o código escrito em linguagem server-side é suficiente, certo? Quem pensa assim, não poderia estar mais enganado.

Apesar das inegáveis facilidades trazidas pelo ASP.NET, não podemos nos esquecer que o resultado do processamento do servidor web que é enviado ao browser ainda é HTML e JavaScript. Isso é o que garante (ou pelo menos deveria garantir) que a aplicação irá funcionar em qualquer browser de qualquer plataforma (Windows, Unix, Mac, etc). O que o ASP.NET faz é esconder o trabalho sujo do desenvolvedor, ou seja, o HTML e JavaScript são gerados automicamente e faz com que muitas vezes nos esqueçamos que eles ainda estão lá.

Muitas pessoas têm dificuldade (ou até mesmo não querem) em aceitar isso, principalmente aqueles que vieram do desenvolvimento de aplicações desktop e só agora, com o ASP.NET, estão tendo o primeiro contato com desenvolvimento Web.

Já muitos daqueles que desenvolviam aplicações web antes do ASP.NET reclamam que a integração com o JavaScript ficou mais complicada. Não sei se "complicada" é uma boa definição, mas com certeza é bem diferente da maneira tradicional a qual estávamos acostumados. Mas isso é questão de costume e, depois que nos adaptamos, fica bem mais fácil.

Vejo muitas pessoas reclamarem que a Microsoft deveria ter mudado isso e ter extinto o JavaScript, além de ter implementado várias outras coisas que só são possíveis com scripts client-side, como se dependesse dela ditar estes padrões! Em vez de ficarem esperando tudo e mais um pouco da Microsoft, porque não desenvolver seu próprio controle? Afinal, você pode desenvolver (ou adquirir de terceiros) um controle que atenda as suas necessidades e depois reaproveitá-lo em vários projetos. A plataforma .NET é bem flexível com relação a isso. Ela não te obriga a ficar amarrado ao que é nativo da plataforma.

Apesar de ser possível desenvolver uma aplicação web em ASP.NET sem ter nenhum conhecimento de HTML e JavaScript, você ficará muito limitado e sua aplicação deixará de ter muitas funcionalidades que só são possíveis através de scripts que rodam no cliente (neste caso, o browser). O exemplo clássico é a manipulação de janelas pop-ups e de frames.

Abaixo, seguem alguns links que mostram como trabalhar com JavaScript e ASP.NET:

Client-Side Script Integration in ASP.NET
Injecting Client-Side Script from an ASP.NET Server Control
Using JavaScript Along with ASP.NET

E agora, alguns links que tratam de JavaScript, HTML e DHTML:

Dynamic Drive HTML
HTML Code Tutorial
JavaScript Source
Doc JavaScript

Ricardo Oneda.