O que é HTTP/2?

HTTP/2 é a segunda grande versão do protocolo Hypertext Transfer Protocol, finalizada como RFC 7540 em maio de 2015. Foi a primeira atualização significativa ao HTTP desde a padronização do HTTP/1.1 em 1997, e abordou problemas fundamentais de desempenho que assombravam a web por quase duas décadas. Se o seu site WordPress ainda serve conteúdo via HTTP/1.1, é provável que você esteja deixando ganhos significativos de desempenho na mesa.

O protocolo cresceu a partir do protocolo experimental SPDY do Google, que estava em uso desde 2012 e provou que as ideias centrais do HTTP/2 (multiplexação, compressão de cabeçalhos, priorização) funcionavam bem em produção. Quando o IETF padronizou o HTTP/2, o SPDY foi aposentado e suas ideias se tornaram a base do novo padrão.

Principais melhorias em relação ao HTTP/1.1

Para entender por que o HTTP/2 importa, primeiro é preciso entender o que havia de errado com o HTTP/1.1. Sob o protocolo antigo, cada conexão TCP só conseguia lidar com uma requisição por vez. Se o seu navegador precisava carregar 40 recursos (uma página WordPress típica), ele tinha que abrir várias conexões (os navegadores tipicamente permitem 6 por domínio) e enfileirar as requisições restantes. Isso criava gargalos artificiais que tornavam cada carregamento de página mais lento.

O HTTP/2 corrige isso e mais:

Multiplexação: essa é, sozinha, a maior melhoria. O HTTP/2 permite que múltiplas requisições e respostas estejam em trânsito simultaneamente sobre uma única conexão TCP. Seu navegador pode pedir o arquivo CSS, três arquivos JavaScript e dez imagens, todos ao mesmo tempo, em uma única conexão. Sem mais espera, sem mais filas, sem mais limites artificiais. O servidor envia as respostas conforme ficam disponíveis e o navegador as monta. Essa única mudança pode reduzir drasticamente os tempos de carregamento em sites WordPress com muitos recursos.

Compressão de cabeçalhos (HPACK): cabeçalhos HTTP são enviados a cada requisição e resposta. No HTTP/1.1, esses cabeçalhos são texto simples e frequentemente repetitivos. Os mesmos cookies, strings de user-agent e cabeçalhos accept são enviados repetidamente. O HTTP/2 usa um algoritmo de compressão chamado HPACK, que mantém uma tabela compartilhada de campos de cabeçalho comuns entre cliente e servidor. Após a primeira requisição, os cabeçalhos subsequentes só precisam enviar as diferenças. Para um site WordPress que carrega 50+ recursos por página, isso pode economizar dezenas de kilobytes por carregamento.

Frame binário: o HTTP/1.1 é um protocolo baseado em texto, o que significa que o parser precisa procurar por quebras de linha, lidar com diferentes codificações de texto e lidar com vários casos extremos. O HTTP/2 usa uma camada de framing binário que envolve toda a comunicação em frames bem definidos. Dados binários são mais rápidos de fazer parse, menos propensos a erros e mais compactos. Você nunca notará isso como usuário, mas reduz a sobrecarga de processamento tanto no servidor quanto no cliente.

Priorização de streams: o HTTP/2 permite ao navegador dizer ao servidor quais recursos são mais importantes. Por exemplo, o navegador pode sinalizar que o arquivo CSS principal deve ser entregue antes das imagens de fundo. O servidor pode então alocar a banda de acordo. Na prática, as implementações de priorização nos navegadores variam, e nem todos os servidores lidam com isso perfeitamente, mas ainda assim oferece melhorias significativas para muitos sites.

Server Push: esse recurso permite ao servidor enviar recursos ao navegador antes mesmo de ele os solicitar. Quando o navegador pede uma página HTML, o servidor pode fazer push dos arquivos CSS e JavaScript que sabe que o navegador vai precisar em seguida. Isso elimina o atraso de round-trip de o navegador descobrir que precisa de um recurso e então requisitá-lo. Entretanto, o Server Push teve adoção limitada na prática. É difícil de implementar corretamente (fazer push de recursos que o navegador já tem em cache desperdiça banda) e algumas CDNs descontinuaram o suporte. O Chrome removeu o suporte ao Server Push na versão 106 (2022). O conceito sobrevive no mecanismo 103 Early Hints, que é mais simples e prático.

Por que domain sharding não é mais necessário

Na era do HTTP/1.1, desenvolvedores web usavam um truque chamado domain sharding para contornar o limite de 6 conexões por domínio. Eles serviam imagens em img1.example.com, CSS em cdn.example.com e fontes em ainda outro subdomínio. Isso multiplicava o número de conexões paralelas que o navegador podia abrir.

Com o HTTP/2, o domain sharding não é só desnecessário, mas na verdade contraproducente. Como o HTTP/2 multiplexa todas as requisições em uma única conexão, dividir recursos em múltiplos domínios força o navegador a estabelecer conexões TCP e handshakes TLS adicionais. Cada nova conexão adiciona latência. Um site WordPress que foi otimizado com domain sharding para HTTP/1.1 deve consolidar seus recursos em menos domínios ao migrar para HTTP/2.

Da mesma forma, concatenar arquivos CSS e JavaScript em bundles únicos (outra otimização comum no HTTP/1.1) se torna menos importante com HTTP/2. Enviar muitos arquivos pequenos funciona eficientemente graças à multiplexação, e ainda traz o benefício de melhor cache: quando um pequeno arquivo muda, só ele precisa ser baixado de novo, não o bundle concatenado inteiro.

