O que devo implementar primeiro: gzip ou HTTP/3?

Se as respostas de texto não estiverem comprimidas, normalmente faz mais sentido verificar primeiro a compressão de conteúdo, como gzip ou Brotli. Se a compressão já estiver funcionando corretamente, o HTTP/3 poderá oferecer melhorias adicionais em redes com perda de pacotes ou latência e para muitas solicitações simultâneas. No entanto, a prioridade real depende de a imagem de LCP, o CSS ou JavaScript que bloqueia a renderização, ou o TTFB ser o maior gargalo.

Ainda preciso de gzip se usar HTTP/3?

Sim. O QPACK do HTTP/3 é um método de compressão para cabeçalhos HTTP, enquanto gzip é uma codificação de conteúdo que comprime corpos de resposta como HTML, CSS, JavaScript e JSON. Eles operam em camadas diferentes e podem ser usados juntos.

Aplicar gzip a imagens fará com que carreguem mais rápido?

Em geral, não. Arquivos que já são comprimidos, como JPEG, WebP, AVIF, vídeo e áudio, normalmente ganham pouco ao serem comprimidos novamente com gzip e podem apenas adicionar sobrecarga de processamento. Para o desempenho das imagens, é mais importante usar as dimensões e o formato adequados e priorizar as imagens necessárias.

O HTTP/3 sempre reduz o tempo de carregamento para todos os usuários?

Nem sempre. Por meio dos fluxos independentes do QUIC, o HTTP/3 pode reduzir o quanto a perda de pacotes afeta outros fluxos, mas não resolve diretamente o processamento lento no servidor, imagens grandes, recursos que bloqueiam a renderização ou o tempo de execução do JavaScript. HTTP/2 e HTTP/3 devem ser medidos separadamente em ambientes com usuários reais.

Posso oferecer apenas Brotli em vez de gzip?

O suporte a Brotli é amplo nos navegadores modernos, mas os servidores precisam inspecionar o cabeçalho `Accept-Encoding` da solicitação e escolher uma codificação que o cliente aceite. Na prática, é comum oferecer Brotli mantendo gzip como alternativa de compatibilidade.

O que são gzip e HTTP/3 e o que melhorar primeiro no desempenho de carregamento de páginas web?

Por 쉬었음.comPublicado 12 de setembro de 2026

gzip é uma forma de reduzir a quantidade de dados que precisa ser transmitida ao comprimir arquivos de texto de uma página web, enquanto HTTP/3 é um protocolo que altera como várias solicitações são tratadas e como a perda de pacotes é resolvida ao entregar HTTP sobre QUIC. Ambos podem ajudar no carregamento de páginas, mas não resolvem o mesmo problema. Em vez de perguntar “qual é mais rápido, gzip ou HTTP/3?”, é mais preciso primeiro perguntar onde está o gargalo da página atual: bytes transferidos, perda na rede, resposta do servidor, imagens, renderização ou JavaScript.www.rfc-editor.org datatracker.ietf.org

Um dos equívocos mais comuns na prática é achar que habilitar HTTP/3 torna automaticamente um site inteiro mais rápido. HTTP/3 pode ser uma melhoria importante de base, mas não substitui soluções para uma imagem excessivamente grande acima da dobra, CSS ou JavaScript que bloqueia a renderização, ou uma resposta lenta do servidor. Por outro lado, se um site não comprime respostas de texto, habilitar gzip ou Brotli pode reduzir perceptivelmente o volume transferido com uma alteração de configuração relativamente pequena.web.dev developer.mozilla.org

O que é exatamente gzip?

gzip é uma codificação de conteúdo (Content-Encoding) amplamente usada para HTTP. Antes de enviar o conteúdo, o servidor comprime em formato gzip HTML, CSS, JavaScript, JSON, SVG e conteúdos semelhantes; o navegador descomprime e usa o conteúdo original. A especificação HTTP Semantics define gzip como uma codificação de conteúdo que usa compressão da família LZ77 e um CRC de 32 bits.www.rfc-editor.org www.rfc-editor.org

