🎉 USE O CUPOM FIM.DE.SEMANA.FULL | com 15% OFF

TTL (Time-to-Live)

TTL (Time-to-Live) é o tempo de vida de dados em DNS, cache e CDN. Veja como funciona e como configurar TTL para WordPress.

Intermediário 7 min de leitura Também conhecido como: tempo de vida, time to live

TTL (Time-to-Live) é um valor em segundos que define por quanto tempo um dado pode permanecer em cache antes de ser considerado expirado. O conceito aparece em três contextos diferentes na infraestrutura web: DNS, cache HTTP e CDN. Em cada caso, o TTL controla a janela em que sistemas intermediários podem servir uma cópia armazenada antes de buscar dados frescos da origem.

O que é TTL (Time-to-Live)?

TTL é um número expresso em segundos. Quando um servidor entrega uma resposta marcada com TTL de 3600, está dizendo ao receptor: “você pode usar essa resposta por uma hora antes de me consultar de novo”. Depois desse tempo, o cache local é considerado vencido e o sistema precisa buscar dados frescos.

O TTL é o que permite a internet escalar. Sem cache controlado por TTL, cada requisição precisaria voltar ao servidor de origem todas as vezes — gastando banda, processamento e tempo. Com TTL, sistemas intermediários servem cópias locais durante a janela definida, reduzindo carga e acelerando entrega.

O conceito original vem de redes de computadores: pacotes IP têm TTL para evitar loops infinitos. Cada roteador que processa o pacote reduz o TTL em 1; se chegar a zero antes do destino, o pacote é descartado. A ideia foi adaptada para DNS, cache HTTP e CDNs como controle de validade temporal.

O detalhe importante: TTL alto significa cache mais agressivo (entrega rápida, propagação lenta de mudanças). TTL baixo significa cache curto (entrega mais lenta em pico, mudanças propagam rápido). Toda decisão sobre TTL é um trade-off entre performance e flexibilidade.

Onde o TTL aparece?

O mesmo conceito aparece em quatro contextos da infraestrutura web. Cada um controla um tipo de cache diferente.

TTL em DNS

Em DNS, o TTL diz aos servidores resolvers (Google DNS, Cloudflare DNS, ISPs) por quanto tempo guardar a resposta de uma consulta. Cada registro DNS — A, CNAME, MX — tem seu próprio TTL definido na zona. Valores típicos vão de 300 segundos (5 minutos) a 86400 segundos (24 horas).

TTL em cache de navegador

O navegador armazena recursos como CSS, JavaScript e imagens em cache local. O TTL é controlado pelos headers HTTP Cache-Control e Expires, enviados pelo servidor. Quando o usuário volta ao site dentro da janela de TTL, o navegador serve o arquivo do disco local em vez de baixar de novo.

TTL em CDN

CDNs como Cloudflare, Bunny e KeyCDN armazenam cópias dos arquivos do site em servidores espalhados pelo mundo. O TTL define por quanto tempo cada nó da CDN pode servir a cópia antes de buscar atualização. CDNs modernas separam TTL do edge (servidor da CDN) do TTL do navegador, permitindo controle granular.

TTL em pacotes de rede

O TTL original vem do protocolo IP. Cada pacote tem um campo TTL que começa tipicamente em 64 ou 128 e é decrementado a cada roteador que processa o pacote. Se chegar a zero, o pacote é descartado. É um mecanismo anti-loop, não um cache. Mas é a origem do conceito que depois virou padrão em DNS e HTTP.

Qual o TTL ideal para DNS?

Não existe valor universal — depende do que o registro faz e da frequência esperada de mudanças. Para registros estáveis (NS, MX, SOA), TTL alto (24 a 48 horas) reduz consultas e dá robustez. Para registros que podem mudar (A de servidor de site), TTL médio (1 a 6 horas) equilibra performance e flexibilidade.

O padrão moderno é TTL de 3600 segundos (1 hora) para registros A e CNAME. É curto o suficiente para que mudanças propaguem em algumas horas, mas longo o suficiente para que o cache absorva picos de tráfego sem sobrecarregar o servidor autoritativo.

Sites com infraestrutura crítica (e-commerces, SaaS) costumam usar TTL ainda mais baixo (300 a 600 segundos) para conseguir failover rápido em caso de problema. Sites institucionais estáveis podem usar TTL de 86400 sem prejuízo — mudanças são raras.

Cloudflare e outros provedores modernos com infraestrutura anycast tornam o TTL menos relevante para performance porque a resposta DNS chega muito rápido de qualquer servidor da rede. Mas o TTL ainda controla a janela de DNS propagation em mudanças.

Como configurar TTL para WordPress

O TTL de DNS é configurado no painel do registrador (Registro.br, GoDaddy, Cloudflare). Cada registro tem um campo TTL editável, em segundos. Para sites WordPress estáveis, configure 3600 (1 hora) como padrão. Para registros NS, deixe o padrão do provedor (geralmente 24 horas).

