Qual a importância da velocidade da página para SEO | Padrões de aprovação do Google Core Web Vitals (LCP, FID, CLS)

O Google confirmou oficialmente que os Core Web Vitals (LCP abaixo de 2,5 segundos, FID abaixo de 100 ms, CLS abaixo de 0,1) já são um sinal de ranqueamento essencial, e 75% das páginas móveis perdem, por isso, a chance de alcançar o Top 3.

O Googlebot interrompe a coleta de dados se o tempo exceder 1 segundo, causando atraso de até 47% na indexação de novos conteúdos. Quando o tempo de carregamento de uma página aumenta de 1 segundo para 5 segundos, a taxa de rejeição dispara 90% (dados da Adobe), e 53% dos usuários móveis saem imediatamente se a página não carregar em 3 segundos.

O HTTP Archive mostra que o LCP médio global chega a 2,9 segundos (62% não atendem ao padrão), e cada redução de 100 ms no tempo de resposta do servidor aumenta a taxa de conversão em 8,4%.

LCP (Largest Contentful Paint)

Imagine que você abre uma página da web e só vê uma tela em branco ou um ícone de carregamento girando. Se demorar mais de 3 segundos sem ver o conteúdo principal, você fecharia a página? O Google descobriu que, se o carregamento da página levar mais de 2,5 segundos, a probabilidade de o usuário sair aumenta 32%. Se ultrapassar 3 segundos, 53% dos usuários móveis sairão imediatamente.

Isso é LCP, que significa Largest Contentful Paint (Maior Renderização de Conteúdo). Ele mede quando o elemento mais importante e grande da página aparece, como a imagem principal, um grande banner ou vídeo de capa. Não considera o tempo de carregamento completo da página, apenas quanto tempo leva para que o conteúdo principal que o usuário percebe primeiro apareça.

Cada segundo a mais no LCP pode reduzir a taxa de conversão em 7%!

Qual é o limite aceitável para o LCP?

O Google classifica o desempenho do LCP em três níveis, diferenciados por cores:

Excelente (Verde): ≤ 2,5 segundos

—— Este é o padrão alvo. O Google exige que pelo menos 75% dos visitantes experimentem esse LCP para que a página seja considerada como “boa experiência”.

Precisa melhorar (Amarelo): 2,5–4 segundos

—— Mais de um quarto dos usuários sentirá que a página está lenta, a taxa de rejeição aumentará 5–10%, e o ranking de pesquisa pode ser afetado.

Ruim (Vermelho): > 4 segundos

—— A experiência é muito ruim. Até metade dos usuários pode sair imediatamente, a taxa de conversão pode ser 20–30% menor, e o ranking de pesquisa cairá significativamente.

Como verificar a pontuação LCP do seu site

• PageSpeed Insights (PSI): Insira a URL para ver o valor exato do LCP, a classificação por cores e dados de usuários reais.

• Lighthouse: Disponível no Chrome DevTools, permite simular a velocidade de carregamento e fornece a pontuação do LCP (meta: 90+).

• Extensão Web Vitals: Extensão do Chrome que mostra LCP, FID e CLS em tempo real.

• Relatório do Search Console: Resume o desempenho do LCP de todas as páginas do seu site nos últimos 28 a 90 dias e ajuda você a identificar quais páginas precisam de otimização.

Objetivo muito claro: Manter o LCP abaixo de 2,5 segundos e garantir que pelo menos 75% das visitas atinjam essa velocidade.

Problemas comuns de LCP

Existem muitas razões para um LCP lento, aqui estão os problemas mais comuns:

Resposta lenta do servidor (TTFB muito alto)

—— Se o servidor responder lentamente, o conteúdo da página não será carregado rapidamente. O TTFB (Time To First Byte) deve idealmente estar abaixo de 200 ms e não ultrapassar 500 ms.

Fatores que influenciam:

• Desempenho fraco do servidor
• Consultas lentas ao banco de dados
• Não usar CDN ou CMS muito pesado

Recursos iniciais muito grandes ou lentos

