Segundo a análise de outubro de 2026 de um blogue de startups, os limiares de Core Web Vitals mantêm-se: LCP até 2,5 segundos, INP até 200 ms e CLS até 0,1, medidos no percentil 75 de visitas reais. Mas há um indicador que pesa muito nestes números e que muita gente ignora: o tempo de resposta do servidor e SEO estão mais ligados do que parece. Antes de mexer em imagens ou em código, convém perceber o que o servidor faz pelo seu site.
O tempo de resposta do servidor (TTFB) é o intervalo entre o pedido do navegador e o primeiro byte recebido. Um servidor lento atrasa a renderização, prejudica o LCP e pode reduzir o número de páginas que o Googlebot rastreia. Não é um Core Web Vital, mas influencia diretamente os que são.
Mito 1: “O tempo de resposta do servidor não é um fator de SEO”
Esta é a ideia mais comum e a mais perigosa. Tecnicamente, o TTFB não é um Core Web Vital, e a documentação do Google não o apresenta como sinal de ranking isolado. O problema é que um TTFB lento atrasa o LCP, e o LCP é avaliado. Além disso, um servidor que demora a responder faz com que o Googlebot consiga visitar menos páginas por sessão, o que atrasa a indexação de conteúdos novos.
Na prática, quando o servidor consome logo o orçamento de LCP, qualquer otimização de imagens chega tarde. Um guia de e-commerce publicado em outubro de 2026 recomenda, por isso, corrigir primeiro o tempo de resposta do servidor. Faz sentido seguir essa ordem.
Mito 2: “Se o site está rápido no meu computador, está tudo bem”
Testar a partir da sua rede de escritório ou de casa, com cache já aquecida, dá uma imagem enganadora. Quem visita o site é um utilizador com telemóvel, em rede móvel, muitas vezes longe do servidor. Por isso, a medição deve ser feita com dados reais de visitantes e com testes a partir de diferentes localizações.
Dica: Compare sempre o TTFB em páginas com cache e sem cache. Se a diferença for grande, o problema está quase sempre na aplicação ou na base de dados, e não na ligação.
Mito 3: “Existe um valor universal de TTFB que garante bons resultados”
Aqui há confusão real. Há quem cite um valor de “bom” até 0,8 segundos, com orientação do web.dev, enquanto outros guias apontam para menos de 200 ms ou menos de 500 ms. Não encontrámos uma atualização oficial recente da Google para estes valores, por isso o mais sensato é validar a referência diretamente no web.dev antes de tomar decisões.
O que importa, na prática, é a tendência. Se o seu TTFB oscila muito entre horas do dia ou sobe depois de cada atualização, há um problema a resolver, independentemente do número exato de referência.
Mito 4: “Mais servidor resolve sempre o problema”
Subir de plano de alojamento web nem sempre resolve. Se a lentidão vem de consultas pouco otimizadas, de plugins em excesso ou de um tema WordPress mal construído, um servidor mais potente apenas adia o problema. Em muitos casos, a combinação de cache de página, otimização de base de dados e renderização mais eficiente dá resultados melhores a menor custo.

Uma tendência técnica de 2025 e 2026 vai nesse sentido: os maiores ganhos de TTFB e LCP surgiram ao combinar implementação em edge com renderização em streaming. Ainda assim, cada projeto é diferente, e a solução certa depende de uma auditoria à sua arquitetura.
Mito 5: “Core Web Vitals e tempo de resposta são uma preocupação só para técnicos”
Quem decide o orçamento precisa de perceber o impacto. Há estudos citados por blogues do setor que associam pequenas melhorias de velocidade a aumentos de conversão, mas esses dados não foram verificados de forma independente e devem ser lidos com cautela. O que é verificável é que cada segundo de espera aumenta a probabilidade de o visitante sair antes de ver a sua oferta.
Para complementar a leitura, veja também O Tempo não pára, dê o Salto Digital Já!.
Se quer perceber como a velocidade afeta as vendas do seu negócio, vale a pena ler Como o Tempo de Carregamento do Site Pode Influenciar as Vendas em 2026.
Como verificar se o seu servidor está a prejudicar o SEO
O primeiro passo é medir, não adivinhar. Use o Google Search Console para acompanhar o relatório de estatísticas de rastreamento, onde pode ver o tempo médio de resposta que o Googlebot recebe. Depois, cruze esses dados com o relatório de Core Web Vitals e com o PageSpeed Insights.