HTTP/2 exige HTTPS na prática

A especificação do HTTP/2 não exige tecnicamente criptografia. Você pode ter HTTP/2 sobre TCP puro (chamado h2c, para HTTP/2 cleartext). Entretanto, todos os principais navegadores (Chrome, Firefox, Safari, Edge) decidiram implementar HTTP/2 apenas sobre TLS (chamado h2). Isso significa que, para todos os efeitos práticos, você precisa de um certificado SSL/TLS para usar HTTP/2.

Isso não é mais realmente uma limitação. Certificados gratuitos do Let's Encrypt tornaram o HTTPS acessível a todos, e a maioria dos provedores de hospedagem WordPress inclui certificados SSL em seus planos. Se o seu site WordPress ainda está em HTTP simples, migrar para HTTPS é um pré-requisito para o HTTP/2 e traz seus próprios benefícios de segurança.

HTTP/3 e QUIC: o próximo passo

O HTTP/3 (RFC 9114, finalizado em junho de 2022) é a próxima evolução. Enquanto o HTTP/2 roda sobre TCP, o HTTP/3 substitui o TCP por completo por um novo protocolo de transporte chamado QUIC. O QUIC é construído sobre UDP e incorpora a criptografia TLS 1.3 diretamente na camada de transporte. As principais vantagens do HTTP/3 sobre o HTTP/2 são:

• Configuração de conexão mais rápida: o QUIC combina o handshake do TCP e o handshake do TLS em um único round-trip, reduzindo o tempo de configuração da conexão. Para visitantes recorrentes, pode até alcançar reabertura de conexão com zero round-trip.
• Sem head-of-line blocking: no HTTP/2 sobre TCP, se um único pacote é perdido, todos os streams daquela conexão travam até o pacote ser retransmitido. O QUIC trata a perda de pacote por stream, então um pacote perdido só atrasa o stream afetado, e não tudo o mais.
• Melhor desempenho móvel: o QUIC lida com mudanças de rede (como alternar entre WiFi e celular) de forma mais elegante, porque as conexões são identificadas por um ID de conexão e não por endereço IP e porta.

Grandes provedores de CDN como Cloudflare e Fastly já suportam HTTP/3. A maioria dos provedores de hospedagem ainda está em processo de adoção. Para proprietários de sites WordPress, o suporte ao HTTP/3 é, em grande parte, uma preocupação do lado do servidor; você não precisa mudar nada no WordPress em si.

Como verificar se sua hospedagem suporta HTTP/2

Existem várias maneiras de verificar se o seu site WordPress é servido via HTTP/2:

• DevTools do navegador: abra a aba Network no DevTools do Chrome, clique com o botão direito nos cabeçalhos das colunas e habilite a coluna "Protocol". Você deve ver h2 para requisições HTTP/2.
• Ferramentas online: sites como o teste HTTP/2 da KeyCDN ou o verificador HTTP/2 em tools.keycdn.com podem confirmar o suporte a HTTP/2 para qualquer URL.
• Linha de comando: execute curl -I --http2 -s https://yoursite.com e procure por HTTP/2 200 na resposta.
• InspectWP: o relatório inclui a versão HTTP detectada para o seu site WordPress.

Se sua hospedagem não suporta HTTP/2, colocar uma CDN como Cloudflare na frente do seu site pode oferecer suporte a HTTP/2 (e HTTP/3) mesmo se o servidor de origem só falar HTTP/1.1. A CDN cuida da conexão HTTP/2 com o navegador do visitante e se comunica com seu servidor de origem usando o protocolo que ele suportar.

Implicações de desempenho para o WordPress

Uma página WordPress típica carrega entre 20 e 80 recursos individuais: folhas de estilo do tema e dos plugins, arquivos JavaScript, web fonts, imagens e às vezes recursos externos de CDNs e serviços de terceiros. Sob HTTP/1.1, carregar todos esses recursos era o maior contribuinte para o tempo de carregamento da página, devido às limitações de conexão e enfileiramento.

Após migrar para HTTP/2, a maioria dos sites WordPress observa melhorias significativas no Time to First Contentful Paint e no tempo geral de carregamento. A melhoria exata depende de quantos recursos seu site carrega, mas reduções de 20-50% no tempo de carregamento são comuns em sites antes em HTTP/1.1. Sites com muitos recursos pequenos (típico do WordPress com vários plugins ativos) são os que mais se beneficiam.

Tenha em mente que o HTTP/2 não substitui outras otimizações de desempenho. Você ainda precisa de cache adequado, otimização de imagens e código eficiente. Mas o HTTP/2 remove um gargalo significativo no nível da infraestrutura que nenhuma quantidade de otimização de plugin do WordPress consegue resolver.

O que o InspectWP verifica

O InspectWP detecta a versão do protocolo HTTP usada pelo seu site WordPress examinando os cabeçalhos de resposta. Se o seu site é servido via HTTP/1.1, o relatório o sinaliza como uma preocupação de desempenho e recomenda a atualização para HTTP/2. Se HTTP/2 ou HTTP/3 é detectado, é relatado como um achado positivo. A versão HTTP é exibida na seção de desempenho do relatório, junto com outras métricas no nível do servidor, como compressão e cabeçalhos de resposta.