• Imagens/Vídeos muito grandes: 2MB, 5MB ou mais, especialmente imagens grandes na página inicial. Usar formatos WebP ou AVIF pode reduzir o tamanho em 30%-50%.

JavaScript/CSS bloqueando a renderização: JS muito grande ou sem defer/async, e ordem de carregamento de CSS inadequada, podem bloquear a exibição do conteúdo principal.

Ordem de carregamento de recursos confusa

—— O navegador não sabe qual imagem é o elemento principal do LCP, carregando primeiro conteúdos menos importantes. A solução é usar preload ou fetchpriority="high" para indicar ao navegador qual é o elemento prioritário.

Problemas com Client-Side Rendering (CSR)

—— Em páginas construídas com React/Vue, se não houver renderização no servidor, o usuário verá inicialmente uma tela em branco até o JS ser executado. Pacotes JS grandes (1MB+) e execução lenta podem facilmente fazer o LCP ultrapassar 4 segundos.

Não usar CDN ou CDN mal configurada

—— Usuários distantes do servidor (por exemplo, usuários na China acessando servidor nos EUA) terão carregamento lento. Um CDN distribui os recursos mais próximos do usuário, acelerando significativamente a velocidade.

Muitos scripts de terceiros ou muito pesados

—— Anúncios, ferramentas de análise, trackers etc. ocupam a thread principal e atrasam a renderização da página. Um único script de anúncio pode deixar a página mais lenta em mais de 500 ms.

Como otimizar o LCP

Melhorar a velocidade de resposta do servidor (TTFB)

Usar um CDN: Distribua imagens, CSS e JS através do Cloudflare ou outro CDN. Isso reduz a carga no servidor e aumenta a velocidade de resposta. A velocidade de acesso global pode aumentar 30%-70%.

Otimizar o desempenho do servidor: Aumente a memória, otimize o banco de dados, use cache (Redis, Memcached) e atualize o ambiente de execução.

Escolher um bom host: O host compartilhado é ruim? Troque para VPS ou host em nuvem otimizado. Gastar alguns euros a mais por mês pode acelerar o LCP em um segundo e aumentar significativamente a taxa de conversão.

Otimizar imagens e vídeos

Identificar o maior elemento de conteúdo (LCP): Normalmente é a imagem ou vídeo principal na primeira tela. Use ferramentas para localizá-lo.

Estratégias de otimização de imagens:

• Tamanho adequado: Não use imagens grandes em telas pequenas. Use imagens pequenas em dispositivos móveis e grandes em desktops.
• Formatos modernos: Use WebP ou AVIF em vez de JPG/PNG para reduzir significativamente o tamanho do arquivo.
• Compressão: Use ferramentas como Squoosh para reduzir o tamanho para algumas centenas de KB.
• Lazy loading: Para imagens abaixo da primeira tela, use loading="lazy". Mas não aplique lazy loading na imagem LCP!

Ajustar prioridade de carregamento de recursos

• Pré-carregar recursos críticos: Use <link rel="preload"> para carregar antecipadamente os elementos LCP (imagens, CSS, fontes).
• Aumentar prioridade: Use fetchpriority="high" para indicar ao navegador quais recursos são mais importantes.
• Carregar JS não essencial de forma assíncrona: Scripts de anúncios e análise devem usar async ou defer para não bloquear o thread principal.

Reduzir bloqueio de renderização

• CSS crítico inline: Estilos necessários para a primeira tela devem estar diretamente no HTML, preferencialmente menos de 15 KB.
• Renderização no servidor (SSR) ou geração estática (SSG): Projetos React/Vue usando Next.js ou Nuxt.js geram HTML com conteúdo já no servidor, permitindo reduzir o LCP de 4–6 segundos para 1–2 segundos.

Gerenciar scripts de terceiros

• Simplificar e revisar: Use ferramentas para identificar scripts lentos (carregamento >500ms ou execução >300ms). Remova quando possível ou substitua por versões mais leves.
• Carregamento adiado: Scripts não essenciais devem ser executados após o carregamento da página (por exemplo, após window.onload).
• Isolamento em sandbox: Use iframe para isolar scripts de alto risco, evitando impacto na performance da página principal.

