Tempo de Resposta de um Site: o que É, Como Medir e Como Melhorar

O tempo de resposta de um site é o tempo entre um navegador (ou qualquer cliente) enviar uma requisição ao seu site e receber a primeira parte da resposta do servidor. Ele inclui encontrar o seu servidor, conectar-se a ele, configurar a criptografia e esperar a aplicação gerar a página. É um dos sinais de saúde mais úteis que um site tem, e muitas vezes é confundido com o tempo de carregamento da página.

Este guia explica o que o tempo de resposta inclui, como medi-lo, como é um bom valor, como interpretar os números ao longo do tempo e quais melhorias fazem mais diferença. Quer um número agora mesmo? Use o teste de tempo de resposta de sites gratuito e volte aqui para interpretar os resultados.

O que o tempo de resposta de um site inclui

Uma única requisição a uma página HTTPS passa por várias fases. Cada uma acrescenta tempo, e cada uma tem causas e soluções diferentes.

Deslize para o lado para ver o diagrama inteiro

O tempo desde o início da requisição até a chegada do primeiro byte da resposta se chama Time to First Byte (TTFB), ou tempo até o primeiro byte. Na prática, "tempo de resposta do servidor" e TTFB costumam ser usados como sinônimos; os monitores de uptime normalmente informam o tempo até a chegada dos cabeçalhos da resposta, que é praticamente o mesmo momento.

Vale conhecer dois detalhes:

• Visitas repetidas são mais rápidas. Os navegadores guardam as respostas de DNS em cache e reaproveitam conexões abertas, então DNS, conexão e TLS muitas vezes somem na segunda página que o visitante abre. Uma primeira visita, ou uma verificação de monitoramento em uma conexão nova, paga todas essas fases.
• Redirecionamentos multiplicam o custo. Se http://example.com redireciona para https://www.example.com/, o visitante paga por duas requisições antes de ver qualquer coisa.

Tempo de resposta x tempo de carregamento da página

Tempo de resposta e tempo de carregamento medem coisas diferentes:

• O tempo de resposta mostra com que rapidez o servidor começa a responder à requisição do documento HTML.
• O tempo de carregamento da página, e métricas centradas no usuário como o Largest Contentful Paint (LCP), incluem tudo o que acontece depois: baixar folhas de estilo, scripts, fontes e imagens e renderizar a página.

Uma página pode ter uma resposta rápida do servidor e ainda assim parecer lenta por causa de imagens ou scripts pesados, e um front-end muito bem otimizado não esconde um servidor que leva três segundos para responder. O tempo de resposta é a base: todas as outras métricas de carregamento começam depois dele. O Google documenta as métricas centradas no usuário em web.dev/vitals. Comparamos as duas perspectivas em Uptime x desempenho de sites.

Qual é um bom tempo de resposta para um site?

Não existe um único número certo, porque o tempo de resposta depende da distância, do tipo de página e da hospedagem. Algumas referências úteis:

• A orientação do Google sobre o Time to First Byte sugere que a maioria dos sites busque 0,8 segundo ou menos e considera ruins valores acima de 1,8 segundo, medidos com usuários reais.
• Páginas estáticas ou bem cacheadas, servidas de perto, podem responder em dezenas de milissegundos.
• Páginas dinâmicas que consultam um banco de dados costumam responder em algumas centenas de milissegundos.
• Levar consistentemente mais de um ou dois segundos normalmente indica algo que vale investigar.

Mais importante do que qualquer meta absoluta é a sua própria referência. Se a sua página inicial normalmente responde em 250 ms e de repente passa a levar 1.500 ms, algo mudou, mesmo que 1,5 segundo não seja catastrófico por si só.

Como medir o tempo de resposta de um site

1. Use uma ferramenta online de tempo de resposta

A opção mais rápida é uma ferramenta que acessa a sua página a partir de um servidor externo e divide o resultado por fase. Nosso teste de tempo de resposta de sites gratuito envia três requisições em conexões novas, mostra a mediana do tempo até o primeiro byte e informa quanto tempo levaram o DNS, a conexão, o TLS e o processamento no servidor, para você ver qual parte precisa de ajuste.

2. Meça pela linha de comando com o curl

