Hospedagem e TTFB: o Que o Servidor Custa ao SEO

Quando você compara planos de hospedagem para decidir onde colocar um site que depende de busca orgânica, a tabela de recursos costuma mostrar espaço em disco, tráfego mensal e quantidade de contas de e-mail. Nenhuma dessas colunas diz nada sobre a métrica que de fato separa um plano bom de um ruim para SEO: o TTFB, o tempo até o primeiro byte — quanto tempo o navegador, ou o Googlebot, espera entre pedir a página e receber o primeiro pedaço de resposta do servidor.

Essa é a decisão de compra real escondida atrás da tabela de recursos. Dois planos com o mesmo disco e a mesma banda podem ter TTFB completamente diferente, porque TTFB não depende de quanto espaço você contratou. Depende de onde fica o servidor, quantos outros sites dividem a mesma CPU com o seu, e quão eficiente é o código que roda a cada requisição. É isso que este texto tenta desembaraçar: quanto do tempo de resposta é física que nenhum upgrade resolve, quanto é capacidade que um plano melhor resolve, e quanto é um problema de código que nenhuma migração resolve sozinha.

TTFB tem duas partes, e você só compra uma delas

Cada requisição HTTP passa por uma sequência de etapas antes de o navegador receber o primeiro byte de resposta. Separar essas etapas importa porque elas têm naturezas diferentes: umas são limitadas pela distância física entre quem pede e quem responde, outras são limitadas pelo que o servidor precisa processar antes de montar a resposta.

A parte de propagação — o tempo que os pacotes levam para viajar pela rede — é fixada pela distância e pela rota dos cabos. Nenhum plano de hospedagem, por mais caro que seja, reduz essa parte se o servidor continuar longe do visitante. Já a parte de processamento — consultar o banco de dados, montar o template, aplicar regras de cache — é exatamente onde um plano melhor, ou um código melhor, faz diferença real.

• Resolução de DNS: traduzir o domínio em endereço IP, quase instantânea se já estiver em cache no resolvedor de quem pergunta
• Handshake TCP: uma ida e volta completa só para abrir a conexão, antes de qualquer dado trafegar
• Handshake TLS: mais uma ou duas idas e voltas para negociar o certificado HTTPS, também antes de qualquer conteúdo
• Processamento no servidor: o tempo que o backend leva para consultar dados, rodar o template e devolver o HTML
• Chegada do primeiro byte: o instante em que o navegador finalmente tem algo para começar a interpretar

A distância que nenhum upgrade de plano resolve

A luz viaja por fibra óptica a cerca de dois terços da velocidade que atinge no vácuo, o que na prática dá algo perto de 200 mil quilômetros por segundo. Parece rápido, e é — mas a internet não é uma linha reta, e cada requisição precisa de mais de uma ida e volta antes de qualquer conteúdo chegar. Entre São Paulo e Lisboa há mais de 7 mil quilômetros em linha reta, e a rota real dos cabos submarinos costuma ser bem mais longa que isso, porque segue pontos de interconexão específicos e não o caminho geometricamente mais curto.

Isso significa que um site com origem em São Paulo atendendo visitantes — ou o rastreador do Google operando a partir — de Portugal, ou uma origem em Lisboa atendendo principalmente o Brasil, carrega uma latência de ida e volta que facilmente passa de 150 a 200 milissegundos por trajeto, antes de qualquer processamento no servidor começar. Como o handshake TCP consome uma dessas idas e voltas e o handshake TLS consome mais uma ou duas, dependendo da versão do protocolo, essa distância se multiplica em cada conexão nova — e volta a pesar sempre que a conexão precisa ser reaberta.

O problema é que a página de vendas de um plano de hospedagem raramente informa em qual país, ou mesmo em qual cidade, o datacenter está. É comum contratar hospedagem pelo preço ou pela marca e descobrir só depois, medindo, que o público majoritário do site fica do outro lado do Atlântico em relação ao servidor — pagando essa taxa de distância em toda requisição que não está em cache.

Por que o CDN resolve um problema e deixa o outro intacto

Um CDN funciona distribuindo cópias de arquivos por servidores de borda espalhados geograficamente, de forma que um visitante em Lisboa baixe uma imagem ou um arquivo CSS de um nó próximo, não do servidor de origem em São Paulo. Isso reduz drasticamente o tempo de carregamento desses arquivos — e é exatamente para isso que um CDN serve bem.

O que um CDN normalmente não resolve é o documento HTML em si, quando esse documento é gerado dinamicamente a cada requisição — o caso comum de um site em WordPress ou qualquer stack que monta a página no momento da visita, com sessão, cookies ou parâmetros de URL envolvidos. Configurações padrão de CDN excluem justamente esse tipo de resposta do cache de borda, porque cachear a página errada para a pessoa errada é um risco maior do que servi-la um pouco mais devagar. O resultado é que o HTML continua fazendo a viagem completa até a origem, com a distância inteira descrita acima, mesmo com um CDN ativo cuidando perfeitamente dos arquivos estáticos.