O TTL do cache de navegador é configurado nos headers HTTP enviados pelo servidor. Para WordPress, isso é feito via .htaccess no Apache ou no bloco location no Nginx. Plugins como WP Rocket e LiteSpeed Cache configuram automaticamente Cache-Control: max-age=2592000 (30 dias) para CSS, JS e imagens estáticas.

O TTL na CDN é configurado no painel da Cloudflare ou equivalente. Tipicamente: 1 ano para arquivos com fingerprint no nome (style.abc123.css), 1 hora para HTML, 1 dia para arquivos sem fingerprint. Esse layout garante que mudanças no conteúdo refletem rápido enquanto recursos estáticos ficam cacheados longamente.

Para o cache WordPress interno, o TTL é controlado pelo plugin de cache. WP Rocket usa 10 horas como padrão. LiteSpeed Cache varia entre 1 hora (admin) e 1 semana (públicas estáticas). Combine com cache no nível de CDN para cobertura completa.

Quando reduzir o TTL antes de migrar

Antes de qualquer migração de servidor, troca de IP ou mudança em registros DNS críticos, reduza o TTL com 24 a 72 horas de antecedência. Configure 300 segundos (5 minutos) nos registros que vão mudar.

O motivo é simples: durante esse período de antecedência, todos os servidores DNS intermediários vão consultar a zona a cada 5 minutos para atualizar o cache. Quando você fizer a mudança real, a propagação completa acontece em 5-10 minutos em vez de horas.

Sem essa redução prévia, alguns servidores podem servir cache antigo por até o valor do TTL anterior. Se estava em 86400 (24 horas), você pode ter usuários acessando o IP antigo por até um dia depois da mudança. Isso é especialmente crítico para troca de hospedagem ou IP de servidor de e-mail.

Após a propagação completa da mudança, volte o TTL para o valor padrão (3600 ou 7200 segundos). Não deixe TTL muito baixo permanentemente — multiplica consultas DNS, aumenta carga nos servidores autoritativos e pode até gerar cobrança extra em alguns provedores.

Otimize cache e DNS do seu WordPress com a FULL. Conheça os planos PRO.

Perguntas frequentes

Qual o TTL padrão de DNS? Não existe TTL universal. O padrão histórico era 86400 segundos (24 horas), mas hoje a maioria dos provedores modernos usa 3600 (1 hora) ou 14400 (4 horas). Cloudflare usa Auto, que ajusta dinamicamente.

Como reduzir o TTL antes de uma migração? Acesse o painel do registrador ou provedor de DNS, edite cada registro que vai mudar e altere o campo TTL para 300 segundos. Faça isso 24 a 72 horas antes da migração, para que os servidores intermediários atualizem o cache. Após a mudança, restaure o TTL para o valor padrão.

TTL alto é bom ou ruim? Depende do uso. TTL alto reduz consultas DNS e melhora performance, mas atrasa propagação de mudanças. TTL baixo acelera propagação, mas aumenta consultas e pode sobrecarregar servidores. Para registros estáveis, prefira TTL alto. Para registros que podem mudar em emergência, prefira TTL médio.

TTL afeta performance do site? Sim, mas indiretamente. TTL muito baixo em DNS aumenta a frequência de consultas DNS, o que pode adicionar latência. TTL adequado em cache HTTP e CDN reduz drasticamente o tempo de carregamento para visitantes recorrentes. O ideal é TTL alto em cache de assets estáticos, médio em DNS e baixo apenas durante migrações planejadas.

Otimização de TTL em DNS, cache HTTP e CDN exige conhecimento técnico que muitos donos de site não têm. A FULL Services entrega WordPress com configuração de cache e TTL otimizada por padrão na stack profissional, integrando WP Rocket, CDN e DNS gerenciado. Conheça os planos PRO.

Termos relacionados

Uma nova era para o WordPress.

A FULL Services redefine o CMS com uma arquitetura modular que transforma o WordPress em um motor de crescimento digital. 

Painéis personalizados

Um novo nível de controle para o WordPress. Acompanhe métricas, automações e evolução do seu site em um único painel visual.

A força por trás de grandes marcas

Para agências, estúdios e profissionais independentes que desejam oferecer soluções de alto nível com sua própria marca.

Componentes

Hero Sections

30 componentes

Seções de CTA

14 componentes

Login

14 componentes

Blog

14 componentes

Cabeçalhos

24 componentes

Seções de FAQ

53 componentes

Cadastro

53 componentes

Blog individual

53 componentes

Rodapés

28 componentes

Seções de contato

27 componentes

Seções de preços

27 componentes

Faixas

27 componentes

Portfólio

16 componentes

Seções de equipe

12 componentes

Números

12 componentes

Logotipos

12 componentes