Pular para o conteúdo

Entenda HTTP/2 no Apache desmistificado: o que significa e como usar

Por Equipe Técnica AviraHost · 15 min de leitura · Atualizado em · Apache, http2, cache-navegador, core-web-vitals, performance-web, AviraHost · 0

HTTP/2 no Apache é a configuração que permite ao servidor entregar múltiplos recursos de uma página com mais eficiência pela mesma conexão. Para usá-lo com foco em Core Web Vitals, ative o protocolo no VirtualHost HTTPS, configure cache de navegador e valide os cabeçalhos, lembrando que HTTP/2 sozinho não corrige LCP, INP ou CLS.

  1. Confirme que o site possui HTTPS com certificado TLS válido.
  2. Verifique o módulo HTTP/2 e o modelo de processamento do Apache.
  3. Ative os módulos necessários e anuncie os protocolos no VirtualHost TLS.
  4. Defina cache de navegador para CSS, JavaScript, fontes e imagens.
  5. Teste o protocolo negociado, os cabeçalhos e a configuração do Apache.
  6. Meça os Core Web Vitals e ajuste os recursos que ainda causam lentidão.

Pré-requisitos

A ativação do HTTP/2 no Apache começa por uma conexão HTTPS funcional, pois os navegadores atuais normalmente negociam o protocolo em sites públicos por TLS. Antes de alterar o servidor, confirme que o domínio abre sem alerta de certificado e que você consegue restaurar a configuração anterior caso o teste falhe.

  • Acesso administrativo ao servidor e permissão para reiniciar ou recarregar o Apache.
  • Apache instalado em uma distribuição atual, como Debian 13 ou superior.
  • VirtualHost HTTPS ativo na porta 443 e certificado TLS válido para seudominio.com.br.
  • Módulos HTTP/2, SSL, cabeçalhos e expiração disponíveis.
  • Aplicação compatível com o modelo de processamento utilizado pelo Apache.
  • Cópia dos arquivos do VirtualHost antes de qualquer modificação.

Se o site ainda responde somente por HTTP, conclua primeiro o HTTPS. O artigo Como redirecionar um site http para https? ajuda a organizar esse redirecionamento sem misturá-lo à negociação do HTTP/2.

O que HTTP/2 no Apache realmente significa

A multiplexação HTTP permite que diferentes requisições e respostas compartilhem uma conexão, reduzindo limitações comuns do fluxo sequencial do HTTP/1.1. Isso é útil em páginas com folhas de estilo, scripts, fontes e várias imagens, mas não reduz automaticamente o tamanho desses arquivos nem elimina processamento lento na aplicação.

  • HTTP/1.1: pode exigir várias conexões e sofre mais com bloqueios entre requisições na mesma conexão.
  • HTTP/2: transporta múltiplos fluxos pela conexão negociada e comprime os cabeçalhos do protocolo.
  • Cache de navegador: evita transferências repetidas de arquivos estáticos que ainda permanecem válidos.
  • Core Web Vitals: dependem também da resposta da aplicação, do recurso de LCP, da estabilidade visual e do trabalho executado no navegador.

Em um caso real, HTTP/2 é apropriado quando uma página precisa baixar muitos recursos estáticos pelo mesmo domínio. O cache complementa esse trabalho nas visitas seguintes: em vez de solicitar novamente cada arquivo, o navegador pode reutilizar a cópia local de acordo com Cache-Control ou Expires.

Não trate o protocolo como substituto para otimização de imagens, redução de JavaScript, fontes eficientes ou investigação de TTFB. Também não aplique cache prolongado a HTML dinâmico, áreas autenticadas ou respostas personalizadas sem entender o comportamento da aplicação.

Verificar módulos e compatibilidade antes da ativação

O módulo mod_http2 precisa estar carregado, mas a verificação deve incluir o MPM utilizado pelo Apache. O MPM prefork não é a escolha adequada para HTTP/2; quando ele existe por dependência de PHP incorporado ao Apache, a migração para event normalmente exige que o PHP seja atendido por PHP-FPM.

Execute as verificações sem alterar o serviço:

apache2ctl -M | grep -E 'http2|ssl|headers|expires|mpm_'
apache2ctl -S
Output esperado:
 http2_module (shared)
 ssl_module (shared)
 headers_module (shared)
 expires_module (shared)
 mpm_event_module (shared)
VirtualHost configuration:
*:443 seudominio.com.br

Os nomes e a organização da saída podem variar, mas você deve localizar o VirtualHost da porta 443 e apenas um MPM carregado. Se http2_module não aparecer, ele ainda precisa ser habilitado. Se aparecer mpm_prefork_module, não troque o MPM sem verificar como o PHP e os demais módulos são executados.

Atenção: mudar o MPM em um servidor de produção pode interromper aplicações dependentes de módulos incompatíveis. Faça backup, valide a integração com PHP-FPM e mantenha uma sessão administrativa aberta para reverter a alteração.

No Debian 13 ou superior, habilite os módulos necessários:

sudo a2enmod http2 ssl headers expires
sudo apache2ctl configtest
Output esperado:
Syntax OK

