Como reduzir o TTFB abaixo de 200ms com Varnish

15 min de leitura  ·  Guia técnico

Para reduzir o TTFB abaixo de 200ms com Varnish, instale o cache HTTP reverso na frente do Nginx ou Apache, configure regras VCL para páginas públicas e valide os resultados com curl antes e depois da ativação. O Varnish entrega respostas já armazenadas sem acionar PHP, CMS ou banco de dados a cada requisição.

1. Meça o TTFB atual com curl antes de alterar a arquitetura.
2. Instale o Varnish e coloque o backend web em uma porta interna, como 8080.
3. Configure o Varnish para escutar HTTP e encaminhar apenas misses ao Nginx ou Apache.
4. Crie regras de cache, bypass e expiração para páginas públicas, cookies e áreas autenticadas.
5. Teste os cabeçalhos, confirme HIT ou MISS e compare o TTFB depois da ativação.

Pré-requisitos para reduzir o TTFB abaixo de 200ms com Varnish

Cache HTTP reverso funciona melhor quando o site tem páginas públicas que podem ser reutilizadas por vários visitantes, como home, categorias, posts, páginas institucionais e landing pages. Antes de aplicar o Varnish, confirme se a lentidão está no processamento do backend e não em DNS, rede, TLS ou falta de recursos básicos no servidor.

• Acesso SSH com usuário administrativo ou root no servidor.
• Servidor Linux com Debian 12, Ubuntu 24.04 LTS, AlmaLinux 9 ou Rocky Linux 9.
• Nginx ou Apache já respondendo pelo site em HTTP.
• Conhecimento do domínio, porta atual do backend e caminho dos arquivos de configuração.
• Ferramentas curl, systemctl e editor de texto no terminal.
• Planejamento para HTTPS: o Varnish trabalha com HTTP; a terminação TLS deve ficar em um proxy como Nginx, Apache ou outro componente na frente.

Se você ainda está estruturando o ambiente base, veja também Configurando um Servidor Linux para Hospedagem de Sites. Para ajustes gerais de recursos e serviços, Dicas de Otimização de Servidores Linux complementa bem este procedimento.

Medir TTFB antes de ativar o Varnish

Tempo até o primeiro byte deve ser medido antes e depois, porque otimizar sem linha de base cria falsa sensação de melhoria. Ao rodar este comando, você verá quanto tempo o servidor leva para começar a responder, separado do tempo total da requisição. Use uma página pública representativa e repita o teste algumas vezes para observar variações naturais.

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://seudominio.com.br/

Output esperado:
TTFB: 0.350000s
Total: 0.620000s

O valor acima é apenas um exemplo de leitura do curl. Se o TTFB estiver alto em páginas dinâmicas e cair em arquivos estáticos, o gargalo provavelmente envolve processamento da aplicação, PHP, CMS ou banco de dados. Se tudo estiver lento, inclusive arquivos simples, investigue rede, DNS, TLS, disco e carga do servidor antes de atribuir o problema ao backend da aplicação.

Também é útil salvar os cabeçalhos atuais para comparar depois. Eles mostram servidor, cache existente, cookies e redirecionamentos que podem impedir cache.

curl -I https://seudominio.com.br/

Output esperado:
HTTP/2 200
server: nginx
content-type: text/html

Se a resposta for 301 ou 302, teste a URL final. Se houver muitos cookies em páginas públicas, revise a aplicação, pois cookies podem fazer o Varnish ignorar cache dependendo da regra definida.

Instalar Varnish e preparar o backend web

Varnish na frente do Nginx ou Apache exige uma pequena mudança de portas: o Varnish recebe a requisição HTTP pública e encaminha para o backend em uma porta interna, normalmente 8080. Em HTTPS, o desenho mais comum é manter um proxy TLS escutando 443, enviar HTTP para o Varnish e deixar o backend real em outra porta.

