O que são HTTP/2 e HTTP/3? Um guia prático para sites WordPress

HTTP/2 e HTTP/3 são as duas versões atuais do Hypertext Transfer Protocol, a linguagem que os navegadores usam para solicitar páginas aos servidores web. HTTP/2 foi padronizado em 2015 e é suportado por 100% dos navegadores modernos. HTTP/3, finalizado como RFC 9114 em 2022, é suportado por todos os navegadores principais desde 2024. Ambos são upgrades plug-and-play sobre HTTP/1.1: mesmas URLs, mesmo HTML, mas carregamentos de página significativamente mais rápidos, especialmente em redes móveis e conexões de alta latência.

Resposta rápida: qual versão meu site WordPress deve usar?

Em 2026, a resposta certa é "HTTP/3 com fallback para HTTP/2". Cada navegador negocia a versão mais alta que ambos os lados suportam, então você não precisa escolher. Se seu servidor fala HTTP/3, navegadores modernos o usam; navegadores mais antigos caem para HTTP/2; clientes antigos caem para HTTP/1.1. Não existe cenário em que HTTP/2 ou HTTP/3 seja mais lento que HTTP/1.1 para uma página WordPress real, então a única pergunta é se seu stack de hospedagem suporta.

Que problema o HTTP/2 resolve em relação ao HTTP/1.1?

HTTP/1.1, o protocolo que rodou a web de 1997 a 2015, tem uma falha fatal num site moderno: ele abre uma conexão TCP por recurso, e apenas seis em paralelo por domínio. Uma página WordPress típica carrega de 50 a 150 recursos (CSS, JS, imagens, fontes, scripts de tracking). Sob HTTP/1.1, esses 100+ requests serializam por uma fila de seis conexões, cada uma esperando a anterior terminar. O navegador literalmente fica parado esperando vagas abrirem.

HTTP/2 resolve isso com três mudanças:

Multiplexing. Uma única conexão TCP carrega um número ilimitado de pares request/response paralelos (chamados streams). Todos os 150 recursos viajam por uma conexão, intercalados.
Compressão de cabeçalhos (HPACK). Cabeçalhos HTTP (cookies, User-Agent, referer) frequentemente somam vários KB por request. HPACK os comprime e lembra de cabeçalhos repetidos, reduzindo o overhead por request de kilobytes a bytes.
Framing binário. HTTP/1.1 é baseado em texto e ambíguo para parsear. HTTP/2 usa um formato de frame binário que é mais rápido para servidores e proxies processarem, e elimina uma classe inteira de ataques de smuggling e parsing.

Efeito líquido: uma página WordPress que carrega em 4 segundos por HTTP/1.1 tipicamente carrega em 1,5 a 2,5 segundos por HTTP/2, no mesmo servidor. A melhora é maior em redes móveis porque o overhead de estabelecimento de conexão é amortizado entre todos os requests.

O que o HTTP/3 acrescenta em cima do HTTP/2?

HTTP/3 mantém tudo que HTTP/2 introduziu (multiplexing, compressão de cabeçalhos, framing binário) mas substitui o transporte subjacente. Em vez de TCP, HTTP/3 roda sobre QUIC, um protocolo de transporte construído sobre UDP. Soa como detalhe de implementação, mas conserta três problemas reais de performance:

Head-of-line blocking na camada TCP. HTTP/2 multiplexa streams sobre uma conexão TCP, mas o próprio TCP entrega pacotes em ordem. Se um pacote é perdido, todos os streams naquela conexão travam até a retransmissão chegar. QUIC lida com perda de pacotes por stream, então um único pacote perdido só afeta o stream ao qual pertence.
Estabelecimento de conexão mais rápido. Estabelecer uma conexão HTTPS por TCP requer três round trips (handshake TCP, depois handshake TLS). QUIC os combina em um único round trip para conexões pela primeira vez, e zero round trips para conexões repetidas em poucos minutos (chamado 0-RTT). Numa conexão móvel com 100ms de latência, isso economiza 200-300ms antes mesmo do primeiro byte de conteúdo começar a carregar.
Migração de conexão. Conexões QUIC são identificadas por um connection ID, não por IP + porta. Quando um celular muda de Wi-Fi para celular, a conexão QUIC sobrevive. Conexões TCP teriam que reconectar.

Ganho real em cima do HTTP/2: tipicamente 5-15% mais rápido para primeiros carregamentos de página, mais em redes móveis com perdas, menos numa conexão cabeada estável.