Para SEO isso importa porque a requisição que o rastreador faz para avaliar a página é, antes de tudo, a requisição do documento HTML — é ali que estão o título, o conteúdo e os links. Um CDN rápido para imagens e scripts não muda em nada quanto tempo o Googlebot esperou pelo HTML que continha o que ele veio buscar.

• O que o CDN cacheia bem: imagens, CSS, JavaScript, fontes — arquivos iguais para qualquer visitante
• O que o CDN costuma deixar passar direto: o HTML dinâmico, com cookies de sessão ou parâmetros de rastreamento
• O que o rastreador avalia primeiro: o documento HTML, não os arquivos estáticos que ele referencia

Quando o servidor demora, o Googlebot passa a bater menos vezes

O sistema de rastreamento do Google ajusta a velocidade com que visita um site com base em como esse site responde. Se as respostas ficam mais lentas ou começam a incluir timeouts e erros de servidor, o ritmo de visitas cai — um comportamento de autoproteção do lado do rastreador, não uma penalidade deliberada, mas com o mesmo efeito prático de uma penalidade: menos páginas revisitadas por dia.

A parte que costuma passar despercebida é o atraso entre causa e sintoma. O servidor pode ter sofrido sobrecarga numa semana de tráfego alto, se recuperado depois, e ainda assim o efeito no rastreamento só aparece semanas mais tarde, quando páginas que antes eram indexadas normalmente passam a ficar marcadas como descobertas mas ainda não rastreadas, ou rastreadas mas ainda não indexadas, no relatório de cobertura. Nesse momento, uma verificação manual da página já não mostra nada de errado — o servidor responde rápido de novo — e a investigação costuma ir procurar o problema no conteúdo ou na estrutura do site, exatamente onde ele não está.

É por isso que vale olhar o gráfico de tempo médio de resposta nas estatísticas de rastreamento do Search Console junto com qualquer queda de frequência de visitas, cruzando as datas com picos de tráfego ou incidentes conhecidos de lentidão — e não só investigar a cobertura isoladamente, como se ela fosse a causa em vez do sintoma.

Antes de trocar de hospedagem, descubra qual é o problema real

Um TTFB alto costuma ter uma de duas causas bem diferentes, e elas se parecem de fora mas pedem soluções opostas. A primeira é capacidade: em planos compartilhados com CloudLinux, cada conta roda dentro de um contêiner (LVE) com um teto fixo de CPU e memória. No instante em que o processo PHP da sua página ultrapassa esse teto, as requisições seguintes entram numa fila — mesmo que o servidor físico como um todo esteja praticamente ocioso atendendo outras contas. Esse tipo de problema aparece em picos: durante uma sessão de rastreamento intensa do Googlebot, num horário de tráfego alto, numa campanha que trouxe volume extra.

A segunda causa é consulta de banco de dados sem índice, ou um padrão de consultas repetidas desnecessárias a cada carregamento. Esse tipo de lentidão é constante, não depende de quantos outros sites dividem o servidor com o seu, e continua idêntico mesmo depois de migrar para um servidor mais caro — porque o gargalo é a consulta em si, não a CPU disponível para executá-la. Migrar hospedagem, nesse caso, só move o mesmo problema para uma máquina mais cara.

• Rode a mesma URL em horários diferentes com `curl -w "%{time_starttransfer}\n" -o /dev/null -s`: se o tempo varia muito com o horário e o tráfego, é limite de recursos; se fica sempre alto, é processamento
• Compare o gráfico de tempo médio de resposta em Configurações, Estatísticas de rastreamento, no Search Console, com os horários de pico do site
• Ative o log de consultas lentas do banco de dados e procure as mesmas queries aparecendo repetidamente sem usar índice
• Confira o painel de uso de recursos do provedor: a maioria dos planos com cPanel mostra quando a conta atingiu o limite de CPU ou memória

Montando um orçamento de TTFB antes de assinar ou migrar

O jeito mais útil de comparar hospedagens não é olhar disco e banda, é montar um orçamento mental para cada etapa do TTFB e saber qual delas o novo plano realmente muda. A distância até o datacenter é uma linha fixa que só muda escolhendo uma região mais próxima do público principal do site, ou adicionando uma camada de borda capaz de responder páginas completas, não só arquivos estáticos. O tempo de processamento é a linha que um plano com mais CPU dedicada, cache de opcode e cache de objetos consegue reduzir de verdade.

Times de engenharia costumam tratar um tempo de processamento no servidor consistentemente acima de algumas centenas de milissegundos como um sinal de alerta, mesmo quando o site parece funcionar bem no dia a dia — porque esse número tende a piorar exatamente nos momentos de mais tráfego, que são os momentos em que mais importa responder rápido, tanto para visitantes quanto para o rastreador.

Meça antes de migrar. Trocar de hospedagem resolve exatamente um tipo de problema — capacidade insuficiente do plano atual — e não resolve os outros dois: distância geográfica do público, e consultas de banco de dados ineficientes. Descobrir qual desses três você realmente tem custa uma tarde de testes; adivinhar custa uma migração inteira, com o mesmo problema esperando do outro lado.