O ponto principal é que o tipo lógico do arquivo não muda. Por exemplo, mesmo quando um servidor entrega app.js com gzip, o navegador executa, no fim, o mesmo JavaScript. O que muda é a quantidade de bytes que trafega pela rede. Quando um arquivo é menor, ele leva menos tempo para baixar em largura de banda limitada e também pode reduzir o uso de dados móveis do usuário.www.rfc-editor.org developer.chrome.com

Como navegadores e servidores escolhem um método de compressão?

Os navegadores usam o cabeçalho de solicitação Accept-Encoding para indicar quais formatos de compressão podem decodificar. Com base nessa lista e em suas prioridades, o servidor seleciona uma representação adequada e adiciona à resposta um cabeçalho como Content-Encoding: gzip ou Content-Encoding: br. br significa Brotli.www.rfc-editor.org developer.mozilla.org

Se um servidor ou CDN fornecer respostas diferentes para a mesma URL conforme o método de compressão, é comum enviar Vary: Accept-Encoding para que os caches as diferenciem. Caso contrário, uma representação comprimida armazenada para um cliente poderia ser reutilizada inadequadamente em uma solicitação com condições diferentes.www.rfc-editor.org

O fluxo conceitual é o seguinte:

O navegador declara os formatos compatíveis, como Accept-Encoding: br, gzip.
O servidor ou CDN escolhe uma das versões Brotli, gzip ou não comprimida do arquivo.
Ele identifica o formato selecionado em Content-Encoding junto ao corpo da resposta.
O navegador descomprime a resposta durante ou após o recebimento e, então, continua a análise de HTML, a aplicação de CSS e a execução de JavaScript.

gzip pode reduzir o tempo de transferência nesse processo, mas não elimina o tempo que o navegador gasta analisando e executando JavaScript. A compressão é uma parte do desempenho, não uma solução para todas as fontes de atraso.developer.chrome.com web.dev

Quais arquivos se beneficiam de gzip?

gzip é especialmente adequado para textos com muitas strings e estruturas repetidas. Dados com repetição substancial, como tags HTML, seletores CSS, identificadores e sintaxe JavaScript e nomes de campos JSON, podem ficar muito menores para transferência após a compressão. Orientações gerais de desempenho web também recomendam aplicar compressão a recursos de texto e excluir ativos que já são comprimidos.developer.mozilla.org web.dev

Tipo de ativo	Avaliação geral para gzip	Áreas de maior prioridade para examinar
HTML	Geralmente adequado	Tempo de resposta do servidor, cache, tamanho do documento
CSS	Geralmente adequado	Remover CSS não usado, gerenciar CSS crítico
JavaScript	Geralmente adequado	Divisão de código, remover código não usado, tempo de execução
JSON e respostas de API	Geralmente adequado	Design da resposta, cache, remover campos desnecessários
SVG	Geralmente adequado	Limpar e simplificar SVGs
JPEG, WebP, AVIF	Geralmente inadequado	Dimensões da imagem, formato, entrega responsiva
MP4 e áudio	Geralmente inadequado	Taxa de bits, streaming, carregamento lento

Para formatos que já realizam compressão por conta própria, como JPEG, WebP, AVIF, vídeo, áudio e arquivos compactados, aplicar gzip novamente pode trazer pouco benefício. O mesmo vale para arquivos pequenos. O web.dev explica que recursos menores que aproximadamente 1 KiB podem ser comprimidos de forma ineficiente ou não proporcionar economia significativa.developer.mozilla.org web.dev

Uma distinção importante aqui é entre tamanho de transferência e tamanho original. No painel Network das ferramentas de desenvolvimento, é possível comparar o tamanho do download comprimido com o tamanho não comprimido e verificar o cabeçalho de resposta Content-Encoding para confirmar se a compressão foi de fato aplicada.developer.chrome.com