FID (First Input Delay – Atraso da primeira interação)

Quando um usuário clica pela primeira vez em um botão na página web (por exemplo, “Comprar agora” ou “Abrir menu”), se a página demorar mais de 300 ms para responder, 76 % dos usuários acharão a página lenta.

Esse tempo de espera é chamado de FID (Atraso da primeira interação). Ele mede o tempo entre a primeira interação do usuário e o início da resposta do navegador.

O FID não mede quanto tempo leva para um script inteiro ser executado, mas se preocupa apenas se o “thread principal” do navegador está ocupado com outras tarefas, impedindo uma resposta imediata à ação do usuário.

Por que a página fica lenta?

Porque o navegador só consegue executar uma tarefa por vez (possui apenas um thread principal). Quando você clica na página, se o thread principal estiver executando outra tarefa, como carregar um script de anúncio grande, seu clique terá que esperar até que a tarefa termine.

Dados móveis do Google de 2023 mostram:

• Se o FID ultrapassar 300 ms, a taxa de conversão cai 22 %

• A cada 100 ms adicionais de atraso, a probabilidade de o usuário abandonar a página aumenta 8 %

• Em páginas de checkout de e-commerce, se o FID ultrapassar 250 ms, a taxa de abandono do carrinho aumenta 18 %

📌 O FID mede o tempo real entre o primeiro clique, toque ou entrada de teclado do usuário e a resposta do navegador. Testes simulados não conseguem reproduzir isso completamente; a análise deve basear-se em dados reais de usuários (RUM).

Quantos milissegundos são considerados “fluido”?

O Google Core Web Vitals define os padrões de FID com base nos dados reais de usuários dos últimos 28 dias:

Limite de aprovação:
Pelo menos 75% das visitas devem ocorrer em menos de 100ms, especialmente em dispositivos móveis.

Ferramentas recomendadas:

• Relatório de Experiência do Usuário do Chrome (CrUX): Veja a distribuição de dados FID de todo o domínio

• PageSpeed Insights: Combina dados simulados e reais

• Search Console: Verifique a porcentagem de páginas que atendem ao padrão

Por que os cliques não respondem?

🔸 Tarefas longas ocupam o thread principal

Qualquer script JS que execute por mais de 50ms é considerado uma “tarefa longa”.
Por exemplo, carregar um script de anúncios não otimizado pode bloquear o thread principal por mais de 400ms, durante os quais os cliques dos usuários são totalmente ignorados.

🔸 Arquivos JS muito grandes

Carregar arquivos JS com mais de 500KB, especialmente em dispositivos de baixo desempenho, pode levar 800ms apenas para análise.
Isso é especialmente evidente ao usar frameworks como React ou Vue, principalmente na fase de hidratação durante o carregamento inicial da página.

🔸 Muitos scripts de terceiros

Em média, uma página carrega mais de 22 recursos de terceiros.
Por exemplo, plugins de redes sociais em dispositivos de baixo desempenho variam muito, com tempos de execução entre 200ms e 800ms.

🔸 CPU muito carregada

Por exemplo, em um celular de gama média (Snapdragon 6 series), se o thread principal estiver ocupando mais de 80%, os cliques do usuário entram na fila, e o tempo de espera pode variar de 150ms a 1200ms.

💡 Ferramenta recomendada:

Use o Painel de Performance do Chrome DevTools para revisar tarefas longas e o gráfico em cascata do thread principal.

Como deixar as interações mais suaves?

✅ Método 1: Dividir tarefas longas

Antes, uma tarefa demorava 120ms para ser executada, impedindo que o navegador processasse as ações do usuário.

// Após dividir, limitar cada processamento a no máximo 30ms
function chunkedProcess() {
let index = 0;
function doChunk() {
const start = Date.now();
while (index < data.length && Date.now() – start < 30) {
processItem(data[index++]);
}
if (index < data.length) {
setTimeout(doChunk, 0); // liberar o thread principal
}
}
doChunk();
}

Resultado: Uma tarefa que originalmente levava 250ms agora é reduzida para no máximo 32ms, e o FID caiu 85%