Atenção: alterar portas de Nginx ou Apache pode tirar o site do ar se você apontar o Varnish para a porta errada. Faça backup dos arquivos de configuração antes de editar e mantenha uma sessão SSH aberta para reversão.

sudo apt update
sudo apt install varnish curl -y

Output esperado:
varnish instalado
curl instalado
serviços processados sem erro crítico

Agora ajuste o servidor web de backend para escutar internamente. No Nginx, por exemplo, edite o bloco do site e troque a porta pública HTTP por 8080.

sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/default.bak
sudo sed -i 's/listen 80 default_server;/listen 127.0.0.1:8080 default_server;/' /etc/nginx/sites-available/default
sudo nginx -t

Output esperado:
nginx: the configuration file syntax is ok
nginx: configuration file test is successful

Reinicie o backend somente depois do teste de sintaxe. Ao rodar o comando abaixo, você deve ver o Nginx ativo e sem falhas de configuração.

sudo systemctl reload nginx
sudo systemctl status nginx --no-pager

Output esperado:
Active: active (running)

Se você usa Apache, a lógica é a mesma: mover o VirtualHost HTTP para uma porta interna e garantir que o Varnish encaminhe para ela. Não misture várias alterações de uma vez; primeiro faça o backend responder localmente.

curl -I http://127.0.0.1:8080/

Output esperado:
HTTP/1.1 200 OK
Server: nginx

Configurar VCL para cache de páginas públicas

VCL do Varnish define o que entra em cache, o que deve ser ignorado e por quanto tempo a resposta pode ser reutilizada. A configuração abaixo é conservadora: faz bypass para métodos diferentes de GET e HEAD, evita cache em áreas comuns de login e preserva segurança em páginas com sessão.

sudo cp /etc/varnish/default.vcl /etc/varnish/default.vcl.bak
sudo nano /etc/varnish/default.vcl

Output esperado:
arquivo default.vcl aberto para edição

Use um modelo como este, ajustando domínio, backend e caminhos conforme a aplicação. Ele não substitui análise do CMS, mas oferece uma base segura para testar cache de página em conteúdo público.

vcl 4.1;

backend default {
    .host = "127.0.0.1";
    .port = "8080";
}

sub vcl_recv {
    if (req.method != "GET" && req.method != "HEAD") {
        return (pass);
    }

    if (req.url ~ "^/(wp-admin|admin|login|minha-conta|checkout|cart)") {
        return (pass);
    }

    if (req.http.Authorization) {
        return (pass);
    }

    if (req.http.Cookie ~ "wordpress_logged_in|PHPSESSID|session|customer") {
        return (pass);
    }

    unset req.http.Cookie;
    return (hash);
}

sub vcl_backend_response {
    if (beresp.status == 200) {
        set beresp.ttl = 5m;
        set beresp.grace = 1m;
    }

    if (beresp.http.Set-Cookie) {
        return (pass);
    }

    return (deliver);
}

sub vcl_deliver {
    if (obj.hits > 0) {
        set resp.http.X-Cache = "HIT";
    } else {
        set resp.http.X-Cache = "MISS";
    }
}

Depois de salvar, valide a sintaxe. Ao rodar este comando, você verá erro de linha se houver problema no VCL.

sudo varnishd -C -f /etc/varnish/default.vcl

Output esperado:
configuração compilada sem mensagem de erro fatal

Se o site usa WordPress, loja virtual, painel de cliente ou qualquer página personalizada por usuário, não force cache sem mapear cookies e rotas sensíveis. Cache incorreto pode entregar conteúdo de uma sessão para outro visitante. Em sites com redirecionamento HTTP para HTTPS, revise também Como redirecionar um site http para https? para evitar loops entre proxy, Varnish e backend.

Ativar o Varnish TTFB na porta pública e testar HIT

Cache de página com Varnish só reduz TTFB quando a requisição realmente passa por ele e recebe HIT. Em instalações comuns, o serviço vem escutando em uma porta própria, como 6081. Para produção em HTTP, ajuste o serviço para escutar 80 ou coloque um proxy na frente apontando para o Varnish.