Se o teste não retornar Syntax OK, não recarregue o serviço. Leia a mensagem, identifique o arquivo e a linha indicados e corrija a diretiva antes de prosseguir.

Configurar HTTP/2 no VirtualHost HTTPS

A negociação de protocolo TLS ocorre no VirtualHost que atende a porta 443. A diretiva Protocols h2 http/1.1 anuncia HTTP/2 e mantém HTTP/1.1 como alternativa para clientes que não negociarem o protocolo mais novo.

  1. Localize o arquivo do VirtualHost indicado por apache2ctl -S.
  2. Crie uma cópia de segurança do arquivo.
  3. Inclua a diretiva de protocolos dentro do VirtualHost HTTPS.
  4. Teste a sintaxe antes de recarregar o Apache.

Atenção: substitua o caminho abaixo pelo arquivo realmente associado a seudominio.com.br. Não sobrescreva certificados ou diretivas existentes.

sudo cp /etc/apache2/sites-available/seudominio.com.br.conf /etc/apache2/sites-available/seudominio.com.br.conf.bak
Output esperado:
Nenhuma saída indica que a cópia foi criada sem erro.

O trecho essencial do VirtualHost deve seguir esta lógica:

<VirtualHost *:443>
    ServerName seudominio.com.br
    ServerAlias www.seudominio.com.br

    Protocols h2 http/1.1

    SSLEngine on
    SSLCertificateFile "/caminho/do/certificado.pem"
    SSLCertificateKeyFile "/caminho/da/chave-privada.pem"

    DocumentRoot "/var/www/seudominio.com.br/public"
</VirtualHost>
Output esperado:
O editor salva o arquivo sem mensagens de erro.

Valide e recarregue apenas depois de confirmar a sintaxe:

sudo apache2ctl configtest
sudo systemctl reload apache2
sudo systemctl is-active apache2
Output esperado:
Syntax OK
active

Um reload aplica a configuração sem a interrupção completa causada por uma parada seguida de inicialização. Caso o serviço não permaneça ativo, restaure o arquivo de backup e consulte os registros do Apache antes de tentar novamente.

Ativar cache de navegador para arquivos estáticos

O cache de navegador no Apache reduz transferências repetidas de recursos que mudam com pouca frequência. A política deve diferenciar arquivos estáticos do HTML dinâmico e precisa ser acompanhada de versionamento de URL, como app.2026.css ou app.css?v=2026-01, para que uma atualização não permaneça escondida por uma cópia antiga.

Adicione as diretivas ao VirtualHost quando você controla o servidor. Em hospedagens que permitem apenas arquivos de configuração por diretório, confirme quais módulos e diretivas estão autorizados antes de adaptar o trecho.

<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType text/css "access plus 1 year"
    ExpiresByType application/javascript "access plus 1 year"
    ExpiresByType image/jpeg "access plus 1 year"
    ExpiresByType image/png "access plus 1 year"
    ExpiresByType image/webp "access plus 1 year"
    ExpiresByType image/svg+xml "access plus 1 year"
    ExpiresByType font/woff2 "access plus 1 year"
</IfModule>

<IfModule mod_headers.c>
    <FilesMatch "\.(css|js|jpg|jpeg|png|webp|svg|woff2)$">
        Header set Cache-Control "public, max-age=31536000, immutable"
    </FilesMatch>
</IfModule>
Output esperado:
O editor salva as diretivas sem erro.

A política de um ano é apropriada somente para arquivos versionados. Se o projeto reutiliza sempre o mesmo nome para CSS ou JavaScript, aplique um período menor ou implemente versionamento antes. Não inclua HTML, respostas de login ou conteúdo privado nesse bloco.

Teste novamente e recarregue:

sudo apache2ctl configtest
sudo systemctl reload apache2
Output esperado:
Syntax OK

Testar HTTP/2, cache e impacto nos Core Web Vitals

A validação de cabeçalhos HTTP confirma o que foi entregue ao cliente, evitando concluir que uma configuração está ativa apenas porque o arquivo foi salvo. Faça testes em uma URL HTTPS pública e em um arquivo estático que realmente exista.

Primeiro, confira o protocolo negociado:

curl --http2 -I https://seudominio.com.br/
Output esperado:
HTTP/2 200
content-type: text/html

Redirecionamentos podem mostrar outro código válido antes da resposta final. Para acompanhá-los, use:

curl --http2 -I -L https://seudominio.com.br/
Output esperado:
HTTP/2 301
location: https://www.seudominio.com.br/
HTTP/2 200

Depois, consulte um recurso estático versionado:

curl --http2 -I https://seudominio.com.br/assets/app.2026.css
Output esperado:
HTTP/2 200
cache-control: public, max-age=31536000, immutable
expires: data futura calculada pelo servidor
content-type: text/css

Por fim, avalie o site antes e depois em condições comparáveis. HTTP/2 e cache podem reduzir custos de transferência, mas um LCP lento ainda pode vir de imagem grande, resposta inicial demorada ou recurso bloqueante. INP exige atenção ao JavaScript e às tarefas executadas no navegador, enquanto CLS depende da reserva correta de espaço para imagens, fontes e componentes inseridos posteriormente.