Como verifico qual versão HTTP meu site WordPress está usando atualmente?

Quatro métodos confiáveis, do mais rápido ao mais autoritativo:

Relatório InspectWP. A seção Performance de qualquer relatório InspectWP lista a versão HTTP negociada para o documento principal. Uma linha, sem setup.
Chrome DevTools. Abra DevTools (F12), aba Network, recarregue a página, clique com o botão direito em qualquer cabeçalho de coluna e habilite "Protocol". A coluna mostra h2 para HTTP/2 e h3 para HTTP/3 (também chamado http/3 em algumas versões do Chrome).
Linha de comando com curl. Execute curl -I --http2 https://seusite.com para HTTP/2 ou curl -I --http3 https://seusite.com para HTTP/3 (curl 7.66+ necessário). A linha de resposta mostra HTTP/2 200 ou HTTP/3 200.
Ferramentas públicas de teste. https://http3check.net testa especificamente suporte a HTTP/3. https://tools.keycdn.com/http2-test testa suporte a HTTP/2. Ambos retornam a versão negociada e o cabeçalho Alt-Svc (que anuncia suporte a HTTP/3).

Uma pegadinha: um site pode anunciar HTTP/3 em seu cabeçalho Alt-Svc sem que HTTP/3 realmente esteja funcionando. O cabeçalho diz ao navegador "da próxima vez, tente HTTP/3 na porta UDP 443", mas se UDP estiver bloqueado em qualquer ponto do caminho, o navegador silenciosamente cai para HTTP/2. Sempre verifique com um request real, não apenas o cabeçalho Alt-Svc.

Como habilito HTTP/2 ou HTTP/3 num site WordPress?

Versões HTTP são negociadas no nível do servidor web. O próprio WordPress não tem nada a ver com isso; a escolha é entre seu stack de hospedagem e o navegador. Três cenários cobrem quase todos os sites:

Cenário 1: hospedagem WordPress gerenciada

Quase todo host WordPress gerenciado (Kinsta, WP Engine, Raidboxes, SiteGround, Pressable, Cloudways) entrega HTTP/2 por padrão desde 2018. Suporte a HTTP/3 agora é amplamente difundido mas não universal em 2026. Kinsta, Cloudways, SiteGround, Raidboxes e Pressable têm HTTP/3 habilitado por padrão. WP Engine tem disponível como toggle. Se seu host não está nesta lista, pergunte ao suporte; geralmente é uma mudança de um clique.

Cenário 2: hospedagem compartilhada com cPanel ou Plesk

Hosts cPanel (IONOS, Hostinger, muitos revendedores) tipicamente entregam HTTP/2 por padrão e HTTP/3 em contas mais novas. Verifique habilitando EasyApache 4 com o módulo mod_http2 se ainda não estiver presente. HTTP/3 no Apache requer o módulo mod_http3 que ainda é considerado experimental. O caminho pragmático em hospedagem compartilhada é colocar Cloudflare na frente (o tier gratuito basta) e deixar Cloudflare lidar com a terminação HTTP/3, que é o padrão deles desde 2019.

Cenário 3: VPS ou servidor dedicado autogerenciado

A configuração depende do seu servidor web:

nginx. HTTP/2 precisa de nginx 1.9.5+ e a diretiva http2 na sua linha listen: listen 443 ssl http2;. HTTP/3 precisa de nginx 1.25+ compilado com suporte QUIC: listen 443 quic reuseport; listen 443 ssl; mais add_header Alt-Svc 'h3=":443"; ma=86400';. A flag reuseport é crítica ou HTTP/3 silenciosamente falha em iniciar.
Apache. HTTP/2 precisa de mod_http2 habilitado e a diretiva Protocols h2 h2c http/1.1 no seu virtual host. HTTP/3 no Apache ainda é experimental; a maioria das instalações Apache em produção param em HTTP/2 e colocam nginx, Caddy ou Cloudflare na frente para HTTP/3.
Caddy. HTTP/3 é habilitado por padrão desde Caddy 2.6. Nada para configurar; se HTTPS funciona, HTTP/3 funciona.
LiteSpeed e OpenLiteSpeed. Ambos entregam HTTP/3 por padrão. Uma razão pela qual LiteSpeed ganhou participação no mercado de hospedagem WordPress.

Um requisito que as pessoas esquecem em setups autogerenciados: HTTP/3 requer a porta UDP 443 aberta no firewall. Muitas configurações de servidor padrão só abrem TCP 443. Execute sudo ufw allow 443/udp no Ubuntu ou o equivalente no seu stack de firewall.

