Uma das coisas mais óbvias que se podem dizer a respeito de donos de sites na Internet é que eles querem o máximo possível de velocidade. Depois o máximo possível em amor por parte do Google. Por fim, segurança nunca é demais. Agora é possível ter tudo isso com o HTTP/2.
Isso tudo porque são esses os três fatores não vinculados à aparência do site responsáveis pela visitação que as páginas recebem.
O protocolo HTTP/2 chegou há algum tempo, a segunda versão do HTTP que é a base da web como conhecemos. É uma atualização desejável que contempla os três fatores acima descritos, agora sem necessariamente custar mais caro para quem mantém um ou vários sites.
Seções desta página
A inovação tecnológica do HTTP/2: multiplexação
A principal diferença entre as versões antigas e nova do HTTP diz respeito a um recurso chamado de “requisições multiplexadas”. Para entender o significado desta mudança é necessário primeiro recapitular a especificação do HTTP/1 a fim de criar um parâmetro de comparação.
Quando um cliente HTTP requisita uma URL ele recebe um documento que referencia outros objetos que são necessários à correta exibição daquele conteúdo, tais como arquivos CSS, JavaScript, imagens, e outros.
No HTTP/1 cada objeto desse é requisitado sequencialmente, interpretado e, quando for o caso, exibido na tela do dispositivo de navegação. — Na verdade há uma média de 4-6 requisições simultâneas, mas para efeitos didáticos vamos ignorar este dado.
Cada uma dessa conexão deve ser completada e fechada para que a próxima possa ser aberta e o próximo objeto processado.
Já no HTTP/2 em vez de existir uma requisição para cada objeto, existe uma única conexão entre o dispositivo visitante e o servidor web. Desta forma, todos os objetos são enviados do servidor para o cliente através dessa mesma conexão, que só é encerrada quando a página toda está carregada e não há mais objetos a serem transferidos (ao menos na maior parte dos casos).
Essa diferença entre muitas conexões (dependendo da página podem ser centenas) e uma única, associada aos protocolos de compactação de conteúdo (popularmente conhecido como “gzip”) que também fazem parte da especificação do HTTP/2, pode representar ganhos de desempenho de até 300% ou mais. Inclusive, há casos em que pudemos observar ganhos até acima desta marca.
Simplificação do desenvolvimento
Para os programadores front-end, então, o HTTP/2 é um sonho que se realiza: devido à multiplexação técnicas até então “atuais” de otimização deixam de fazer sentido. Exemplos:
- CSS Sprites: como todas as imagens de uma página são transmitidas em conjunto numa única requisição TCP, mas ficam disponíveis individualmente no cache do navegador, não há mais necessidade de utilizar-se do recurso de juntar todas as imagens em uma só e “recortá-la” usando CSS.
- Lazy Loaders: também por causa da multiplexação já não faz mais sentido o uso de lazy loaders, scripts que servem para que as imagens da página sejam carregadas somente à medida que forem necessárias; seu uso em sites HTTP/2 quebra justamente a funcionalidade mais importante da nova versão do protocolo.
- Pre-loaders: pelo mesmo motivo pelo qual não vale a pena fazer o carregamento tardio de imagens num site usando HTTP/2, não há mais motivo para fazer o carregamento antecipado. A regra geral diz que é preferível deixar a critério dos programas (cliente e servidor) a decisão sobre o que carregar primeiro, uma vez que ambos estão sintonizados no objetivo de propiciar o carregamento mais rápido possível de uma página num dado momento.
- CDNs: se antes era uma estratégia recomendável distribuir os objetos do site por múltiplos domínios com o fito de otimizar o uso de conexões TCP paralelas, com a multiplexação este uso deixa de ser assim tão desejável; não que as CDNs estejam mortas (longe, muito longe disso), mas sim que seu uso agora deverá ser melhor avaliado (assim como o carregamento de web-fonts que não estejam no próprio domínio do site, ou de bibliotecas como a jQuery a partir de servidor de terceiros).
HTTP/2 é um protocolo criptografado
O HTTP/2 foi desenvolvido em cima do SPDY, um protocolo criado pela Google cujo objetivo era acelerar a Internet e ao mesmo tempo torná-la mais segura: o navegador só utilizaria as melhorias do SPDY se o site estivesse operando em HTTPS, ou seja, caso tivesse um certificado SSL válido e funcional nele.
O HTTP/2 acabou “herdando” essa característica, talvez por força de uma eventual pressão dos fabricantes de navegadores que recusaram-se a implementar a nova versão do HTTP para sites não seguros.
Assim, a Internet está presenciando uma virada de jogo sensacional: há não muito tempo (2015, por exemplo) o HTTPS ainda era conhecido por ser um protocolo lento, devido à necessidade de uma camada extra de processamento para criptografar os dados no servidor, e para descriptografar no cliente.
Agora, com o advento do HTTP/2, o HTTPS é muito mais rápido do que o HTTP/1, pois a economia de recursos promovida pela multiplexação de requisições TCP supera largamente o trabalho extra na camada de criptografia.
O amor do Google
Se acelerar o site e torná-lo mais seguro (e subjetivamente mais confiável aos olhos do visitante médio) já não fossem atrativos bastantes para o HTTP/2, ele conta com um outro fator: já faz algum tempo que é de conhecimento público que a criptografia é um dos “sinais de ranqueamento” que o indexador utiliza para priorizar (ou não) a aparição de uma determinada URL nas páginas de resultado.
HTTP/2 é HTTPS e requer certificado SSL válido
Há não muito tempo o custo de um certificado SSL era proibitivo. Quem precisasse criptografar alguns domínios teria de desembolsar uma soma considerável, que para muita gente seria impeditivo (inclusive para muita gente “graúda” do mercado).
Como já dissemos isso é resultado dos fabricantes de navegadores, mais notadamente da Google com seu quase onipresente Chrome, que se recusam a suportar os recursos do HTTP/2 em conexões não criptografadas.
Entretanto, muitas entidades certificadoras resolveram render-se ao mercado e passaram a oferecer certificados SSL gratuitos.
Quando usar e quando não usar HTTP/2
Recomendamos a utilização de HTTP/2 em todo e qualquer site na Internet, exceto no caso de uma das situações abaixo.
- Quando sua audiência for predominantemente de usuários de Windows XP: os certificados gratuitos Let’s Encrypt não são, ainda, compatíveis com o finado Windows XP; todos os sistemas operacionais modernos de plataformas móveis ou desktop são plenamente compatíveis com os certificados Let’s Encrypt e CloudFlare.
- Quando o site veicular anúncios ou outros objetos HTTP e que não seja possível convertê-los para HTTPS: há casos de redes de anúncios que não oferecem seus códigos de anúncios em HTTPS; nesse caso a adoção do HTTP/2 poderá representar queda de receita para o site, justificando assim esperar até que os patrocinadores reconheçam a necessidade de adequar-se aos padrões mais recentes e mais seguros.
Felizmente é bem fácil de reverter o processo de migração de HTTP/1 para HTTP/2.
Acelere seu site aproveitando melhor o HTTP/2
Assim como nós, sabemos que você também quer ter o seu site carregando o mais rápido possível, por diversos motivos: porque o usuário gosta mais, porque o Google favorece quem tem sites rápidos, porque é bom de brincar com os amiguinhos de “quem tem o PageSpeed maior”.
Da nossa parte, só interessa ficar melhor posicionado no buscador, o que exige que o site preste um bom serviço ao visitante.
Um dos grandes avanços que o protocolo HTTP/2 trouxe para a Internet está o aumento de desempenho (leia-se: de velocidade de carregamento) das páginas que trafegam sob este protocolo. As principais tecnologias encarnadas no HTTP/2 são:
- o push — que permite forçar a partir do servidor o envio de objetos (scripts, imagens, etc) para o cliente;
- a multiplexação TCP, que permite que vários objetos (arquivos, de maneira grosseiramente simplificada) trafeguem ao mesmo tempo pela mesma conexão;
- e o preconnect, que permite sinalizar ao navegador quais outros domínios serão utilizados na mesma página, para que este antecipe em segundo plano as resoluções de DNS e mesmo de, literalmente, conexão antecipada a estes locais remotos.
Justamente do preconnect que vamos tratar hoje, ensinando como identificar os domínios que precisam de conexão antecipada e como implementá-los no código do seu site.
Identificando os domínios externos ao site
Para identificar os domínios que precisam de preconexão vamos utilizar uma ferramenta qualquer que permita visualizar no modo “cascata” (ou waterfall nas ferramentas em Inglês) tudo o que compõe uma determinada página.
Nossa ferramenta favorita para este mister é o Pingdom Website Speed Test — que daqui para frente será apenas “Pingdom”, por motivos de clareza e simplicidade.
Para identificar os domínios que precisam de conexão antecipada devemos observar a lista de recursos carregados na página na visualização waterfall e tomar nota de tudo que não seja do nosso domínio.
Adicionando o código de conexão antecipada ao site
Agora, é necessário adicionar um código específico na seção <head></head> do template.
Trata-se da tag <link rel='preconnect'> — que basicamente diz ao navegador algo como: “Ei, Chrome, nós vamos precisar de uma conexão ao domínio tal daqui a pouco. Vai se preparando aí”.
A sintaxe dessa tag é: <link rel='preconnect' href='...'>
Assim, para incluir os domínios externos na lista basta seguir o exemplo abaixo:
<link rel='preconnect' href='//dominio-externo.com.br' />
Vale ressaltar que não basta indicar o domínio no href. É necessário indicar o protocolo http:// ou https:// ou a notação do HTML5.
Agora é só voltar a testar seu site e ver a pontuação melhorar graças à conexão prévia com os serviços externos.
Como ativar o HTTP/2 no seu site
É muito simples ativar o HTTP/2 no seu site: basta entrar em contato conosco por meio de um chamado de suporte e pedir uma avaliação. Se não houver nenhum impedimento, em questão de minutos seu novo site estará chutando bundas com o que há de mais recente em tecnologia de serviço web!