Como gzip e Brotli diferem?

Brotli não é um sucessor do gzip; é outro algoritmo que pode ser selecionado junto com gzip para compressão de conteúdo HTTP. Na web moderna, é comum priorizar Brotli para ativos de texto e também oferecer gzip a clientes que não podem usar Brotli. Como os navegadores enviam Accept-Encoding e os servidores negociam o resultado, diferentes representações comprimidas podem ser enviadas para a mesma URL, dependendo do cliente.developer.mozilla.org developer.mozilla.org

Em geral, Brotli pode produzir resultados menores que gzip para textos web. Contudo, isso nem sempre significa uma melhoria proporcional na velocidade percebida da página como um todo. Se os bytes economizados forem poucos ou se o gargalo estiver nas imagens, no processamento do servidor ou na execução de JavaScript, trocar gzip por Brotli pode ter efeito limitado. Em servidores que comprimem dinamicamente, configurações que aumentam a taxa de compressão também podem aumentar o uso de CPU e a latência da resposta. Portanto, ativos estáticos devem ser pré-comprimidos na etapa de build ou da CDN, enquanto respostas dinâmicas devem ser ajustadas com base na carga real.web.dev web.dev

Em outras palavras, os critérios de seleção se aproximam mais dos seguintes pontos do que de “Brotli é sempre melhor”:

Se os ativos de texto forem grandes e houver muitos visitantes de primeira vez, considere servir tanto Brotli quanto gzip.
Se uma CDN já fornecer compressão adequada, não comprima novamente o mesmo conteúdo na aplicação.
Para um serviço dinâmico com CPU de servidor limitada, meça o equilíbrio entre nível de compressão e TTFB.
Se imagens e vídeos representarem uma grande parcela da página, a otimização de mídia pode vir antes da compressão de texto.

O que HTTP/3 muda?

HTTP/3 é um padrão que mantém a semântica de solicitação e resposta do HTTP enquanto substitui TCP por QUIC como base de transporte. QUIC opera sobre UDP, mas não é apenas uma forma de enviar HTTP sobre UDP. Ele oferece recursos como estabelecimento de conexão, criptografia, confiabilidade, controle de congestionamento e fluxos multiplexados, e o HTTP/3 usa esses recursos para entregar mensagens HTTP.datatracker.ietf.org developer.mozilla.org

HTTP/1.1 tinha limitações substanciais para lidar com solicitações em uma única conexão, portanto o uso de várias conexões TCP em paralelo tornou-se disseminado. HTTP/2 melhorou isso ao multiplexar várias solicitações em uma conexão TCP. Porém, como TCP garante a entrega em ordem dos dados recebidos, quando um pacote é perdido em uma conexão, os dados que chegam depois não podem ser entregues à aplicação na ordem correta até que essa perda seja recuperada. No HTTP/2, esse atraso no nível do TCP pode afetar vários fluxos HTTP.datatracker.ietf.org www.rfc-editor.org

O QUIC do HTTP/3 gerencia a entrega confiável e ordenada por fluxo. Como resultado, a perda de dados em um fluxo não exige necessariamente que fluxos não relacionados também parem. A RFC 9000 explica que, quando um pacote é perdido, somente os fluxos que contêm dados daquele pacote ficam bloqueados aguardando retransmissão, enquanto os demais podem continuar.www.rfc-editor.org

Quão precisa é a expressão “elimina o bloqueio head-of-line”?

O que HTTP/3 aborda principalmente é o bloqueio head-of-line na camada de transporte em toda a conexão. É incorreto interpretar isso como se toda espera desaparecesse.

Primeiro, a ordem ainda importa em um único fluxo. Se uma parte anterior for perdida no mesmo fluxo, como o corpo de um documento HTML ou uma imagem grande, os dados posteriores desse fluxo não poderão ser usados completamente até que a ordem necessária seja restaurada. Segundo, se dados de vários fluxos estiverem incluídos em um pacote QUIC, a perda desse pacote poderá atrasar vários desses fluxos simultaneamente.www.rfc-editor.org