Se o TTFB estiver consistentemente acima de 800 ms em páginas importantes, comece por aí. Procure também picos de erros 5xx nos registos do servidor, porque um erro intermitente pode fazer o Google rastrear menos o seu site durante semanas.
| Sinal | O que indica | Ação recomendada |
|---|---|---|
| TTFB alto em todas as páginas | Servidor ou alojamento sobrecarregado | Rever plano de alojamento e cache |
| TTFB alto só em páginas dinâmicas | Consultas à base de dados ou plugins | Otimizar consultas e reduzir plugins |
| Erros 5xx intermitentes | Falhas de estabilidade | Analisar registos e recursos do servidor |
Porque é que a velocidade do servidor importa para o rastreamento
O Googlebot tem um orçamento de rastreamento limitado para cada site. Quando as respostas são lentas, o robô visita menos URLs no mesmo intervalo de tempo. Em sites pequenos, isto raramente é um problema. Em lojas online com milhares de produtos, ou em sites com conteúdos publicados diariamente, pode atrasar a indexação das páginas mais importantes.
Por isso, além de acelerar o servidor, vale a pena manter o ficheiro robots.txt limpo e o sitemap atualizado, para que o rastreamento seja dirigido às páginas que realmente geram negócio.
O que fazer a seguir, sem complicar
Comece pela medição, depois corrija o servidor e só então avance para imagens, scripts e fontes. Esta ordem poupa tempo e evita gastar orçamento em melhorias que não chegam a ser visíveis para o utilizador. Se o seu site depende de visibilidade local, a velocidade é também um fator de confiança para quem pesquisa perto de si, como explicamos em SEO local em Lisboa e Cascais: mais clientes próximos.
Para empresas que querem perceber por onde começar, o ponto de partida costuma ser uma auditoria técnica completa. Pode ler mais sobre a abordagem da equipa em Porque as Empresas Perdem Tempo a Resolver os Mesmos Problemas Repetidamente.
Na Digital Xperience, começamos quase sempre por medir o desempenho real do seu site e só depois propomos alterações.
Acompanhar a evolução das métricas de desempenho
O tempo de resposta do servidor não se resolve de uma vez por todas. Os limiares de Core Web Vitals mantêm-se em 2026, mas o INP passou por uma atualização de metodologia que pode fazer com que sites limítrofes passem a reprovar. Por isso, reveja as métricas pelo menos uma vez por trimestre e após cada alteração de tema, plugin ou alojamento.
Perguntas frequentes sobre tempo de resposta do servidor e SEO
Qual é um bom tempo de resposta do servidor para SEO?
Não existe um valor universal. Há referências que vão de 200 ms a 800 ms, consoante a fonte. Valide a referência atual no web.dev e acompanhe a tendência do seu próprio site.
O TTFB é um Core Web Vital?
Não. É um indicador de diagnóstico, mas influencia o LCP, que é avaliado. Por isso, melhorar o TTFB costuma melhorar também o LCP.
Mudar de alojamento web melhora sempre o SEO?
Nem sempre. Se o problema estiver em consultas, plugins ou no tema, um alojamento mais caro não resolve a causa. Uma auditoria ajuda a identificar a origem antes de gastar.
Como sei se o Googlebot está a ser prejudicado pela lentidão?
No Google Search Console, o relatório de estatísticas de rastreamento mostra o tempo médio de resposta e a quantidade de pedidos. Uma queda de rastreamento acompanhada de tempos altos é um sinal claro.
Cache resolve o problema do tempo de resposta?
Ajuda muito em páginas que não mudam a cada visita. Em páginas dinâmicas, como carrinhos ou áreas de cliente, é preciso otimizar a aplicação e a base de dados.
Vale a pena pedir ajuda externa para esta análise?
Depende da complexidade do site e da equipa interna. Se não tem alguém com conhecimento técnico de servidores, uma auditoria externa poupa tempo e evita correções mal priorizadas.