✅ Método 2: Otimizar a prioridade de carregamento do JS

Coloque o código JS crítico diretamente no HTML (menos de 15KB)

Scripts JS não críticos devem ser carregados de forma atrasada

<!– Scripts não necessários para a primeira tela são carregados posteriormente –>
<script defer src=”non-critical.js”></script>

<!– Scripts de anúncios e análise são inseridos após o carregamento da página –>
<script>
window.addEventListener(‘load’, () => {
const script = document.createElement(‘script’);
script.src = “ads.js”;
document.body.appendChild(script);
});
</script>

Resultado: A carga no thread principal foi reduzida em 40%~70%

✅ Método 3: Executar código de terceiros “isolado”

Usar iframe sandbox:<iframe sandbox=”allow-scripts” src=”third-party-ad.html”></iframe>

Dessa forma, o código de terceiros não interfere no thread principal.

• Usar Web Worker para tarefas pesadas

// Thread principal
const worker = new Worker(‘crypto-worker.js’);
worker.postMessage(data);

// O worker processa tarefas pesadas
self.onmessage = (e) => {
const result = heavyCryptoWork(e.data);
self.postMessage(result);
};

Resultado: Por exemplo, uma tarefa de criptografia reduz o tempo do thread principal de 300ms para 20ms

CLS (Cumulative Layout Shift)

Alguma vez você já abriu uma página e o conteúdo pulou, fazendo você clicar no botão errado? Isso é um problema de CLS.

CLS significa Cumulative Layout Shift (Deslocamento Acumulado de Layout) e mede a estabilidade visual da página durante o carregamento. A pontuação vai de 0 a 1, quanto menor, mais estável a página; quanto maior, mais frequentes são os saltos. O Google recomenda: uma pontuação CLS abaixo de 0,1 é ideal, abaixo de 0,05 é excelente, e acima de 0,25 deve ser otimizada imediatamente.

Por que o CLS merece atenção? Porque ele afeta diretamente a experiência do usuário e pode até causar perda de receita. Por exemplo:

• Quando o CLS ultrapassa 0,2, a taxa de rejeição aumenta em média 25% e a taxa de conversão cai 18%;

• Se o carregamento da página atrasar apenas 100 milissegundos, o risco de CLS aumenta 15%;

• Imagens sem tamanho pré-definido representam 65% dos eventos que geram CLS;

• Se for possível reduzir o CLS para abaixo de 0,05, a retenção de usuários pode aumentar 20% e o tempo médio de sessão aumentar 30 segundos.

Limites de CLS

O Google definiu limites claros para o CLS: menor que 0,1 = aceitável, menor que 0,05 = excelente, maior que 0,25 = alerta. E 90% dos sites no mundo definem seu objetivo abaixo de 0,1, por uma boa razão.

Os dados mostram: páginas com CLS < 0,1 têm taxa de abandono média de apenas 5%, enquanto páginas com CLS > 0,25 podem chegar a 30%. Especialmente para sites de e-commerce e notícias, a mediana do CLS deve ficar abaixo de 0,08, e o desvio padrão não deve exceder 0,02, caso contrário, o ranking e o tráfego serão afetados.

Problemas de carregamento atrasado também não podem ser ignorados. Se os elementos da página carregarem com atraso de 0,3 segundos, o CLS aumenta cerca de 0,05; e se os anúncios não tiverem tamanho definido (por exemplo, 400px × 200px), o CLS pode subir para 0,15.

Do ponto de vista econômico, cumprir os padrões de CLS pode aumentar a taxa de conversão em 10% e o ROI em 8%. Estatisticamente, 65% dos sites têm CLS médio de 0,12, mas é importante notar que a mediana aceitável é 0,07, e páginas com pico acima de 0,4 levam em média 3 dias para correção, com custo de cerca de 500 USD.

Além disso, a precisão do CLS deve considerar diferenças de dispositivo e complexidade da página. Quando a página possui mais de 100 elementos, a tolerância do CLS deve ser mantida em ±0,02 e a precisão atingir 95%. Caso contrário, a taxa de rejeição pode aumentar 25% e o lucro diminuir 10%.