O curl consegue exibir tempos detalhados. Salve este formato em um arquivo chamado curl-format.txt:

    dns lookup:  %{time_namelookup}s
       connect:  %{time_connect}s
   tls (total):  %{time_appconnect}s
 first byte at:  %{time_starttransfer}s
         total:  %{time_total}s

Depois rode:

curl -o /dev/null -s -w "@curl-format.txt" https://example.com/

Observe que o curl informa tempos acumulados: cada valor é medido a partir do início da requisição. Para obter a duração de uma única fase, subtraia o valor anterior. Por exemplo, o processamento no servidor é aproximadamente time_starttransfer − time_appconnect.

3. Use as ferramentas de desenvolvedor do navegador

Abra as ferramentas de desenvolvedor, vá até a aba Rede, recarregue a página e selecione a primeira requisição (o documento HTML). A visualização de tempos mostra a consulta DNS, a conexão inicial, o SSL, a "espera pela resposta do servidor" (TTFB) e o download do conteúdo. Lembre-se de que o seu navegador pode reaproveitar o DNS em cache e conexões abertas.

4. Monitore continuamente

Uma única medição é uma foto. O tempo de resposta muda com o tráfego, o horário, as tarefas em segundo plano e o crescimento gradual dos dados. Um monitor de uptime registra o tempo de resposta em cada verificação, o que transforma as fotos em uma tendência. O UptimeStats guarda o tempo de resposta de cada verificação, a cada 5 minutos, e mostra gráficos de 24 horas e de 7 dias na página de cada site.

Como interpretar os dados de tempo de resposta

Olhe tendências, não valores isolados

As verificações individuais variam por causa das condições da rede. Uma verificação lenta raramente significa algo. Olhe o gráfico ao longo de horas e dias: a linha está estável, subindo aos poucos ou com picos em certos horários? Medianas e médias de um período são mais confiáveis do que valores isolados.

Padrões e o que costumam significar

• Aumento gradual ao longo de dias ou semanas: tabelas do banco de dados crescendo sem índices adequados, acúmulo de dados, disco enchendo ou tráfego crescendo.
• Picos no mesmo horário todos os dias: tarefas agendadas, como backups, importações ou geração de relatórios, disputando recursos.
• Um salto repentino: uma publicação, a atualização de um plugin, uma mudança de configuração ou de hospedagem.
• Tempos de resposta subindo seguidos de tempo esgotado: o servidor está ficando sem capacidade, um aviso antecipado de queda. Veja O que deixa um site fora do ar?
• Conexão e TLS demorados, mas processamento rápido no servidor: o servidor está longe de onde está sendo medido, ou o caminho da rede está congestionado.

A distância importa

O tempo de resposta medido por um servidor de monitoramento depende da distância entre ele e o seu servidor. Um monitor em outro continente sempre vê números maiores do que um que está perto. Compare medições feitas do mesmo local ao longo do tempo, e lembre-se de que a experiência dos seus visitantes depende de onde eles estão.

Como melhorar o tempo de resposta de um site

Comece pela fase que leva mais tempo. A divisão do teste de tempo de resposta ou do curl mostra qual é.

Se o processamento no servidor for lento

Esse é o gargalo mais comum e normalmente a maior oportunidade.

• Faça cache de páginas inteiras. A resposta mais rápida é aquela que o servidor não precisa calcular. O cache de página inteira entrega HTML pronto para visitantes anônimos; a maioria dos gerenciadores de conteúdo tem plugins ou módulos de cache maduros.
• Use um cache de objetos. Um armazenamento em memória evita repetir consultas e cálculos pesados a cada requisição.
• Otimize as consultas ao banco de dados. Ative o log de consultas lentas, crie índices para as buscas frequentes, carregue só os dados de que a página precisa e remova consultas que rodam a cada requisição sem necessidade.
• Revise plugins e extensões. Cada um pode acrescentar trabalho a todas as requisições. Remova o que você não usa e meça depois de cada mudança.
• Mantenha o software atualizado. Versões mais novas das linguagens, servidores web e bancos de dados costumam trazer ganhos de desempenho importantes, além de correções de segurança.
• Tire o trabalho lento da requisição. Enviar e-mails, gerar miniaturas ou chamar APIs externas lentas pode acontecer em tarefas em segundo plano.
• Dimensione o servidor corretamente. Se a CPU ou a memória vivem perto do limite, a otimização só vai até certo ponto; podem ser necessários mais recursos ou mais servidores.

