Encontrar o carregamento perfeito é tão fácil como ganhar na Mega Sena. Você precisa precisa tentar.
Eu sempre fui um cara empenhado em em conseguir velocidade no carregamento. Tanto que quando o BLOG mxml.com.br fez um ano, o site foi para um servidor dedicado, e quase um ano depois saiu do Wordpress e ganhou sistema próprio para que o desempenho fosse melhorado.
Quando migrei de domínio, de mxml.com.br para flex.eduardokraus.com eu tentei criar um sistema em Ajax que nas transições de página só carregava o conteúdo da div#content e não toda a página. Abandonei por causa do IE, que na época ainda dominava o mercado.
Maldito Internet Explorer. Eu fico indignado ao ver um programador usando o IE, mesmo depois das pessoas saberem que o IE foi o maior calço para a vinda de novas técnicas de desenvolvimento WEB.
Depois que o Google postou em 2009 que a velocidade do carregamento de um site passaria a ser um dos parâmetros para o hanking (faster-sites-create-happy-users) das buscas do Google, uma verdadeira enxurrada de opções vem surgindo todos os dias para melhorar o desempenho do site.
No site www.escolaemcasa.com.br eu estou usando novas técnicas para melhorar o desempenho no carregamento do site. Algumas delas vou falar aqui.
Este é um dos necessários. Não se fala mais em site carregando rápido sem que o HTML saia do servidor compactado.
Quando falo em compactado, falo que o todos os espaços, inúteis e quebras de linhas devem ser removidos antes de serem enviados ao navegador.
Isso porque, para o navegador não importa se o HTML esteja assim:
<!DOCTYPE html> <html lang="pt-BR"> <head> <meta charset="UTF-8"> <title>Título</title> </head> <body> <div id="content"> <div id="header"> <p>topo</p> </div> <div id="article"> <p>aqui o conteúdo</p> </div> <div id="footer"> <p>Rodapé</p> </div> </div> </body> </html>
ou assim:
<!DOCTYPE html><html lang="pt-BR"><head><meta charset="UTF-8"><title>Título</title></head><body><div id="content"><div id="header"><p>topo</p></div><div id="article"><p>aqui o conteúdo</p></div><div id="footer"><p>Rodapé</p></div></div></body></html>
A diferença é que do primeiro exemplo, para este segundo, foi economizado 119 bytes de dados que não tem utilidade nenhuma para o navegador. 110 Bytes equivale a 32,2% que significa que o sei HTML será carregado 32% mais rápido e consumirá 32% menos banda de seu servidor. Agora imagine 32% para quem tem internet de 512Kbps, ou menos.
Links úteis:
O que é renderização?
Renderização é o processo que o Browser faz para converter o código HTML, CSS e JS em conteúdo visível.
O que é Bloqueio de Renderização?
Bloqueio de Renderização é quando o Browser tem que parar a renderização para buscar um novo arquivo no servidor.
Veja este vídeo que gravei:
Apesar de até algum tempo atrás, CSS inline ser considerado vilão, hoje, CSS inline vem ganhando força de novo pelo fato da sua maior velocidade na renderização da página. Porém o CSS Inline deve ser usado com cautela e de preferência com ferramentas que otimizam o carregamento de páginas futuras do site.
Abaixo esta, a forma tradicional de adicionar o CSS a uma página.
<!DOCTYPE html> <html lang="pt-BR"> <head> <meta charset="UTF-8"> <title>Título</title> <link rel="stylesheet" href="style.css"/> </head> <body> <div id="content"> <p>aqui o conteúdo</p> </div> </body> </html>
Porém, com este processo, quando ele encontra o <link rel="stylesheet" href="style.css"/> ele tem que parar a renderização para ir no servidor e buscar o conteúdo do arquivo style.css. Então, agora analise o código abaixo:
<!DOCTYPE html>
<html lang="pt-BR">
<head>
<meta charset="UTF-8">
<title>Título</title>
<style>
body{
margin: 0;
padding: 0;
}
#content{
background-color: #ffffff;
color: #757575;
margin: 0 auto;
width: 600px;
}
</style>
</head>
<body>
<div id="content">
<p>aqui o conteúdo</p>
</div>
</body>
</html>
veja que neste novo código a quantidade de bytes trafegado será igual, mais com a vantagem de não haver bloqueio de renderização e não haver duas chamadas para o servidor web.
PS: não esqueça de compactar o HTML e remover os pespaços em branco
Mesma quantidade de Bytes Kraus? Isso esta certo?
Sim, e sabe por quê?. Quando, no primeiro exemplo, havia dois arquivos, um HTML e outro CSS. O CSS tem 106 bytes (comprimido) e o HTML tem 197 bytes quando comprimido.
Já o segundo exemplo possui 277 Bytes quando comprimido. Então, 106+197=303 Bytes o que é menor que os 277 bytes o que da 26 bytes de diferença. E sabe da onde vem a diferença? Confira abaixo a diferença das duas chamadas do CSS. A primeira tem 26 caracteres a mais…
<style></style> <link rel="stylesheet" href="style.css"/>
E, só há uma requisição para o servidor...
Ai, você vai dizer que o cache ajudará o usuário quando ele acessar uma segunda página em seu site, correto? Pois sim, mais logo em seguida vou explicar como ganhar mais velocidade ainda quando este for para uma segunda página do seu site.
Mais antes vamos ver o JavaScript.
O JavaScript é um dos maiores vilões quando se fala em bloqueio de renderização. Isso porque o navegador quando encontra uma chamada para um arquivo JavaScript, ele para tudo o que esta fazendo para buscar o JavaScript e o renderia antes de prosseguir com seu trabalho.
Abaixo tenho um exemplo bem comum de página WEB:
<!DOCTYPE html> <html lang="pt-BR"> <head> <meta charset="UTF-8"> <title>Título</title> <script src="js/jquery.min.js"></script> <script src="js/jquery-ui.min.js"></script> <script src="js/custom.js"></script> </head> <body> <div id="content"> <p>aqui o conteúdo</p> </div> </body> </html>
O Browser dos eu cliente analisa linha por linha e quando chega no primeiro SCRIPT ele para a renderização e vai até o servidor para buscar o arquivo /js/jquery.min.js. Neste ponto ele teve o primeiro bloqueio de renderização.
Quando ele recebe o arquivo, e volta ao trabalho de renderização, ele encontra um outro SCRIPT e o processo se repete. Neste ponto ele teve o segundo bloqueio de renderização. E logo ele acha mais um SCRIPT e tem o terceiro bloquei.
Então, você chegou a perceber que em um simples exemplo citado acima, ele teve três paradas só para carregar JavaScript?
O que deve ser feito, é compilar todos os arquivos JS em um único arquivo JS e coloca-lo no final do arquivo.
<!DOCTYPE html> <html lang="pt-BR"> <head> <meta charset="UTF-8"> <title>Título</title> </head> <body> <div id="content"> <p>aqui o conteúdo</p> </div> </body> <script src="/js/js_compilado.js"></script> </html>
Parece não ser simples? Mais no POST Compilando arquivos JavaScript lhe ensino a fazer isso fácil fácil.
Quando se fala em jQuery, os tutoriais falam em fazer da seguinte forma:
$(document).ready(function(){
// aqui seu código javascript
});
Ou assim:
$(function(){
// aqui seu código javascript
});
Você já deve ter visto né? E faz né? Pois é, sinto lhe informar, mais isso atrapalha o carregamento. Então, agora vou mostrar como é o correto a ser feito.
Use o evento onload para chamar uma função dentro do seu arquivo que substitui o ready do Jquery.
No arquivo HTML faça assim:
. . . </body> <script src="/js/js_compilado.js" async onload="compiladoOnload()"></script> </html>
E no arquivo JavaScript deve ser feito assim:
function onloadExecute() {
// aqui seu código javascript
}
Agora ficou bom. Muiiiito bom.
async e o onload? O async diz ao seu navegador que o carregamento deste JavaScript deverá acontecer de forma assíncrona, junto com a renderização da página, fazendo com que não cause o bloqueio de renderização.
Então, agora você deve estar se perguntando, do porque não só colocar o async no primeiro exemplo. Pois bem, mesmo sendo assíncrono, o carregamento poderá causar demora na renderização, pois o navegador terá que trabalhar em dois casos ao mesmo tempo. E, como a prioridade deve ser para conteúdos visíveis, JavaScript deve ser deixado de lado até o conteúdo visível ser totalmente carregado.
O onload tem a tarefa de chamar uma função assim que o JavaScript for totalmente carregado. Isso faz com que só seja executado quando não haver mais nenhum item aguardando ser retornado do servidor. Assim, prioriza-se todos os recursos de processador e memória para conteúdo visível. Simples não?