Comecei esse post com uma pergunta de propósito e espero que você possa responder essa questão ao final da leitura.

Hoje enfrentamos um grande problema em todos os sistemas de rede que basicamente é a velocidade de uma informação sair de um ponto e chegar a outro, esse tempo de viagem da tal informação entre dois pontos é o que chamamos de latência.

O tempo de latência normalmente é medido em ms (milissegundos) para a maioria dos sistemas/situações, como não estamos habituados a pensar em milissegundos veja abaixo uma tabela de percepção dos usuários em relação a algumas “esperas”:

Claramente se quisermos ter a atenção total de nossos usuários teremos que manter a velocidade de resposta de nossas aplicações em até 300ms (complicadíssimo!).

Ok, já sabemos o que é latência, mas outro conceito importante de aprendermos é o RTT (round trip time) que basicamente é o tempo de ida e volta de um sinal/informação entre dois pontos (latência de um meio de transmissão vezes 2).

O grande problema com a latência na realidade é que hoje já estamos transmitindo os dados/sinais/informações de maneira muito rápida e estamos amarrados a um limite de velocidade também conhecido como velocidade da luz.

A velocidade da luz por definição é igual a 299 792 458 metros por segundo ou mais ou menos 300 000 quilomêtros por hora (bastante não?), só que (sempre tem um but) essa velocidade toda só é atingida no vácuo.

Bom como o vácuo perfeito não é possível na natureza e o não perfeito hoje não é utilizado em grande escala (somente alguns centros de pesquisa possuem câmaras de vácuo) teremos que utilizar outro meio para a transmissão da luz certo? Sim perfeito!

Que a fibra óptica é realidade não temos duvida =D e é nela que basicamente transmitimos a luz/sinais/informações entre os continentes hoje em dia (normalmente debaixo dos oceanos).

A fibra é um meio muito competente para a transmissão da luz, mas é um meio de transmissão e não a ausência dele (vácuo). Todo meio de transmissão possui um índice de refração associado ao mesmo e no caso da fibra esse valor é de ~1.5.

Veja abaixo algumas distâncias e tempos de latência entre algumas cidades famosas do nosso querido planeta terra:

O desafio hoje é tentar reduzir cada vez mais o índice de refração dos meios de transmissão e chegar cada vez mais perto do “limite” da velocidade da luz (complicadíssimo de novo!).

Perceba que uma resolução de DNS (que acontece em todas as páginas web do mundo) requer um RTT, estabelecer uma conexão TCP (que é por onde uma requisição HTTP é trafegada, leia: Anatomia de uma requisição HTTP) requer outro RTT, mas sabemos que acontece mais de uma resolução DNS por página e também que são estabelecidas mais de uma conexão TCP para trafegar as diversas requisições HTTP de uma página.

Mesmo sabendo disso ainda queremos ter aplicações rodando abaixo de 300ms (Are you fucking kidding me?).

Ok, sabemos que da para reaproveitar conexões TCP (keep-alive), usar CDN e trazer para mais perto dos usuários nossos assets, assim diminuindo o percurso o que diminui a latência.

Agora você pode estar pensando que foi justamente por isso que você contratou aquela internet super veloz de 10/20Mbps do seu fornecedor de internet, para poder navegar muito mais rápido na Web certo? Errado!

Veja bem a largura de banda (bandwidth) se compararmos com um cano de água quer dizer simplesmente que quanto mais largo o cano mais água eu posso colocar dentro dele, mas se o cano estiver vazio demorará um tempo para o conteúdo do cano ir de um lado ao outro, entende?

Ai você deve estar se perguntando, pois é eu comprei mais banda para ter um cano mais largo e portanto transferir mais dados de um lado a outro, se eu tivesse uma banda menor (um cano mais fino) certamente demoraria mais para todos os dados viajar de um canto a outro. Perfeito! Você tem razão.

Mas perceba que a minha pergunta no começo do post foi se aumentar a banda quer dizer aumentar a velocidade de navegação na web. Eu não me referi por exemplo em assistir um vídeo, música, streaming e outras coisas porque para esse tipo de atividade uma banda maior faz TOTAL diferença, quanto mais melhor.

E por quê? Por quê para ver vídeo a banda faz diferença e para navegar na Web nem tanto?

Bom a resposta é na verdade simples, ouvir uma música ou ver um vídeo significa dizer que estamos utilizando o protocolo TCP (transporte) para fazer algo que ele foi desenhado para.

O protocolo TCP foi desenhado para transmitir dados em long lived connections (conexões duradouras) e também para bulk data transfer (grandes quantidades de dados).

Navegar na Web é justamente o oposto, utilizamos conexões curtas e que trafegam poucas quantidades de dados.

O Google fez dois experimentos visando ver a diferença de se aumentar a largura de banda e também de diminuir a latência e ver o que acontece com a navegação na Web (não vídeos, músicas e etc), veja o que acontece quando aumentamos a largura de banda ou então diminuimos a latência:

Quando fixamos a latência e aumentamos Mbps, depois de 5Mbps a diferença até 10Mbps é de apenas 15% (ajuda, mas nem tanto), primeiro gráfico.

Por outro lado quando fixamos a banda (nesse caso em 5Mbps) e vamos diminuindo de 20ms em 20ms (segundo gráfico) o ganho se mostra linear! Quanto menos latência maior é a velocidade de carregamento de nossas páginas! (sweet!)

O estudo do Google pode ser visto aqui: https://docs.google.com/a/chromium.org/viewer?a=v&pid=sites&srcid=Y2hyb21pdW0ub3JnfGRldnxneDoxMzcyOWI1N2I4YzI3NzE2

Ou seja, se seu objetivo é apenas aumentar a velocidade de navegação nas páginas Web aumentar a banda (para mais de 5Mbps) não vai te ajudar muito, mas se você conseguir derrubar as leis da física e fazer algo que ultrapasse a velocidade da luz ou diminua o índice de refração dos meios de transmissão será algo muito melhor =D.

Oh wait!

Você esta em uma rede WIFI? 3G? Bom ai o negócio é ainda pior, mas isso é assunto para outro post

Good news 

HTTP 2.0 esta sendo desenvolvido e ele esta sendo baseado no protocolo SPDY que entre outras coisas faz um uso MUITOO melhor das conexões TCP (teremos melhoria de performance só de migrar \o/), mas ainda estamos numa fase inicial do projeto, vamos aguardar.

Conclusão

Navegar na Web é “latency bound”, aumentar a banda depois de um certo nível não faz sentido.

Diminuir a latência é muito difícil (leis da física caem sobre nossas cabeças)

HTTP 2.0 nos ajudará bastante

PS: Se gostou do post compartilhe com seus amigos, principalmente se forem Devs Web

Obrigado e vamos falar mais nos comentários?

Abs

O que percebo na realidade é que as pessoas não entendem isso muito bem, não entendem o “NOSQL” (eu mesmo não entendia). Já fui a diversos eventos de tecnologia onde o tema foi abordado e sempre saia confuso, tentando encaixar o que alí tinha sido dito com a minha realidade, e de fato percebia o mesmo na cara dos demais e confirmava quando conversava com essas pessoas.

O problema é que sempre conseguimos encaixar tudo (qualquer tipo de dado) em um modelo relacional (em um banco de dados relacional) e sendo assím ficamos no mínimo ressabiados com qualquer abordagem “não relacional”, afinal foi o modelo relacional que aprendemos na escola e que sempre nos foi passado como “o cara”, são 40 anos utilizando este modelo ele realmente deve ser infalível (só que não).

Acredito que um ponto importante para toda essa dificuldade em entender ou aceitar modelos diferentes de dados esteja de fato no magnifico nome “banco de dados relacional“, embora não seja um nome errado isso gera confusão e um forte apego.

Os bancos de dados relacionais são baseados na teoria de conjuntos, lembram disso? Quem na faculdade não teve aquela famosa disciplina chamada álgebra relacional (forma de cálculo sobre conjuntos ou relações)? Tuplas, atributos, relacões… lembram??

Pois é o “relacional” dos bancos de dados relacionais não vem de relacionamentos e sim das relações, dos conjuntos ou como chamamos de maneira mais “moderna” das tabelas, é um banco de dados de tabelas onde aplicamos operações como: união, intersecção, diferença, produto cartesiano etc etc etc.

E se pensarmos como tal, deveríamos então deixar como responsabilidade para estes bancos de dados apenas dados com esta característica, dados tabulares.

Você já tentou modelar um domínio altamente conectado (tipo uma comunidade de pessoas) em um banco de dados relacional? Eu já e sofri com isso, modelar a gente modela certo? Tira as redundancias de dados (formas normais) e vai embora, mas e para tirar o dado de lá de dentro? Pois é, só sofrimento não é?.

Então vamos deixar a cargo dos bancos de dados relacionais o que eles são bons em tratar, dados tabulares, e vamos buscar outras alternativas para dados com outras características, beleza? Bora estudar meu povo! =D

Ahhh se tivessem me ensinando como banco de dados tabular eu não teria sofrido tanto… certamente não.

Nessa palestra falarei bastante sobre IIS, mas voltado para o desenvolvedor. Vou tentar mostrar algumas coisas que aprendi depois de apanhar muito.

Nessa palestra falei bastante sobre Front-end e expliquei a motivação e o uso das bibliotecas javascript LABjs e JQuery Templates

Nessa palestra falei sobre as novidades do ASP.NET MVC 4, a galera gostou bastante.

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 Lookup

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.

Initial Connection

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

1. Browser envia um pacote com o metadado SYN (Sequence Number) para o servidor
2. Servidor responde com ACK (Acknowledged) e um outro SYN
3. Browser finaliza o cumprimente (handshake) com mais um ACK
4. Conexão estabelecida!

Keep-Alive Header

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

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).

Content Download

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).

Conclusão

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

