Alguns entendem a velocidade de um site como o tempo de carregamento de todo o conteúdo presente na página, outros consideram o tempo de carregamento do primeiro byte de informação. Seja qual for sua medição, uma coisa é certa: seu site precisa ser rápido. O tempo de carregamento é um dos pontos que mais contribuem para o abandono de páginas. Sim, e os dados podem ser ainda mais assustadores do que você imagina:

• 40% dos usuários tendem a abandonar uma página web que leva mais de três segundos para carregar;
• 47% dos usuários acreditam que uma página web deve carregar completamente em dois segundos ou menos;
• 52% dos consumidores online tendem a ser mais leais a sites que carregam mais rápido.

Ou seja, a lentidão no carregamento de um site pode provocar um alto índice de insatisfação de usuário, mas não apenas isso. A demora também impede, cada vez mais, que seu site seja encontrado na internet, isso porque, em termos SEO a velocidade de carregamento é um item considerado bastante importante. Entre uma infinidade de fatores que o Google utiliza para classificar um site em seus resultados, por exemplo, a velocidade, também de sites mobile, aparece na lista – e não é de hoje, esse fator é considerado desde 2010.

Se você acha que “segundos” é pouco tempo, não esqueça que, na internet, o carregamento de página é medido em milissegundos, ou seja, milésimos de segundo.
Funciona mais ou menos assim:

E, se você está pensando que “é tudo problema no front-end!”, saiba que não necessariamente. É muito comum que más práticas de front-end sejam as principais responsáveis pelo tempo de carregamento de um site, mas é preciso estar atento também ao back-end. Pensando nesses dois cenários, iniciamos hoje uma série de posts sobre as melhores práticas para acelerar o carregamento de suas páginas. Para começar, vamos analisar dois pontos bastante importantes: latência e front-end.

Latência

Sim, esse é um fator essencial e que, frequentemente, gera muitas dúvidas. Contratar uma hospedagem no Brasil ou no exterior, qual a diferença entre latência e largura de banda. São muitos os questionamentos, mas, vamos por partes. Em primeiro lugar é importante esclarecer o que é latência. Latência é o intervalo de tempo em que uma informação (ou um conjunto delas) vai de um ponto a outro. A tabela no início desse post refere-se justamente à latência, o tempo que uma solicitação leva para sair do computador do usuário, chegar ao servidor de origem e voltar para máquina do usuário.

É importante entender que a latência está delimitada pela velocidade da luz (299.792.458m/s), velocidade que só é atingida no vácuo. Hoje, o melhor meio de transmissão é a fibra óptica (que na verdade é um meio e não a ausência dele, como no caso do vácuo), mas é preciso considerar que todo o meio de transmissão tem um índice de refração, que no caso da fibra óptica é ~1,5.

Por exemplo:

Uma requisição feita em Nova York em um site hospedado em Londres (uma distância de 5.585km) levaria 19ms se transmitida na velocidade da luz, no vácuo. Já na transmissão por fibra óptica, a latência passa a ser de 28ms, com Round Trip Time (RTT) de 56ms – o tempo de ida de volta de uma informação entre dois pontos.

Seria redundante dizer que quanto mais longe um site estiver hospedado maior será sua latência, certo? Mas não parece tão repetitivo afirmar que a latência e a largura da banda são coisas diferentes. Uma boa analogia é a do encanamento de água. Enquanto a primeira (latência) refere-se à quantidade de tempo que a água leva para entrar de um lado do cano e sair pelo outro, a segunda (largura da banda) refere-se ao tamanho desse cano ou à quantidade de água que pode fluir nele por um período de tempo.

Após diversos testes já realizados, hoje entende-se que a largura da banda pode impactar na velocidade de carregamento de sites, mas que a latência continua sendo um fator bem mais importante.

Front-end

Você sabia que 80% do tempo de carregamento de uma página está no front-end? Seja carregando recursos ou montando tudo na tela, na maioria dos casos o gargalo está na linha de frente.

