Adoção do HTTP/3 estaciona nos 21% — a física por trás do travamento

Quando a IETF padronizou o HTTP/3 em 2022, a promessa era clara: um protocolo construído sobre o QUIC, eliminando o head-of-line blocking do TCP, com estabelecimento de conexão mais rápido e melhor desempenho em redes não confiáveis. Quatro anos depois, 39,5% dos sites suportam HTTP/3 — mas apenas 21,11% das requisições reais o utilizam, abaixo do pico de 22,16% em janeiro de 2026. A curva de adoção achou um platô.

Essa não é uma história sobre desenvolvedores lentos em atualizar. É uma história sobre física.

O Paradoxo das Redes Rápidas

Em conexões de alta largura de banda e baixa latência — o tipo que a maioria dos usuários corporativos e tráfego de data center usa — o HTTP/3 tem desempenho pior que o HTTP/2. Um artigo de 2024 apresentado na ACM Web Conference mediu uma redução de 45,2% na taxa de dados para QUIC em comparação com HTTP/2 em redes acima de 500 Mbps. O motivo: os algoritmos de controle de congestão do QUIC foram projetados para redes móveis com perda de pacotes e imprevisíveis. Em fibra ótica, eles se tornam conservadores de uma forma que os algoritmos do TCP, com décadas de uso, não são.

Além disso, o QUIC roda sobre UDP, o que significa que ele não pode aproveitar o hardware offloading embutido em placas de rede modernas para TCP. Cada pacote QUIC exige ciclos de CPU que pacotes TCP não exigem. Em escala, em data centers processando milhões de requisições por segundo, essa sobrecarga é significativa.

Onde o HTTP/3 Realmente Vence

A história de desempenho é diferente em redes móveis e mercados emergentes. O relatório de desempenho de 2025 da Akamai encontrou redução de 30% na latência em conexões com perda de pacotes acima de 2% — condição comum em redes celulares na África, sul da Ásia e Europa rural. Para usuários em Wi-Fi congestionado ou alternando entre torres de celular no meio da sessão, a migração de conexão do HTTP/3 (que mantém uma sessão mesmo quando o IP do cliente muda) é uma melhoria real em relação à necessidade do TCP de restabelecer conexões.

Isso cria uma divisão estranha: o HTTP/3 ajuda os usuários que mais precisam — aqueles em conexões ruins — mas piora marginalmente as coisas para usuários em conexões rápidas que carregam a maior parte do tráfego em volume.

Adoção por CDNs Versus Realidade do Tráfego

Os principais provedores de CDN — Cloudflare, Fastly, Akamai — todos suportam HTTP/3 nativamente. O mercado de serviços de edge habilitados para QUIC está crescendo de US$ 2,84 bilhões em 2025 para US$ 3,79 bilhões em 2026 a um CAGR de 33%. Mas suportar um protocolo e rotear tráfego sobre ele são decisões diferentes. As CDNs estão cada vez mais oferecendo ativação seletiva de HTTP/3 com base nas características do cliente: clientes móveis com alta latência medida recebem QUIC, enquanto clientes desktop em fibra ótica recebem HTTP/2.

Essa implantação seletiva é provavelmente mais saudável do que a adoção em massa. Significa que os ganhos do HTTP/3 se concentram onde são reais e seus custos permanecem invisíveis para usuários que não se beneficiariam.

O Platô de 21% Não é um Fracasso

Enquadrar a curva de adoção como falha interpreta mal o que aconteceu. O HTTP/3 alcançou exatamente o que foi projetado para fazer — melhorou o desempenho para conexões com perda de pacotes e alta latência. O erro foi a narrativa mais ampla de que ele substituiria universalmente o HTTP/2 para todo tráfego. Protocolos não funcionam assim.

A leitura mais precisa: HTTP/3 continuará sendo o padrão para tráfego mobile-first, conexões CDN-cliente com qualidade variável e qualquer cenário onde a migração de conexão ou streams multiplexados justifiquem a sobrecarga do UDP. O HTTP/2 continuará dominante para tráfego servidor-para-servidor, data center e clientes de alta largura de banda onde as otimizações de hardware do TCP e o controle de congestão maduro têm vantagens.

Para engenheiros tomando decisões de implantação hoje, o aprendizado é prático: meça seu perfil de tráfego real antes de assumir que HTTP/3 melhora algo. Se seus usuários estão principalmente em conexões de alta largura de banda com baixa perda de pacotes, a troca de protocolo pode custar a você taxa de transferência. Se estão em dispositivos móveis em mercados com cobertura variável, provavelmente ajuda.

O que Vem a Seguir

O grupo de trabalho QUIC na IETF está ciente da lacuna de desempenho em alta largura de banda. Há trabalho em andamento em algoritmos de controle de congestão para QUIC que explorem melhor a largura de banda em redes confiáveis, e em suporte a UDP offloading em nível de hardware que possa reduzir a diferença de custo de CPU com TCP. Essas melhorias levarão tempo para se propagar pelo ecossistema.

Enquanto isso, a participação de 21% do HTTP/3 não é um teto — é onde o protocolo se estabilizou naturalmente, dado seu envelope de desempenho. Se vai crescer mais depende menos do suporte dos navegadores (que é universal) e mais de se as características de desempenho do protocolo melhorarem nos tipos de rede que carregam a maior parte do tráfego.