Atenção: mudar o Varnish para a porta 80 conflita com qualquer serviço que já esteja nessa porta. Confirme que Nginx ou Apache foram movidos para 8080 antes de prosseguir.

sudo systemctl edit varnish

Output esperado:
editor aberto para override do serviço varnish

No override, defina a porta desejada. O formato pode variar conforme a distribuição, então mantenha a linha compatível com o arquivo de serviço instalado no seu sistema. A ideia é iniciar o Varnish escutando em 0.0.0.0:80 e usando o VCL padrão.

[Service]
ExecStart=
ExecStart=/usr/sbin/varnishd -j unix,user=vcache -F -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -s malloc,256m

Output esperado:
override salvo

Recarregue o systemd e reinicie o Varnish. Ao consultar o status, procure o serviço ativo.

sudo systemctl daemon-reload
sudo systemctl restart varnish
sudo systemctl status varnish --no-pager

Output esperado:
Active: active (running)

Agora faça duas requisições consecutivas. A primeira tende a ser MISS porque o cache ainda será preenchido; a segunda deve indicar HIT se a URL for cacheável.

curl -I http://seudominio.com.br/
curl -I http://seudominio.com.br/

Output esperado:
HTTP/1.1 200 OK
X-Cache: MISS

HTTP/1.1 200 OK
X-Cache: HIT

Depois meça novamente o TTFB com Varnish ativo. A meta abaixo de 200ms é uma referência operacional comum para resposta rápida, mas não deve ser tratada como garantia universal: distância do usuário, TLS, rede, backend, tamanho da resposta e regras de cache influenciam o resultado.

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" http://seudominio.com.br/

Output esperado:
TTFB: 0.080000s
Total: 0.120000s

Ajustar bypass, expiração e invalidação de cache

Regras de bypass no Varnish são a diferença entre um cache rápido e um cache perigoso. Páginas públicas podem ser armazenadas; áreas autenticadas, carrinhos, checkout, painel administrativo, APIs sensíveis e respostas com Set-Cookie geralmente devem passar direto ao backend.

Uma prática segura é começar com TTL curto, como alguns minutos, validar comportamento e aumentar gradualmente em páginas estáveis. Ao publicar conteúdo novo, a expiração natural pode ser suficiente para blogs pequenos, mas ambientes com atualização frequente precisam de uma estratégia de purge ou ban controlada.

sudo varnishadm ban "req.url ~ /"

Output esperado:
200
Ban added

Atenção: o comando acima invalida o cache de forma ampla. Use em manutenção, após publicação crítica ou durante testes. Em produção, prefira regras mais específicas para não provocar pico desnecessário no backend.

sudo varnishlog -g request -q 'ReqUrl eq "/"'

Output esperado:
requisições exibidas com detalhes de backend, cache e entrega

Ao analisar logs, procure requisições com cookies inesperados, rotas que nunca viram HIT e páginas com Set-Cookie indevido. Muitas aplicações enviam cookies em todas as páginas mesmo quando o visitante é anônimo; nesse caso, a regra de remover cookies em páginas públicas pode ser necessária, desde que você tenha certeza de que a página não depende deles.

Problemas comuns e como resolver

Sintoma: o site fica fora do ar depois de ativar o Varnish

Causa: porta pública em conflito, backend não escutando em 8080 ou Varnish apontando para host e porta incorretos.

Solução: verifique portas com ss, teste o backend local com curl e revise o bloco backend no default.vcl. Reinicie primeiro o servidor web, depois o Varnish, e confirme o status dos dois serviços.

sudo ss -ltnp
curl -I http://127.0.0.1:8080/
sudo systemctl status varnish nginx --no-pager

Output esperado:
porta 80 usada pelo varnish
porta 8080 usada pelo backend
serviços active (running)

Sintoma: X-Cache sempre mostra MISS

Causa: cookies, cabeçalho Authorization, Set-Cookie no backend, rotas em bypass ou métodos não cacheáveis impedem o armazenamento.