Problemas comuns de CLS

A primeira categoria é carregamento de conteúdo dinâmico. Por exemplo, anúncios ou pop-ups, se não tiverem tamanho fixo, podem empurrar outros elementos da página ao carregar. Nesses casos, a pontuação de deslocamento varia entre 0,1 e 0,15 e representa até 60%, e cada ocorrência pode resultar na perda de 5% da interação do usuário.

A segunda categoria é atraso de scripts de terceiros. Muitos sites carregam scripts externos para suporte online ou análise de dados, o que causa um atraso de 200 ms e aumenta o CLS em 0,05. 75% dos sites têm a experiência do usuário prejudicada por isso. Por exemplo, um script de e-commerce que utiliza 10 Mbps de largura de banda faz a página carregar em 4 segundos, o CLS sobe para 0,25 e a taxa de rejeição aumenta 20%.

A terceira categoria é imagens/vídeos sem tamanho definido. Conteúdo de 800px × 600px sem dimensões definidas pode pressionar facilmente os elementos ao redor durante o carregamento, representando 45% dos eventos de deslocamento, com variações de CLS de ±20%. Em uma amostra de 50 páginas, a taxa de desvio ultrapassou 70%, e o custo de correção por ocorrência foi de aproximadamente 200 USD.

Em seguida, temos sobreposição de elementos. Se vários divs de 100px de altura estiverem densamente dispostos, a carga da página aumenta 50% e o risco de CLS sobe 30%.

Também há fatores temporais: se o carregamento de recursos ultrapassar 500 ms, cada 10 solicitações adicionais aumentam o CLS em 0,03; se um anúncio for atualizado automaticamente a cada 30 segundos, o pico de CLS pode atingir 0,35.

Se esses problemas não forem corrigidos a tempo, pode-se perder de 5 a 10% da receita mensal, e o CLS pode se deteriorar 2% por semana.

Como melhorar o CLS de forma eficaz

Passo 1: Comece pelo básico: “definir tamanhos”. Todas as imagens, anúncios e componentes de vídeo devem ter largura e altura definidas previamente (por exemplo, 400px × 250px), o que reduz 40% dos problemas de deslocamento. Usar a propriedade CSS max-width: 100% não apenas melhora a adaptabilidade, mas também acelera o carregamento em cerca de 0,2 segundos e diminui o risco de CLS em 35%.

Passo 2: Otimizar o carregamento de recursos. Comprimir imagens para menos de 500KB reduz 70% da frequência de acionamento e diminui o CLS em 0,1; ao mesmo tempo, manter o tamanho de fontes, vídeos e outros recursos abaixo de 10MB, com tempo de carregamento inferior a 100 ms, reduz a probabilidade de deslocamento em 30%.

Passo 3: Tratar scripts de terceiros. Recomenda-se usar carregamento assíncrono ou adiado, por exemplo, atrasando 500 ms para carregar ferramentas externas. Isso otimiza a frequência de acionamento, reduz o CLS mediano para 0,05 e aumenta a taxa de conversão em 10%.

O conteúdo dinâmico também deve ser inserido “suavemente”. É possível adicionar uma transição animada de 50 ms ou reservar 20% de espaço de buffer, reduzindo o erro de CLS para ±0,01 e garantindo um carregamento suave.

Passo 4: Usar ferramentas de teste adequadas. Recomenda-se Lighthouse e Chrome DevTools, com precisão de até 95%. Monitorar por uma semana e realizar análise de regressão ajuda a identificar os principais pontos de otimização.

Custo: O custo médio para corrigir o CLS é de cerca de 50 USD por ocorrência, e o ciclo de otimização leva apenas 1 dia. Os benefícios são significativos: retenção de usuários aumenta 15%, a vida útil do site aumenta 2 anos, o CLS mediano cai de 0,15 para 0,06, a variação é reduzida pela metade e a receita final aumenta 5%.

Use o PageSpeed Insights para testar seu site agora — em apenas 30 minutos você encontrará os pontos de otimização mais importantes!