Se a conexão e o TLS forem lentos

• Sirva o site mais perto dos seus visitantes. Escolha uma região de hospedagem próxima do seu público principal, ou coloque uma CDN na frente do site para que as conexões terminem perto deles.
• Ative o TLS 1.3. Ele precisa de menos idas e voltas no handshake do que as versões anteriores.
• Ative o HTTP/2 ou o HTTP/3 para reduzir o custo das conexões dos recursos que vêm depois do HTML.
• Sirva uma cadeia de certificados compacta e completa e ative o OCSP stapling. Confira o seu certificado com o verificador de SSL.

Se o DNS for lento

• Use um provedor de DNS rápido e confiável, com servidores perto do seu público.
• Evite longas cadeias de registros CNAME, em que cada um exige outra consulta.
• Use TTLs razoáveis para que os resolvedores possam guardar as respostas em cache. Confira seus registros com a ferramenta de consulta DNS e leia como problemas de DNS afetam a disponibilidade.

Se os redirecionamentos acrescentarem tempo

Aponte os links direto para as URLs finais, atualize os links internos depois de migrações e mantenha os redirecionamentos necessários com um único salto, por exemplo direto de http://example.com para https://example.com/. O verificador de status HTTP revela as cadeias de redirecionamento, e nosso guia de códigos de status HTTP explica a diferença entre 301 e 302.

Erros comuns ao medir o tempo de resposta

• Testar só do seu próprio computador. Seu navegador reaproveita conexões e o DNS em cache, e você pode estar perto do servidor.
• Julgar por uma única medição. Use várias amostras e olhe a mediana.
• Medir só uma página em cache. A página inicial pode estar em cache enquanto as páginas de produto, busca ou conta são geradas a cada requisição. Teste as páginas que importam.
• Confundir tempo de resposta com tempo de carregamento. Um TTFB rápido não garante uma página rápida, e a solução de cada um é diferente.
• Ignorar a tendência. Tempos de resposta subindo aos poucos são um dos melhores avisos antecipados que você pode ter.

Perguntas frequentes

Qual é a diferença entre tempo de resposta e TTFB?

O TTFB é o tempo até a chegada do primeiro byte da resposta. "Tempo de resposta do servidor" costuma ser usado para dizer a mesma coisa. Algumas ferramentas usam "tempo de resposta" para o download completo da resposta, então confira como cada ferramenta define o termo.

O tempo de resposta do site afeta o SEO?

O tempo de resposta é a primeira parte de todo carregamento de página, então influencia métricas centradas no usuário como o Largest Contentful Paint, que fazem parte da forma como os mecanismos de busca avaliam a experiência na página. A relevância e a qualidade do conteúdo importam muito mais, mas um servidor lento deixa todo o resto mais lento. Respostas muito lentas ou com falha também afetam a eficiência com que os mecanismos de busca rastreiam o seu site.

Por que o meu tempo de resposta muda a cada teste?

As condições da rede, a carga do servidor, o cache e as tarefas em segundo plano variam. Por isso boas ferramentas fazem várias medições e informam a mediana, e por isso monitorar ao longo do tempo diz mais do que um teste isolado.

Com que frequência devo verificar o tempo de resposta?

Continuamente, por meio de monitoramento. Verificações a cada poucos minutos dão uma tendência confiável sem acrescentar uma carga relevante ao seu servidor.

Resumo

• O tempo de resposta de um site é quanto o servidor leva para começar a responder, incluindo DNS, conexão, TLS e processamento no servidor.
• O Google sugere buscar um TTFB de 0,8 segundo ou menos; a sua própria referência e a tendência importam ainda mais.
• Meça com divisão por fases para saber o que corrigir: uma ferramenta online, o curl ou as ferramentas de desenvolvedor do navegador.
• Cache e consultas eficientes ao banco de dados resolvem a maioria dos servidores lentos; CDNs, TLS 1.3 e menos redirecionamentos atacam os atrasos ligados à rede.
• Monitore o tempo de resposta continuamente para pegar a lentidão antes que ela vire queda.

Teste o seu site agora com o teste de tempo de resposta gratuito, ou comece a monitorar de graça para acompanhar o tempo de resposta a cada 5 minutos.