Solução: revise cabeçalhos com curl -I, verifique varnishlog e ajuste regras apenas para páginas públicas. Não remova cookies de áreas autenticadas.

curl -I http://seudominio.com.br/
sudo varnishlog -g request

Output esperado:
cabeçalhos HTTP visíveis
eventos de pass, miss ou hit registrados

Sintoma: HTTPS entra em loop de redirecionamento

Causa: o proxy TLS, o Varnish e o backend não concordam sobre o protocolo original da requisição, causando redirecionamentos repetidos entre HTTP e HTTPS.

Solução: mantenha a terminação TLS em um ponto definido, encaminhe cabeçalhos como X-Forwarded-Proto e configure o backend para confiar nesse fluxo. Teste primeiro em uma URL simples antes de liberar todo o domínio.

curl -I https://seudominio.com.br/

Output esperado:
HTTP/2 200
sem sequência repetida de 301 ou 302

Perguntas frequentes sobre reduzir o TTFB abaixo de 200ms com Varnish

Varnish realmente reduz o TTFB do site?

O Varnish pode reduzir o TTFB quando a lentidão vem de processamento repetido no backend, como PHP, CMS ou consultas de banco executadas a cada acesso. Ele atua como cache HTTP na frente do servidor web e entrega respostas já armazenadas, mas o resultado depende da configuração, das regras de cache e do tipo de conteúdo.

Posso usar Varnish com Nginx ou Apache?

Sim, o Varnish pode ficar na frente do Nginx ou do Apache, recebendo as requisições HTTP e encaminhando apenas o que não estiver em cache para o backend. Em ambientes com HTTPS, normalmente ele trabalha junto de um proxy ou servidor web responsável pela terminação TLS.

Como medir o TTFB depois de configurar o Varnish?

A forma mais direta é usar curl para verificar o tempo até o primeiro byte e comparar antes e depois da configuração. Também é importante confirmar se a resposta veio do cache, analisando cabeçalhos HTTP e logs do Varnish.

Quando não devo usar Varnish para reduzir TTFB?

Evite usar Varnish como solução principal quando o problema é DNS, latência de rede, certificado TLS mal configurado ou servidor sem recursos básicos. Ele também exige cuidado em áreas autenticadas, carrinhos de compra e páginas personalizadas por usuário, pois cache incorreto pode expor conteúdo indevido.

Varnish substitui Redis, OPcache ou cache de página do WordPress?

Não necessariamente. O Varnish atua como cache HTTP na borda do servidor, enquanto Redis, OPcache e caches do WordPress trabalham em camadas diferentes da aplicação. Em muitos cenários eles podem coexistir, desde que as regras de expiração e bypass estejam bem definidas.

Conclusão

Otimização de TTFB com Varnish deve ser tratada como ajuste de arquitetura, não como comando único. O ganho aparece quando páginas públicas deixam de acionar o backend a cada acesso e passam a ser entregues diretamente do cache, com regras claras para conteúdo dinâmico e autenticado.

• Meça antes e depois com curl, sempre validando HIT ou MISS nos cabeçalhos.
• Mantenha backend, Varnish e proxy TLS com papéis bem definidos para evitar loops e indisponibilidade.
• Comece com TTL curto, monitore logs e só amplie cache quando tiver certeza de que a página é pública e segura.

Leia também

• Passo a passo para configurar Nginx com PHP-FPM no VPS Linux: Guia Completo
• Otimizar Nginx + PHP-FPM no mesmo servidor: conflitos
• LAMP vs LEMP: qual stack roda melhor em VPS com 1 GB RAM

Precisa de ajuda com Varnish e TTFB?

Se você quer hospedar aplicações com mais controle de cache, portas, proxy reverso e ajustes de performance, um VPS bem configurado facilita a implementação do Varnish. A equipe da AviraHost pode ajudar você a escolher uma base adequada para esse tipo de arquitetura.

Otimize seu TTFB com um VPS AviraHost