Os benefícios do HTTP/3 podem, portanto, ser especialmente perceptíveis em redes onde há perda ou reordenação de pacotes. Por outro lado, ao visualizar uma página pequena em uma conexão cabeada, de baixa latência e baixa perda, a diferença em relação ao HTTP/2 pode ser pequena ou variar conforme as condições de medição. Isso ocorre porque HTTP/3 não é uma tecnologia que reduz bytes magicamente; é uma arquitetura que reduz o quanto a espera durante o transporte se propaga.datatracker.ietf.org www.rfc-editor.org

Como o QPACK do HTTP/3 difere de gzip?

HTTP/3 inclui um mecanismo de compressão de cabeçalhos chamado QPACK. Isso pode levar à ideia equivocada de que HTTP/3 inclui gzip, mas eles se aplicam a alvos diferentes. QPACK foi projetado para representar eficientemente campos de cabeçalho em solicitações e respostas HTTP, como Cookie, Content-Type e Cache-Control. gzip e Brotli são codificações de conteúdo que comprimem corpos de resposta, como HTML, CSS e JavaScript.datatracker.ietf.org www.rfc-editor.org

O HPACK do HTTP/2 depende da premissa de que o estado de compressão dos cabeçalhos é entregue em sequência, mas essa premissa é difícil de aplicar sem mudanças à arquitetura de fluxos independentes do QUIC. QPACK usa fluxos unidirecionais separados para gerenciar o estado da tabela dinâmica, permitindo que implementações equilibrem eficiência de compressão e risco de bloqueio de cabeçalhos.datatracker.ietf.org datatracker.ietf.org

Do ponto de vista do desempenho real da página, é útil considerar seus papéis da seguinte forma:

gzip e Brotli: reduzem o volume de transferência dos corpos de texto.
QPACK: melhora a eficiência da transmissão dos cabeçalhos de solicitação e resposta.
HTTP/3 e QUIC: reduzem o quanto atrasos de transporte causados por várias solicitações e condições de perda se propagam a outras solicitações.
Cache: impede que recursos já recebidos sejam transferidos novamente.
Otimização de imagens e código: reduz a quantidade de trabalho que precisa ser baixada e processada desde o início.

Não são opções concorrentes de escolha única; são abordagens complementares para gargalos diferentes.

Quais são os maiores gargalos na velocidade percebida de páginas web?

A velocidade de carregamento percebida pelos usuários não é um único número. O tempo até o servidor enviar o primeiro byte, o tempo até o conteúdo principal acima da dobra se tornar visível e o tempo até botões e campos responderem podem ser atrasados por causas diferentes. Em especial, LCP (Largest Contentful Paint) representa o momento em que a maior imagem, bloco de texto ou vídeo na viewport é renderizado, o que o torna útil para avaliar a experiência inicial da página.web.dev

LCP lento nem sempre significa que a causa é a compressão de rede. O web.dev recomenda separar TTFB, atraso no carregamento de recurso, tempo de carregamento de recurso e atraso na renderização do elemento ao diagnosticar LCP. Por exemplo, mesmo que uma imagem seja baixada rapidamente, um CSS grande pode bloquear a renderização, ou a thread principal pode estar ocupada demais com tarefas longas de JavaScript para exibir a imagem.web.dev

Quando a imagem acima da dobra é o gargalo

O maior elemento acima da dobra costuma ser uma imagem, como uma foto grande de produto em uma página de detalhes do produto, uma imagem de destaque na página inicial de notícias ou um banner em uma página de viagens. Nessa situação, habilitar gzip ajuda pouco nos próprios arquivos JPEG, WebP ou AVIF. Uma abordagem mais eficaz é servir imagens dimensionadas para suas dimensões de exibição, usar formatos modernos adequados e evitar atrasar a imagem de LCP com loading="lazy". Quando necessário, é possível oferecer uma dica de prioridade usando fetchpriority="high", mas dar alta prioridade indiscriminadamente a muitas imagens pode, em vez disso, gerar competição.web.dev web.dev