HTTP/2 no Apache melhora quais etapas do carregamento?

Ele atua principalmente na transferência dos recursos entre cliente e servidor. O benefício tende a ser mais visível em páginas com várias solicitações pelo mesmo host, enquanto o cache reduz solicitações nas visitas subsequentes. O processamento do PHP, as consultas ao banco e a renderização no navegador continuam exigindo diagnóstico próprio.

Problemas comuns e como resolver

O diagnóstico do Apache HTTP/2 deve começar pela sintaxe, pelos módulos carregados, pelo VirtualHost selecionado e pelos registros do serviço. Evite trocar várias diretivas ao mesmo tempo, pois isso dificulta identificar a causa real.

Sintoma: o teste continua mostrando HTTP/1.1

Causa: o módulo HTTP/2 pode não estar carregado, a diretiva Protocols pode estar no VirtualHost errado ou a conexão HTTPS pode não estar negociando corretamente. Solução: rode apache2ctl -M e apache2ctl -S, confirme o VirtualHost da porta 443, valide o certificado e repita o teste diretamente no domínio correto.

Sintoma: o Apache falha após recarregar

Causa: existe erro de sintaxe, diretiva fora do contexto permitido ou incompatibilidade introduzida na configuração. Solução: execute apache2ctl configtest, examine a linha indicada e consulte os registros com o comando abaixo.

sudo journalctl -u apache2 --since "10 minutes ago"
Output esperado:
Registros recentes do serviço, incluindo o arquivo e a causa da falha quando disponível.

Se o serviço não inicializar, use a cópia de segurança. Para uma análise mais ampla, consulte Como solucionar problemas de inicialização de serviços no VPS Linux: Guia Completo.

Sintoma: Cache-Control não aparece no arquivo estático

Causa: o módulo de cabeçalhos pode estar desativado, a expressão pode não corresponder à extensão ou outro componente pode substituir o cabeçalho. Solução: confirme headers_module, teste a URL exata do arquivo e procure diretivas concorrentes no VirtualHost e na aplicação.

Sintoma: usuários continuam vendo CSS ou JavaScript antigo

Causa: um período longo foi aplicado a arquivos sem versionamento de URL. Solução: publique o arquivo com novo nome ou parâmetro de versão e atualize o HTML para apontar para a nova URL. Reduzir o prazo ajuda nas próximas respostas, mas não remove imediatamente uma cópia já armazenada conforme a política anterior.

Perguntas frequentes sobre HTTP/2 no Apache

Como saber se o HTTP/2 está ativo no Apache?

Verifique a resposta HTTPS do site com uma ferramenta capaz de exibir a versão do protocolo negociado. O resultado deve indicar HTTP/2; se mostrar apenas HTTP/1.1, revise o módulo HTTP/2, o VirtualHost TLS e a configuração de protocolos do Apache.

O HTTP/2 melhora sozinho os Core Web Vitals?

O HTTP/2 pode tornar a transferência de recursos mais eficiente, mas não corrige sozinho LCP, INP ou CLS. Ele deve ser combinado com cache de navegador, otimização de imagens, redução de recursos bloqueantes e ajustes na aplicação.

Como configurar cache de navegador no Apache?

Habilite os módulos de cabeçalhos e expiração e defina políticas de cache por tipo de arquivo no VirtualHost ou no arquivo permitido pela hospedagem. Depois, confirme nos cabeçalhos de resposta a presença e os valores de Cache-Control ou Expires.

É necessário usar HTTPS para ativar HTTP/2 no Apache?

Na prática dos navegadores atuais, o HTTP/2 para sites públicos deve ser disponibilizado por uma conexão HTTPS com certificado TLS válido. Além do módulo HTTP/2, o VirtualHost da porta 443 precisa anunciar o protocolo corretamente.

Cache de navegador pode impedir a atualização de arquivos do site?

Sim, períodos longos podem manter versões antigas de CSS, JavaScript e imagens no navegador. Use versionamento nos nomes ou URLs dos arquivos estáticos antes de aplicar uma política de cache prolongada.

Conclusão

A otimização de performance do Apache exige validar cada camada em vez de confiar apenas na presença de uma diretiva. HTTP/2 melhora o transporte, enquanto o cache de navegador reduz downloads repetidos; os Core Web Vitals ainda dependem do conteúdo e da aplicação.

  • Confirme HTTPS, MPM, módulos e VirtualHost antes de anunciar h2.
  • Aplique cache longo somente a arquivos estáticos versionados e confira os cabeçalhos.
  • Compare medições e investigue separadamente LCP, INP, CLS e tempo de resposta.

Leia também

Precisa de ajuda com HTTP/2 e performance do Apache?

Uma infraestrutura com acesso administrativo permite ajustar o Apache, validar o cache e acompanhar o comportamento da aplicação conforme a necessidade do projeto.

Conheça as opções de Servidor VPS


Esta resposta foi útil?