Abaixo os slides da minha palestra de hoje (02/02/2012) no Codificando Night Week
Nessa palestra falei bastante sobre Front-end e expliquei a motivação e o uso das bibliotecas javascript LABjs e JQuery Templates
Precisamos conhecer exatamente como as coisas acontecem por debaixo dos panos, só assim conseguiremos otimizar nossas páginas e deixar nossos usuários felizes 
.
Muitos fatores podem afetar a performance de uma página, largura de banda, distância entre o cliente e o servidor, tamanho e quantidade de elementos em uma página, como esses elementos são carregados e etc.
Devemos começar por algum lugar a procura por gargalos, existem muitas ferramentas que podem nos ajudar com isso. O que todas elas possuem em comum é o que chamamos de Waterfall chart, um gráfico em cascata que mostra como os elementos da página estão sendo carregados.
Figura 1: Aba Net do FireBug
Figura 2: Waterfall View da ferramenta WebPageTest.org
As duas figuras acima mostram o Waterfall view da página inicial do site do Google.
Cada linha da cascata representa um componente de página sendo baixado para o browser do usuário.
Perceba que primeiramente o HTML é baixado e depois todos os componentes associados a ele (Imagens, arquivos CSS, arquivos JS e etc).
No caso da visualização do WebPageTest.org cada componente (linha) tem uma barra com pedaços coloridos que representam diferentes atividades para aquela requisição HTTP, vejamos:
Figura 3: Requisição HTTP
Figura 4: Legenda
DNS (Domain Name System) Lookup é o processo de resolução de nome (de domínio) em IP, ou seja, é achar através de uma url como http://www.google.com.br o IP associado a mesma, que é o que o browser precisa para fazer a conexão com o servidor remoto.
Um ponto importantissímo é que um DNS Lookup irá acontecer para cada domínio diferente que sua página possa ter associado a ela, por exemplo: http://images.seusite.com.br , http://static1.seusite.com.br . Cada um desses subdomínios gerará um novo DNS Lookup já que diferentes subdomínios podem estar associados a difentes IP’s.
Todos as requisições HTTP que um browser faz para o servidor são trafegadas através de conexões TCP (Transmission Control Protocol), portanto toda requisição precisa de uma conexão TCP ativa para que se possa baixar os componentes da página.
Para se estabelecer uma conexão TCP um three-way handshake é feito entre o cliente e o servidor através de metadados enviados nos pacotes. Os pacotes do handshake são muito pequenos e depois de enviados e reconhecidos pelas duas pontas a conexão é estabelecida e a transferência do arquivo pode ser iniciada.
Figura 5: Handshake
Um novo header foi introduzido no HTTP 1.1 com o intuito de reaproveitar conexões TCP para difentes requisições. Quando utilizamos o header Connection: keep-alive uma conexão TCP aberta e que nao tenha dado timeout ainda será reaproveitada para trafegar outras requisições HTTP, evitando assim o overhead de se estabelecer conexões TCP (handshake).
Figura 6: Visualização de conexões
Perceba que em uma mesma linha diferentes tipos de componentes são trafegados em momentos diferentes, uma mesma conexão TCP é reaproveitada.
Time to First Byte também conhecido como TTFB é o tempo que o browser espera para receber o primeiro byte de informação da requisição, em páginas dinâmicas podemos considerar esse tempo a demora do processamento server side por exemplo. Se o TTFB de uma request esta muito alto, investigue pois pode ser um ponto importante para otimizações (índice de bancos de dados, melhorias de algoritmos na aplicação e etc).
Depois de receber o primeiro byte, o “resto” em azul é o tempo de download do componente em sí.
Perceba na figura 3 que só de bater o olho percebemos que mais da metade do tempo gasto nessa requisição foi gasto com REDE!, DNS Lookup, estabelecimento de conexão TCP e TTFB (resumidamente consideramos esse tempo como simplesmente LATÊNCIA).
Digo novamente, nós desenvolvedores web precisamos conhecer muito tudo isso, esse tipo de conhecimento esta escondido e poucas pessoas tem ou tentam aprender, mas com certeza saber isso e muito mais faz de você um melhor desenvolvedor.
Abraços
Post rápido prometo. Piadinhas de cookie a parte 
a coisa é bem séria.
É muito comum nós Web Developers guardarmos informações em cookie(s) no(s) browser(s) do(s) usuário(s), certo? Sim certo!
As vezes até “sem querer” fazemos isso (até sem saber), por exemplo, vários frameworks web (inclusive o ASP.NET) armazena no cookie informações para fazer a autenticação dos usuários na aplicação.
Bom, e daí que não é através de mágica que nós conseguimos acessar lá no SERVER os dados do cookie que fica no BROWSER do usuário.
A toda request feita para o servidor pelo browser o cookie do usuário (sem piadinhas aqui ok? ) vai junto, é trafegado na request. Sério? Sim, sério.
A grande questão aqui é que o cookie é baseado em subdomínio, ou seja, se eu gero um cookie qualquer para www.meusite.com.br, toda request feita para o “www” levará o cookie junto (sem piadas novamente), inclusive requisições para imagens, arquivos css e javascript e tudo que estiver apontando para o subdomínio “www”.
Agora cá pra gente, por que raios a gente precisa trafegar os cookies para imagens e arquivos estáticos em geral? Não precisamos! Não serve pra nada, nem pra gente e nem para o servidor, é um grande desperdício!
Use cookie-free domains, se nós criarmos um novo subdomínio, por exemplo, static.meusite.com.br e fizermos com que todos os arquivos estáticos apontem para este subdomínio bingo! Os cookies não serão trafegados porque eles foram gerados para o “www” e não para o “static”, dessa forma conseguimos economizar alguns Kilobytes no final do mês no tráfego geral do site , chique não?
Qualquer dúvida ou sugestão, deixe-me saber nos comentários
Abraços
Olá pessoal,
Resolvi escrever este pequeno post para explicar a diferença entre dois (famosos) eventos que são disparados quando uma página é carregada, são eles:
Estes eventos são muito importantes e devemos saber a real diferença entre eles, assim usaremos cada um deles de maneira apropriada
Também conhecido em JQuery como: $(document).ready
Este evento é disparado quando o documento HTML é carregado e parseado (analisado), neste momento o DOM (Document Object Model) é construído e esta pronto para ser acessado.
Não há a necessidade de esperarmos todo o resto da página ser carregado para acessarmos a estrutura de objetos e fazermos manipulações .
Também conhecido em JQuery como: $(window).load
Este evento por sua vez é disparado quando TODOS os componentes da página são carregados: Imagens, CSSs, JavaScripts, Frames, Flashs e etc.
Devemos usar este evento somente quando quisermos fazer algo depois do carregamento COMPLETO da tal página.
Tirei a imagem acima do FireBug uma extensão do Firefox.
Perceba duas linhas verticais uma azul e outra vermelha, que representam os eventos DOMContentLoaded e load respectivamente. No tooltip ainda conseguimos ver a quantidade de tempo que se passou até que esses eventos fossem disparados, interessante não?
Quanto mais perto uma linha da outra mais rápido sua página esta sendo carregada!
Sim! Botões do Facebook, coisas do Twitter e etc, tudo que for de terceiro que estiver “pindurado” em sua página vai interferir ou postergar o evento load de sua página, portanto cuidado!
O ideal nesses casos é carregar tais componentes de modo assíncrono, mas isso é assunto para um próximo post .
Espero ter contribuído de alguma forma
Abraços!