Quando CSS e JavaScript são o gargalo

O CSS tem características de bloqueio de renderização porque impede que o conteúdo apareça sem estilo. Porém, CSS excessivamente grande, CSS não necessário para a visualização inicial e scripts carregados de forma síncrona podem atrasar a exibição do conteúdo principal. Mesmo depois que a transferência termina, grandes bundles JavaScript usam a thread principal do navegador para análise, compilação e execução; portanto, reduzir apenas o tamanho do download com gzip pode não bastar.developer.chrome.com web.dev

Assim, o desempenho de JavaScript deve ser analisado separadamente da compressão. Possíveis ações incluem remover código não utilizado, carregar sob demanda funcionalidades desnecessárias na visualização inicial, dividir tarefas longas e, quando possível, usar renderização no servidor ou pré-renderização para que o HTML inicial exponha o conteúdo e os recursos principais para descoberta. Contudo, a renderização no servidor também pode aumentar o tempo de processamento no servidor e afetar o TTFB, portanto alterações arquiteturais devem ser avaliadas com medições.web.dev

Quando a resposta do servidor e o cache são o gargalo

Quando o TTFB é longo, o navegador tem dificuldade em descobrir recursos subsequentes antes de receber o HTML. Causas comuns incluem um servidor distante, processamento longo de banco de dados e personalização, redirecionamentos desnecessários e oportunidades de cache não aproveitadas. HTTP/3 pode melhorar parte da etapa de transferência nessa situação, mas não reduz diretamente o tempo que o servidor precisa para gerar a primeira resposta.web.dev

O cache é diferente de outras melhorias de desempenho. gzip envia os mesmos dados em uma forma menor, HTTP/3 altera as características da conexão usada para entregar dados, e o cache impede que dados sejam enviados novamente em visitas recorrentes qualificadas. Para um serviço com alta proporção de visitantes recorrentes, uma política de cache apropriada pode produzir uma diferença percebida maior do que mudar algoritmos de compressão. Contudo, estratégias de cache para respostas que mudam frequentemente ou variam por usuário, como HTML, precisam ser projetadas com mais cuidado.www.rfc-editor.org developer.chrome.com

Qual é a classificação prática das melhorias de desempenho por impacto percebido?

Não há uma classificação fixa aplicável a todos os sites. Os resultados variam conforme a composição da página, a proporção entre visitantes de primeira vez e recorrentes, as redes dos usuários, a localização dos servidores e a configuração existente. Ainda assim, para páginas típicas de conteúdo, comércio e serviços que mantêm gargalos importantes, a ordem a seguir é prática para investigação.

Descubra o que atrasa o conteúdo principal acima da dobra. Primeiro, examine o tamanho, o momento de descoberta e a prioridade da imagem de LCP; CSS que bloqueia a renderização; JavaScript síncrono; e renderização desnecessária no cliente.web.dev
Revise o tempo de resposta do servidor e o cache. Verifique TTFB, redirecionamentos, posicionamento da CDN, cache de ativos estáticos e atrasos no processamento de backend.web.dev www.rfc-editor.org
Verifique a compressão de texto para HTML, CSS, JavaScript e JSON. Se eles não estiverem comprimidos, aplicar gzip ou Brotli é alta prioridade. Se já estiverem devidamente comprimidos, ganhos adicionais na mesma área podem ser limitados.developer.mozilla.org developer.chrome.com
Reduza o volume total transferido e otimize a composição das solicitações. Organize imagens, scripts e recursos de terceiros grandes e adie solicitações até que sejam realmente necessárias. Grandes cargas úteis de rede estão associadas a longos tempos de carregamento.developer.chrome.com developer.chrome.com
Ofereça HTTP/3, mantenha uma alternativa em HTTP/2 e valide com tráfego real. Compare os resultados antes e depois, sobretudo em ambientes móveis, de alta latência e perda de pacotes, e em páginas com muitas solicitações simultâneas.datatracker.ietf.org www.rfc-editor.org