Um primeiro ponto que devemos prestar atenção é no número de requisições HTTP da sua página vs o tamanho dos arquivos que você está carregando. Assim sendo, considere que:

• Enviar múltiplas requisições, para arquivos muito pequenos, não vale a pena, pois cada requisição terá um overhead do protocolo HTTP, como o envio e recebimento de cookies em cada requisição . Ao invés disso, agrupe vários arquivos pequenos em um só, para que cada ida no servidor valha mais à pena.
• Requisitar arquivos muito grandes não vale a pena, pois o protocolo HTTP limita o número de requisições simultâneas a um mesmo servidor em um número entre 2 e 8, dependendo de cada navegador. Caso uma das requisições tenha um arquivo que seja muito grande, ficará consumindo uma preciosa requisição deste limite durante muito tempo.

Com isso em mente, certifique-se de agrupar pequenos arquivos Javascript em um só, bem como pequenos arquivos CSS. Já as pequenas imagens devem ser agrupadas em Sprites CSS, uma técnica largamente difundida na web atualmente.

Aproveitando que tocamos no assunto de CSS e JS, não faz mal lembrar a regra de ouro para estes arquivos:

CSS no header. JS no footer!
Albert Einstein

Coloque seus arquivos CSS (nem precisa dizer que você não deveria usar CSS inline!) no header da página, para que a estrutura do HTML se monte, juntamente com o estilo, de maneira mais fluida, sem “solavancos”. Já os arquivos JS devem ficar no final da página, uma vez que seu carregamento é bloqueante e atrapalha a experiência do usuário enquanto está carregando. Ainda sobre CSS e JS, certifique-se de minificá-los sempre antes de mandá-los para produção, existem muitos plugins que se integram às IDEs mais comuns do mercado, bem como automatizadores de tarefas como Gulp e Grunt que fazem isso para você automaticamente.

Outra dica que sempre é válida é usar CDN (Content Delivery Network, como o CloudFlare, add-on disponível na Umbler) para guardar todos os seus conteúdos estáticos do seu site. Lembra do que falamos antes sobre a limitação de requisições simultâneas do HTTP? Pois é, o limite é por domínio, o que podemos facilmente contornar usando mais de um domínio para nossos recursos, geralmente um domínio que aponte para um CDN. Se seu site é meusite.com, que tal criar o static.meusite.com, ou o img.meusite.com? Apenas certifique-se de não usar mais que dois ou três domínios, caso contrário a resolução de DNS vai cobrar um alto preço da sua aplicação e a estratégia pode ser um “tiro no pé”!

Mas, por que um CDN e não apenas um subdomínio comum? O protocolo HTTP carrega consigo, além das informações da requisição em si, uma série de meta-informações (cabeçalhos) e de cookies, que caso não saiba, são informações da sessão do navegador. Um CDN é um ambiente otimizado para entregar os arquivos da maneira mais rápida possível, livre de cookies (desnecessários em requisições de arquivos estáticos como imagens, JS e CSS) e com controle da expiração do cache desses arquivos. Assim, um arquivo que não muda com frequência, pode ser armazenado em cache no navegador do usuário por um mês, por exemplo, o que vai economizar muitas requisições caso ele (o usuário) acesse seu site com frequência.

Ainda sobre conteúdo estático (você notou como eles são muito importantes?), certifique-se de que todas suas imagens estão com o tamanho e qualidade apropriados, para evitar redimensionamento via HTML/CSS ou mesmo imagens com alto nível de detalhes e transparências quando apenas queremos um ícone pequeno e pouco visível.

Estas foram algumas dicas que acreditamos que possam fazer uma diferença significativa no desempenho do seu site e certamente existem muitas outras que poderíamos aplicar. Nos próximos posts vamos abordar temas como melhorias no back-end e no banco de dados. Para isso, contamos com a sua colaboração. O que você aplica hoje em seus sites para aumento de desempenho e recomenda que os outros façam também?

Deixe as suas dicas aí nos comentários e nos ajude a criar um post ainda mais incrível 🙂