A CDN tem dois grandes objetivos o primeiro é tornar mais próximo o conteúdo que esta sendo distribuído e solicitado (Imagens, Stylesheets, Scripts, Flashs, Músicas, PDF’s e etc) dos usuários assim diminuindo o tempo de resposta e latência destes componentes, o segundo é diminuir custos com banda/tráfego de dados (do site que esta utilizando a CDN) e por conseqüência diminuir a quantidade de requisições diretas ao servidor real do site desafogando e muito a infra “local”.

É normal um site sendo acessado de uma país ter grandes diferenças no tempo de resposta das páginas quando acessado de um país vizinho, até mesmo diferenças entre cidades ou bairros. Isto ocorre devido ao roteamento entre as requisições e os servidores que estão sendo solicitados que dependendo do link ou região que o usuário se encontra os saltos são maiores ou menores e com velocidades diferentes também.

Uma solução interessante seria entregar para cada usuário ou região o conteúdo que esteja mais próximo da requisição que esta sendo feita e é justamente ai que uma CDN faz a diferença melhorando incrivelmente a experiência do usuário e o tempo de resposta dos componentes que estão sendo solicitados pelo usuário.

Existem CDN’s comerciais ou pagas e CDN’s gratuitas abaixo listo algumas bem famosas e recomendadas pela indústria.

CDN’s Comerciais:
Akamai
EdgeCast Networks
Limelight Networks

Curiosidade

Daniel M. Lewin um dos fundadores da Akamai estava em um dos vôos do 11 de setembro de 2001 e faleceu.

Conclusão

Aumente a performance do tempo de resposta dos componentes de suas páginas, faça os usuários mais felizes e ainda diminua alguns gastos com o alto tráfego que você tem hoje sem uma CDN pra te dar uma força.

Isto requer um investimento menor já que é mais barato no começo criar um site do que montar por exemplo uma loja física (comparando a outros negócios).

Uma vez que a empresa vive através da World Wide Web é fundamental que o tal site esteja otimizado afim de garantir entre outras coisas um rápido atendimento (e a qualquer momento, afinal acho que essa é uma vantagem da Web), satisfação do cliente, um baixo (ou o mais baixo possível) custo para manter a “lojinha” aberta (o site do ar), fidelização da clientela, aumento da taxa de conversão, uma fácil descoberta de seus produtos ou serviços por potenciais interessados (SEO), etc etc etc.

WPO – Web Performance Optimization é uma recente área de estudo e otimização pra Web Sites e deve ser observada e utilizada cada dia mais por todos aqueles que pretendem trabalhar ou até viver de internet (no caso dos empreendedores). WPO é parecido com SEO do ponto de vista que também traz mais trafego para o site, mas não para por aí, de acordo com alguns cases que veremos abaixo também melhora a experiência do usuário, aumenta receita e diminui custos operacionais.

Parece ridículo, mas apenas 1 segundo a mais ou a menos no tempo de carregamento de uma página faz muita diferença dependendo de qual site estamos falando, veja alguns exemplos:

Bing – 2 segundos a mais no tempo de resposta de suas páginas é igual a 4,3% de receita a menos por usuário.

Google – 400 milisegundos de delay é equivalente a 0,59% de buscas a menos por usuário.

AOL – Atestou que usuários que carregam páginas rápidas navegam 50% mais que usuários com páginas com carregamentos mais demorados (50% de páginas a mais por usuário)

ShopZilla – Diminuiu o tempo de carregamento das páginas de 7 segundos para 2 segundos e conseguiu aumentar de 7% para 12% em receita e diminuir em 50% os custos com hardware e banda.

Fonte: Gomez Inc

Empresas sérias que tem milhares ou milhões de acessos diariamente devem sem sombra de dúvidas melhorar a performance de suas páginas, simplesmente você ganha mais e gasta menos! veja que maravilha!

Há varias formas e técnicas para aumentar a performance das páginas de nossos sites, mas isso é assunto para um outro post. (em breve postarei algumas coisas.)

Importante: Não poderia deixar de dizer que o Google já há algum tempo vem utilizando o fator “velocidade/performance” como critério para o resultado de suas buscas, ou seja, agora páginas rápidas ou performáticas são melhor indexadas pelo maior mecanismo de buscas do planeta.

Conclusão

Melhorar a performance de nossas páginas diminui custos de operação com hardware e banda (pois se trafega menos dados e diminui em manutenção dos servidores, por exemplo), aumenta tempo de navegação e pageview por usuário (logo da pra vender mais, aumentando a receita), fortifica a marca afinal sites rápidos são adorados pelos usuários e eles recomendarão com certeza, etc e tal!

É 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.

Ok, mas e daí!?

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!

O que eu faço então?

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

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:

• DOMContentLoaded;
• load

Estes eventos são muito importantes e devemos saber a real diferença entre eles, assim usaremos cada um deles de maneira apropriada

DOMContentLoaded

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 .

Load

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.

Exemplo de DOMContentLoaded vs load

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!

Componentes de terceiros – CUIDADO!

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!