Essa classificação tem exceções importantes. Se uma aplicação tiver respostas de texto não comprimidas maiores que 1 MB, aplicar gzip ou Brotli na etapa 3 poderá ser a maior melhoria de curto prazo. Por outro lado, se uma imagem de destaque tiver vários MB e o texto já estiver comprimido com Brotli, a otimização de imagens terá prioridade. Se o servidor não conseguir gerar HTML por vários segundos, o trabalho em backend e cache virá antes de HTTP/3.developer.mozilla.org web.dev developer.chrome.com

Se você comparar apenas gzip e HTTP/3

Se a escolha for somente entre essas duas tecnologias, a decisão é relativamente direta.

Quando o texto não está comprimido: gzip ou Brotli geralmente vêm primeiro. Eles reduzem a quantidade de dados a transmitir, portanto é possível esperar benefícios em toda conexão compatível.
Quando a compressão já funciona corretamente: o valor relativo do HTTP/3 aumenta. No entanto, a melhoria real depende da qualidade da rede e da estrutura das solicitações.
Para páginas com muitas imagens e vídeos: nem gzip nem HTTP/3, isoladamente, provavelmente resolverão o problema maior. A otimização de mídia vem primeiro.
Para aplicações JavaScript grandes: gzip é apenas o ponto de partida. Também é necessário examinar os custos de execução após a transferência para alcançar uma melhoria percebida contínua.
Para serviços com muitas visitas recorrentes: as taxas de acerto de cache podem ser uma variável maior do que mudar métodos de compressão.

Portanto, nenhuma das conclusões — “gzip está sempre à frente de HTTP/3” ou “HTTP/3 é mais novo, então está sempre à frente” — é correta. Uma afirmação mais precisa é: a compressão de conteúdo é a prioridade básica para textos não comprimidos, enquanto HTTP/3 é uma otimização de base que pode trazer benefícios adicionais conforme as condições de transporte e os padrões de solicitação.

Quais restrições devem ser consideradas ao adotar HTTP/3?

Para oferecer HTTP/3, servidores, CDNs, balanceadores de carga, firewalls e ferramentas de observabilidade devem conseguir tratar adequadamente o tráfego QUIC e baseado em UDP. Como alguns clientes ou caminhos podem não conseguir usar HTTP/3, em geral é adequado fazer uma implantação gradual que também ofereça HTTP/2 ou HTTP/1.1. O padrão HTTP/3 é baseado em QUIC e define o processo pelo qual um cliente descobre um servidor HTTP/3 e então estabelece uma conexão QUIC.datatracker.ietf.org

Do ponto de vista operacional, é importante não julgar o sucesso apenas por uma troca de protocolo. Monitore conjuntamente a proporção de conexões HTTP/3, taxas de falha e repetição de tentativa, TTFB, LCP, taxas de erro e uso de CPU. Em particular, quando uma CDN ou proxy fica à frente da origem, o protocolo visível no servidor de origem pode ser diferente daquele realmente usado pelo navegador do usuário final; assim, a observação do lado do cliente também deve ser incluída.developer.chrome.com developer.chrome.com

Há considerações de segurança sobre compressão?

Sim. Mesmo com HTTPS, se entrada controlada por um atacante e valores secretos forem comprimidos juntos no mesmo contexto de compressão, um atacante poderá inferir o segredo ao observar diferenças no tamanho do texto cifrado. As especificações HTTP Semantics e HTTP/3 alertam contra situações em que dados sensíveis e dados controlados pelo atacante são comprimidos juntos e identificam desabilitar a compressão para dados sensíveis ou separar contextos de compressão como as mitigações mais confiáveis.www.rfc-editor.org www.rfc-editor.org

