Revisitando práticas de performance front-end depois do HTTP/2 | iMasters
Performance Web tem uma importância imensa. Um site performático é melhor para o usuário e para as conversões, trazendo mais retorno para a empresa.
Agora com o HTTP/2, várias técnicas desses tipos passam a ser desnecessárias. Às vezes, podem até ser prejudiciais. Antes de prosseguirmos, dê uma conferida nas novidades do HTTP 2.0 para que possamos analisar seus impactos.
O HTTP/2 deixa as requisições em si mais baratas. O GZIP, por exemplo, importante desde o HTTP/1, já costuma estar habilitado nos servidores HTTP/2.
Mais que isso: um alto custo de se fazer vários requests no HTTP 1.1 era o tráfego dos cabeçalhos (headers). Eles não eram comprimidos, mas enviados em texto puro. E, pra piorar, cabeçalhos tinham que ser mandados novamente a toda requisição.
No HTTP 2.0, os cabeçalhos são binários e compactados. Além disso, com os header tables, o navegador e o servidor podem mandar um certo header uma vez só e reaproveitar para as requisições seguintes. Só é preciso mandar os cabeçalhos que mudam. Isso deixa as requisições ainda mais baratas e justificam ainda mais a prática de usar vários requests, ao invés de concatenar as coisas como fazíamos antigamente.
Então, no HTTP 1.1, a boa prática sempre foi diminuir os requests, concatenando arquivos CSS e JS, criando sprites e até fazendo inline do recurso direto no HTML da página. Tudo isso é desnecessário no HTTP 2.0, o que facilita muito a vida do desenvolvedor.
A limitação nas requisições no HTTP 1.1 é tão grande que nasceram diversas técnicas para passar por cima disso. A mais comum era a utilização de múltiplos hostnames para aumentar o limite de conexões paralelas. O browser abria, então, 6 conexões com o hostname principal, mas a página usava mais outros endereços para ganhar mais 6 conexões, como imagens.meusite.com. Isso é trabalhoso de fazer.
No HTTP 2.0, usar vários hostnames é uma má-prática, principalmente por anular os benefícios do multiplexing. Agora, a conexão única do protocolo consegue paralelizar todos os requests e responses e não é mais necessário várias conexões.
Fiz um página de testes com 200 arquivos JavaScript separados com tamanho médio de 13 KB cada um. Cada arquivo, quando executado, pintava um quadrado verde na tela, assim, conseguimos visualizar o carregamento individual. O primeiro teste, usando HTTP 1.1 mostrou esse resultado:
A boa prática do HTTP 1.1, então, nos dizia para juntarmos tudo em um arquivo só. Refiz o teste, veja a diferença:
A mágica acontece quando testamos com HTTP/2 usando os 200 arquivos separados:
Repare como o multiplexing permite o download paralelo de muitas coisas, diminui a espera e praticamente junta o melhor dos dois mundos. O tempo final continua baixo em 7s e o tempo do primeiro script fica em 1.2s. Ou seja, requests em paralelo, execução progressiva e tempo total excelente.
Tchau inline de recursos, bem vindo Server Push
No HTTP 1.1, costumava ser uma boa ideia pegar recursos pequenos e essenciais e inserir seu conteúdo direto no HTML – uma prática chamada de inline de recursos. Isso é ruim, pois os recursos não podem ser cacheados individualmente.
No HTTP 2.0, existe um recurso chamado Server Push que permite enviar requisições para o cliente antes mesmo dele as requisitá-las. O próprio protocolo suporta o envio de respostas para os clientes antes do request ser feito – você só precisa configurar seu servidor pra isso; algo bem simples.
Na prática, são as vantagens do inline de enviar coisas junto com o HTML inicial sem suas desvantagens.
Resumindo o que vimos até agora, várias práticas param de fazer sentido no HTTP 2.0:
Então, onde focar os esforços de otimização? Há várias práticas mais específicas e avançadas, que, inclusive, discuto bastante nos meus cursos de Performance Web na Alura. No geral, são práticas do tipo:
Usar Server-push e Server-hints
Animações a 60 FPS
O importante é perceber que só a utilização do HTTP 2.0 já vai fazer muita coisa para a gente. As outras otimizações são mais específicas e nem sempre aplicáveis.