Qual é o papel do Cloudflare e outros CDNs?

Um CDN sentado na frente do seu servidor de origem tipicamente termina o protocolo moderno na borda, e depois fala com sua origem por HTTP/1.1 ou HTTP/2. Da perspectiva do visitante, a conexão ao nó de borda do CDN (frequentemente a 20-50ms de distância) é HTTP/3, rápida e moderna. O link do CDN à origem acontece servidor-para-servidor em redes de datacenter onde o protocolo importa muito menos. É por isso que colocar Cloudflare na frente de um host compartilhado rodando apenas HTTP/1.1 ainda dá a maior parte do benefício de velocidade. O visitante nunca toca diretamente na sua origem.

A pegadinha: se sua origem retorna um cabeçalho cache-busting (no-cache, no-store) ou seu conteúdo não é cacheável (páginas WordPress logadas, carrinho WooCommerce), o CDN tem que buscar da origem a cada request, e o hop lento origem-para-CDN se torna o gargalo. Para esses casos, o protocolo na origem ainda importa.

Erros comuns e como evitá-los

Tratar HTTP/2 como bala mágica para sites lentos. HTTP/2 conserta overhead de conexão. Não conserta PHP lento, queries não otimizadas, imagens hero de 5MB, ou JavaScript bloqueando render. Se seu TTFB (time to first byte) é 2 segundos, mudar para HTTP/3 economiza 200ms. Os outros 1800ms ainda são PHP e banco de dados.
Esquecer de manter HTTP/1.1 habilitado. Crawlers de motores de busca, ferramentas de monitoramento e bibliotecas cliente antigas às vezes só falam HTTP/1.1. Desabilitar HTTP/1.1 inteiramente as quebra. Servidores web modernos negociam automaticamente a versão mais alta mutuamente suportada; mantenha todos os três (h3, h2, http/1.1) habilitados.
Concatenar e inlinar assets por hábito de HTTP/1.1. Sob HTTP/1.1, combinar 30 arquivos CSS em 1 era uma grande vitória por causa do limite de conexão. Sob HTTP/2 e HTTP/3, essa otimização para de importar e pode até prejudicar (um único bundle grande invalida o cache para qualquer mudança; 30 arquivos pequenos invalidam apenas os que mudaram). A maioria dos plugins de performance WordPress ainda colocam "combinar tudo" como padrão porque usuários esperam isso, mas não é mais o padrão certo em 2026.
Supor que Alt-Svc significa que HTTP/3 está funcionando. O cabeçalho anuncia suporte a HTTP/3; não garante que a conexão realmente seja estabelecida. Sempre verifique com curl ou DevTools.
Bloquear UDP no firewall. Uma causa comum de HTTP/3 silenciosamente não funcionar. Verifique tanto o firewall do servidor quanto o firewall de rede (security group do provedor cloud, filtragem em nível de ISP em conexões de consumidor).

HTTP/2, HTTP/3 e Core Web Vitals

Os Core Web Vitals do Google medem Largest Contentful Paint (LCP), Interaction to Next Paint (INP) e Cumulative Layout Shift (CLS). Dos três, LCP é o mais afetado pela versão HTTP. O elemento LCP (geralmente a imagem hero ou o maior bloco acima da dobra) precisa baixar completamente antes que LCP possa ser reportado, e velocidade de download é exatamente o que HTTP/2 e HTTP/3 melhoram. Sites que migram de HTTP/1.1 para HTTP/2 veem LCP cair 300-800ms em média. O salto de HTTP/2 para HTTP/3 é menor, tipicamente 50-200ms, mas em redes móveis com perda de pacotes pode ser maior.

O que o InspectWP verifica

A seção Performance de cada relatório InspectWP mostra qual versão HTTP foi negociada para o documento principal, mais a codificação de conteúdo (gzip, Brotli) e o tamanho total do HTML. Se seu site ainda está em HTTP/1.1 em 2026, o relatório sinaliza como aviso, porque é uma das vitórias de performance de maior impacto e menor esforço disponíveis, geralmente um único interruptor no painel de hospedagem. Se você está em HTTP/2 mas não em HTTP/3, isso aparece como informativo; HTTP/3 é o padrão moderno mas HTTP/2 ainda é completamente aceitável. A versão que seu navegador vê é a versão que seus visitantes recebem, então o relatório reflete a performance real, não a configuração teórica.