Isso não significa que toda resposta gzip seja perigosa. A questão principal é se existem ao mesmo tempo entrada de usuário refletida, segredos relacionados à autenticação e condições que permitem a um atacante fazer solicitações repetidamente e observar tamanhos de resposta. Fluxos sensíveis, como login, pagamento e recuperação de conta, não devem receber mecanicamente as mesmas políticas de compressão aplicadas a ativos estáticos gerais; eles devem ser revisados junto ao design de segurança.www.rfc-editor.org datatracker.ietf.org

O que devo medir no meu site?

É mais seguro validar melhorias de desempenho pela experiência de usuários reais do que por uma única pontuação de laboratório. Lighthouse é útil para identificar rapidamente possíveis problemas, mas não representa todos os usuários reais em redes, dispositivos, estados de cache e regiões diversos. Usar ferramentas de desenvolvimento junto com monitoramento de usuários reais facilita separar hipóteses de resultados.developer.chrome.com developer.chrome.com

Você pode revisar o desempenho na seguinte ordem:

Verifique o estado atual da transferência. No painel Network, revise Content-Encoding, o tamanho de transferência e o tamanho original para respostas importantes de HTML, CSS, JS e JSON.developer.chrome.com
Verifique o protocolo. Na coluna Protocol, confirme se as solicitações reais usam h3, h2 ou http/1.1.
Segmente as métricas principais de usuário. Compare TTFB, LCP e métricas de interação por primeira visita versus visita recorrente, dispositivos móveis versus desktop, região e tipo de rede.web.dev web.dev
Mude uma coisa por vez. Se você implantar simultaneamente a ativação de gzip, suporte a Brotli, substituições de imagens, divisão de JavaScript e ativação de HTTP/3, será difícil identificar qual mudança produziu efeito.
Registre também os efeitos colaterais. Monitore ainda CPU do servidor, taxas de erro, taxas de acerto de cache e taxas de falha ou fallback da conexão HTTP/3.

Por exemplo, se trocar um bundle JavaScript não comprimido por gzip reduzir o tamanho de transferência, mas quase não alterar o LCP, é provável que o próximo gargalo seja uma imagem grande, CSS ou execução de JavaScript, e não a compressão. Por outro lado, se a cauda longa do LCP melhorar para usuários de rede móvel após adotar HTTP/3, você poderá identificar benefícios em ambientes de alta perda e alta latência, além de observar as médias. Tais conclusões começam com gargalos medidos, não com o nome de uma tecnologia.web.dev www.rfc-editor.org

Resumo: trate gzip e HTTP/3 como papéis complementares, não como uma disputa de classificação

gzip e HTTP/3 são ambos úteis para o desempenho web, mas a base de comparação entre eles é diferente. gzip reduz bytes de transferência para respostas de texto, enquanto HTTP/3 pode reduzir o impacto da perda de rede sobre várias solicitações por meio de fluxos multiplexados baseados em QUIC. O QPACK do HTTP/3 é compressão de cabeçalhos; ele não substitui a compressão do corpo realizada por gzip e Brotli.www.rfc-editor.org datatracker.ietf.org datatracker.ietf.org

A prioridade mais prática é primeiro identificar o gargalo real entre LCP, TTFB, bloqueio de renderização, JavaScript, imagens e cache; implementar a compressão de texto como base se ela estiver ausente; e então validar HTTP/3 sob condições de usuários reais. Desempenho não é uma questão de adicionar uma única tecnologia mais recente — é uma questão de encurtar o caminho mais longo pelo qual o usuário precisa esperar.web.dev developer.chrome.com

Leitura adicional

Especificações de HTTP Semantics e codificação de conteúdowww.rfc-editor.org
Padrão HTTP/3datatracker.ietf.org
Padrão de compressão de cabeçalhos QPACKdatatracker.ietf.org
Especificação de transporte QUICwww.rfc-editor.org
Orientações de desempenho web e otimização de LCPweb.dev
Visão geral da compressão HTTPdeveloper.mozilla.org