Otimizaste o teu conteúdo. O teu site tem competência, autoridade e sinais de confiança. Mas quando um rastreador de IA chega à tua página e esbarra num limite de tempo, quando o teu servidor demora 6 segundos a responder, ou quando o LCP não acaba de ser desenhado em 5 segundos, o rastreador segue em frente. O teu conteúdo nunca é indexado. As tuas citações nunca acontecem.
A velocidade mata a visibilidade. Não de forma lenta. De forma instantânea e definitiva.
Os rastreadores de IA funcionam sob restrições que os motores de pesquisa tradicionais não têm. Têm janelas de limite de tempo rígidas, orçamentos de computação limitados e pouca paciência. Uma página que fica perfeitamente classificada no Google pode ser completamente invisível para o ChatGPT, o Perplexity ou o Claude porque não carrega dentro do prazo do rastreador. Este capítulo explica como os Core Web Vitals funcionam para a IA, que métricas contam mais e que mudanças precisas de fazer.
O que medem os Core Web Vitals e porque existem
Os Core Web Vitals são três métricas que o Google criou para medir a experiência real do utilizador. Captam o momento em que o navegador começa a mostrar conteúdo, o momento em que os utilizadores podem interagir com a página e quão estável fica o layout durante o carregamento. O Google trata-os como fatores de classificação. Mas, para os rastreadores de IA, são fatores de sobrevivência.
As três métricas são:
Largest Contentful Paint (LCP): quanto tempo até carregar o maior elemento visual. O objetivo é menos de 2,5 segundos. É o que os utilizadores veem primeiro: se a tua imagem principal, o teu título ou a tua secção de conteúdo principal demora 4 segundos a aparecer, tanto as pessoas como os rastreadores têm de esperar.
Interaction to Next Paint (INP): quanto tempo demora o navegador a responder depois de o utilizador clicar em algo. O objetivo é menos de 200 milissegundos. Esta métrica testa se o teu JavaScript está inchado ou se a tua página bloqueia quando os rastreadores simulam interação.
Cumulative Layout Shift (CLS): quanto a página salta durante o carregamento. O objetivo é menos de 0,1. Quando os elementos se deslocam de forma inesperada, os rastreadores extraem conteúdo baralhado ou incompleto. Os teus parágrafos escritos com cuidado ficam truncados na interpretação do rastreador.
Para a pesquisa tradicional, estas métricas são pistas. Para os rastreadores de IA, são limites rígidos.
Porque é que os rastreadores de IA têm requisitos de velocidade diferentes dos do Google
O rastreador do Google distribui o trabalho. Rastreia milhões de URLs em milhares de servidores. Pode dar-se ao luxo de esperar 10 segundos que uma página carregue porque a espera se dilui por uma infraestrutura enorme.
Os rastreadores de IA funcionam com inferência por pergunta. Quando um utilizador faz uma pergunta ao ChatGPT, o Perplexity tem 3 a 5 segundos para encontrar, obter e interpretar o teu conteúdo antes de a resposta ter de começar a ser gerada. Cada segundo conta. Cada milissegundo é contado contra o orçamento de rastreio.
Os estudos sobre o comportamento dos rastreadores de IA mostram que os sites com First Contentful Paint abaixo de 0,4 segundos têm em média 6,7 citações, enquanto os sites que carregam em mais de 1,13 segundos têm em média 2,1 citações. Isto não é correlação. É causalidade. As páginas lentas são ignoradas.
O rastreador de obtenção do ChatGPT tem um limite de tempo documentado. As páginas que não respondem dentro dessa janela são marcadas como inacessíveis e perdem prioridade em futuras tentativas de rastreio. O robô do Perplexity faz o mesmo. Um site que demora 6 segundos a responder não tem uma segunda hipótese.
Time to First Byte (TTFB): a métrica que mais importa aos rastreadores de IA
O TTFB mede o intervalo entre o envio de um pedido e a receção do primeiro byte de volta do servidor. É a medida mais pura da capacidade de resposta do servidor.
Para os rastreadores de IA, o TTFB determina se chegam sequer a tentar desenhar a página. Se o teu servidor demora 700 milissegundos a responder, o rastreador já gastou 700 milissegundos da sua janela de 3 a 5 segundos. O rastreador abandona por completo o desenho da página e passa a interpretar apenas o HTML, o que significa que o teu conteúdo desenhado por JavaScript fica invisível.
Os valores de referência são claros. Um TTFB abaixo de 200 milissegundos é considerado excecional. Entre 200 e 500 milissegundos é aceitável, mas não ideal. Acima de 600 milissegundos, tens um problema de infraestrutura do servidor.
A maioria dos artigos sobre desempenho trata o TTFB como secundário face às métricas visuais. Para os rastreadores de IA, é o porteiro. Se o TTFB falha, nada mais importa.
As causas comuns de um TTFB lento incluem consultas lentas à base de dados em cada carregamento de página, alojamento sobrecarregado com demasiados sites por servidor, encaminhamento geográfico fraco dos pedidos e falta de cache numa rede de distribuição de conteúdo (CDN). Não são problemas de design. São problemas de infraestrutura.
Largest Contentful Paint (LCP): esperar pelo elemento grande
O LCP mede o tempo até o maior elemento visual carregar por completo. Normalmente é uma imagem principal, uma imagem de fundo ou um grande bloco de texto. Nas páginas com muito conteúdo, é a área de conteúdo principal.
Um LCP abaixo de 2,5 segundos é o limite "bom". Os rastreadores de IA citam páginas neste intervalo 2,8 vezes mais vezes do que páginas com LCP mais lento. A diferença não é subtil.
O rastreador não espera que todos os elementos acabem de carregar. Mas espera que o conteúdo principal apareça. Se a tua imagem principal tem 4 megabytes e não a otimizaste para a web, o rastreador fica parado enquanto a imagem é transferida. Quando a imagem acaba de carregar, já passaste o limite de tempo do rastreador.
As causas comuns de um LCP lento incluem imagens demasiado grandes sem compressão, vídeos incorporados não otimizados que bloqueiam o desenho da página, tipos de letra web que não são reduzidos e não carregam depressa, e scripts de terceiros que são desenhados acima da dobra. Cada um destes acrescenta segundos ao LCP.
A solução não é esperar mais. A solução é fazer o LCP acontecer mais depressa. Isto significa otimização de imagens, carregamento diferido do conteúdo abaixo da dobra, carregamento assíncrono de scripts e, possivelmente, trocar elementos pesados de terceiros por alternativas em HTML estático.
Interaction to Next Paint (INP): desempenho da execução de JavaScript
O INP mede a capacidade de resposta. Quando um utilizador (ou um rastreador que simula um utilizador) interage com a página, quanto tempo demora a mudar algo no ecrã? O objetivo é menos de 200 milissegundos.
Para os rastreadores de IA, o INP revela se o teu JavaScript está otimizado ou inchado. Uma má pontuação de INP sinaliza que a tua página tem demasiado código a correr na thread principal, ou que o código não está devidamente dividido e diferido.
Os rastreadores que simulam interação fazem-no para extrair conteúdo dinâmico. Se a tua página carrega HTML estático mas depende de JavaScript para desenhar formulários, conteúdo condicional ou elementos interativos, o rastreador precisa de executar esse JavaScript. Se o JavaScript é lento, o rastreador obtém uma má pontuação de INP e marca a tua página como ineficiente.
O problema escondido do desenho no lado do cliente é que a maioria dos rastreadores de IA nem sequer executa JavaScript. A investigação mostra que o HTML estático com schema markup atinge 94% de sucesso na interpretação, enquanto o conteúdo desenhado por JavaScript fica nos 23%. Isto significa que, se o teu conteúdo está escondido atrás de JavaScript, os rastreadores de IA podem nunca vê-lo.
Se o teu site usa desenho no lado do cliente, o problema do INP torna-se um problema de visibilidade. O rastreador não pode esperar que o JavaScript execute, por isso ignora o conteúdo que depende de JavaScript.
Cumulative Layout Shift (CLS): estabilidade durante a extração
O CLS mede a instabilidade visual. Quando os elementos da página se movem durante o carregamento, o Cumulative Layout Shift aumenta. O objetivo é menos de 0,1.
Para os rastreadores, o CLS não tem a ver com a experiência do utilizador. Tem a ver com o rigor da interpretação. Quando o DOM se desloca enquanto o rastreador está a extrair conteúdo, este pode apanhar os elementos errados. Um título pode deslocar-se para o espaço de outro título. Uma barra lateral pode empurrar o conteúdo principal para fora de posição. O rastreador extrai o texto que estiver numa posição, e não o texto que logicamente lá pertence.
As causas comuns de um CLS alto incluem espaços de anúncios que carregam tarde e empurram o conteúdo para baixo, imagens sem dimensões especificadas que carregam e deslocam o layout, tipos de letra web que mudam e alteram o espaçamento, e carrosséis com reprodução automática que deslocam o conteúdo. Cada um faz o layout mexer-se.
A solução é reservar espaço para tudo o que vai carregar. Especifica as dimensões das imagens no HTML. Define o font-display como swap para que os tipos de letra não bloqueiem o desenho da página. Carrega anúncios e conteúdo dinâmico em contentores reservados que não causem deslocações do layout.
Como otimizar a velocidade para os rastreadores de IA
A otimização de velocidade para os rastreadores de IA é diferente da otimização de velocidade para as pessoas. Os utilizadores ligam a quando veem a página e a quando podem interagir com ela. Os rastreadores ligam a quando o servidor responde e a se todo o conteúdo acaba de ser desenhado.
Começa pelo TTFB. Se o teu servidor demora mais de 500 milissegundos a responder, nada mais importa. Faz uma auditoria às tuas consultas à base de dados, muda para um fornecedor de alojamento mais rápido, implementa cache ao nível da aplicação ou usa uma CDN. O investimento no TTFB compensa de imediato na cobertura dos rastreadores.
Otimiza as imagens. Todas as imagens da tua página devem ser comprimidas, redimensionadas para as dimensões em que são mostradas e servidas em formatos modernos como o WebP, com alternativas em PNG. Usa uma ferramenta de compressão de imagens. Para as imagens principais, usa uma CDN com otimização automática.
Adia o JavaScript não crítico. Carrega apenas o JavaScript que é absolutamente necessário para o rastreador ver o conteúdo. Os scripts que acompanham estatísticas, carregam anúncios ou alimentam funcionalidades interativas devem ser diferidos ou carregados de forma assíncrona. Isto mantém a thread principal livre e a execução rápida.
Desenha o conteúdo crítico no servidor. Se o teu site usa uma framework do lado do cliente, desenha o caminho crítico no servidor e hidrata no cliente. Isto garante que os rastreadores veem o conteúdo de imediato. A geração de sites estáticos (SSG) é ainda melhor: constrói as tuas páginas em HTML no momento da publicação.
Evita grandes elementos incorporados de terceiros. Se incorporas leitores do YouTube, leitores de áudio ou grandes widgets externos, eles bloqueiam o desenho da página. Substitui-os por marcadores de posição que carregam ao clicar, ou extrai a informação essencial para HTML estático.
Reserva espaço para o conteúdo dinâmico. Define dimensões explícitas para imagens, anúncios e secções dinâmicas. Isto evita deslocações do layout e garante que o rastreador extrai o conteúdo certo.
Usa uma CDN. Uma rede de distribuição de conteúdo encaminha os pedidos para o servidor geograficamente mais próximo, reduzindo a latência e o TTFB. A maioria das CDN também oferece otimização e compressão automática de imagens.
O que a WEMASY inclui para a velocidade e a otimização para rastreadores
O criador de websites da WEMASY inclui alojamento com cache CDN automática, otimização de imagens no carregamento e desenho no servidor de todo o conteúdo do site. As páginas feitas com a WEMASY cumprem por predefinição os padrões dos Core Web Vitals.
Quando publicas um site com a WEMASY, o teu TTFB é otimizado através da nossa CDN, as tuas imagens são redimensionadas e comprimidas automaticamente, e o teu HTML é servido como páginas estáticas, não gerado a pedido. Isto significa que os rastreadores de IA veem o teu conteúdo de imediato, sem esperar por desenho ou processamento.
Descobre o que está incluído nos planos de preços da WEMASY.
Perguntas frequentes
A velocidade da página afeta mais as citações da IA do que o SEO tradicional?
Os rastreadores de IA são mais sensíveis à velocidade porque funcionam com restrições de tempo mais apertadas. Os rastreadores tradicionais do Google podem esperar 10 segundos que uma página carregue. Os rastreadores de IA costumam esgotar o tempo após 3 a 5 segundos. No SEO tradicional, a velocidade é um sinal de classificação. No GEO, a velocidade é um limiar. Se o falhares, as citações não acontecem de todo. Com o criador de websites da WEMASY, podes configurar isto diretamente no teu website.
Como sei se o meu TTFB é suficientemente rápido para os rastreadores de IA?
Usa o Google PageSpeed Insights (corre-o como se fosse um rastreador, verificando a versão para computador). Procura um TTFB abaixo de 500 ms. Se for mais alto, tens de investigar o teu alojamento, a base de dados ou o código da aplicação. Outras ferramentas gratuitas de teste de velocidade também mostram o TTFB. Se o teu TTFB estiver de forma consistente acima de 600 ms, contacta o teu fornecedor de alojamento ou pensa em mudar para um alojamento mais rápido.
Devo otimizar os Core Web Vitals se não estou a acompanhar as classificações tradicionais do Google?
Sim. Os Core Web Vitals afetam diretamente a visibilidade na IA. Os estudos mostram que 85% dos sites citados por plataformas de IA passam nos três limiares dos Core Web Vitals. Mesmo que as classificações no Google não importem ao teu negócio, a visibilidade na IA importa. A otimização é a mesma.
Vale a pena mudar para um alojamento mais rápido só por causa dos Core Web Vitals?
Se o teu TTFB atual está acima de 600 ms, sim. A diferença de custo entre um alojamento básico e um alojamento rápido costuma ser de 5 a 15 dólares por mês. O retorno de melhores citações da IA e de uma melhor cobertura dos rastreadores é bastante superior. Um alojamento rápido também melhora a experiência do utilizador e as taxas de conversão, e não só a capacidade de rastreio.
A cache melhora os Core Web Vitals?
A cache é essencial. A cache do navegador diz aos navegadores dos visitantes para guardarem localmente imagens e ficheiros estáticos, para não os terem de descarregar de novo. A cache do servidor guarda páginas totalmente desenhadas em memória, para não terem de ser reconstruídas de raiz. Ambas reduzem o TTFB e o LCP de forma significativa. Implementa cabeçalhos de cache de forma agressiva e usa uma CDN com cache automática.
Otimizar a velocidade para os rastreadores de IA prejudica a experiência do utilizador?
Não. As otimizações para a velocidade dos rastreadores, como servidores mais rápidos, compressão de imagens e adiamento de JavaScript, melhoram a experiência do utilizador em geral. As páginas que carregam mais depressa para os rastreadores carregam mais depressa para as pessoas. A única exceção é se tentares otimizar apenas para os rastreadores, removendo imagens ou cortando conteúdo, o que prejudicaria os utilizadores. Não faças isso. Otimiza a velocidade sem remover valor.