O que são Core Web Vitals?

As Core Web Vitals são um conjunto de métricas específicas e mensuráveis que o Google usa para avaliar a experiência real do usuário em uma página web. Elas focam em três aspectos fundamentais de como uma página é percebida pelos visitantes: a rapidez com que o conteúdo principal aparece, a rapidez com que a página responde à interação e a estabilidade do layout durante o carregamento. O Google usa as Core Web Vitals como um sinal oficial de ranqueamento nos resultados de busca desde junho de 2021, ou seja, essas métricas influenciam diretamente onde seu site WordPress aparece na busca.

As três Core Web Vitals explicadas

Cada Core Web Vital mede uma dimensão diferente da experiência do usuário, e cada uma tem um limite específico que define desempenho "bom", "precisa de melhorias" e "ruim".

Largest Contentful Paint (LCP)

O LCP mede quanto tempo o maior elemento de conteúdo visível leva para ser totalmente renderizado na tela. Normalmente é uma imagem de herói, um grande bloco de texto ou um pôster de vídeo. O cronômetro começa quando o usuário navega para a página pela primeira vez e para quando aquele maior elemento termina de ser pintado.

• Bom: 2,5 segundos ou menos
• Precisa de melhorias: entre 2,5 e 4,0 segundos
• Ruim: mais de 4,0 segundos

O LCP é a métrica que reflete mais diretamente a velocidade de carregamento percebida. Uma página pode ter um Time to First Byte (TTFB) rápido e ainda assim ter um LCP ruim se o maior elemento demorar muito para renderizar devido a imagens grandes, recursos que bloqueiam a renderização ou respostas lentas do servidor para recursos críticos.

Interaction to Next Paint (INP)

O INP substituiu o First Input Delay (FID) como Core Web Vital em março de 2024. Enquanto o FID media apenas o atraso da primeira interação, o INP mede a responsividade de todas as interações ao longo do ciclo de vida da página. Ele rastreia cliques, toques e entradas de teclado, registrando o tempo da interação até quando o navegador efetivamente atualiza a tela. O valor final de INP normalmente é a pior interação observada (com alguns ajustes para outliers).

• Bom: 200 milissegundos ou menos
• Precisa de melhorias: entre 200 e 500 milissegundos
• Ruim: mais de 500 milissegundos

O INP é uma métrica mais difícil de otimizar que o FID porque cobre toda interação, não apenas a primeira. Uma página pode responder rapidamente ao primeiro clique, mas ficar lenta depois quando JavaScript pesado entra em ação.

Cumulative Layout Shift (CLS)

O CLS mede o quanto o conteúdo visível se desloca inesperadamente enquanto a página carrega e durante a sessão do usuário. Toda vez que um elemento muda de posição sem que o usuário inicie a ação (por exemplo, clicando em um botão), esse deslocamento contribui para a pontuação de CLS. A pontuação é calculada multiplicando a fração de impacto (quanto da viewport é afetada) pela fração de distância (o quanto o elemento se moveu).

• Bom: 0,1 ou menos
• Precisa de melhorias: entre 0,1 e 0,25
• Ruim: mais de 0,25

O CLS é particularmente frustrante para os usuários. Imagine tentar clicar em um botão, mas, pouco antes do clique acontecer, um anúncio carrega acima dele e empurra o botão para baixo. Você acaba clicando no anúncio. É exatamente esse tipo de experiência que o CLS mede.

Como o Google usa as Core Web Vitals como sinal de ranqueamento

As Core Web Vitals fazem parte dos sinais de ranqueamento mais amplos de "experiência da página" do Google, que também incluem compatibilidade com mobile, HTTPS e a ausência de interstícios intrusivos. O Google avalia as Core Web Vitals usando dados de usuários reais do Chrome User Experience Report (CrUX). Isso significa que o Google usa dados de campo reais, vindos de visitantes do Chrome reais ao seu site, e não dados de laboratório de um único teste. O impacto no ranqueamento se aplica tanto a resultados de busca em mobile quanto em desktop. Embora a relevância do conteúdo continue sendo o fator de ranqueamento mais forte, as Core Web Vitals podem ser o critério de desempate entre páginas com qualidade de conteúdo semelhante.

Medindo as Core Web Vitals

Há várias ferramentas para medir as Core Web Vitals, e elas se dividem em duas categorias: dados de campo (medições de usuários reais) e dados de laboratório (testes simulados).

• PageSpeed Insights: ferramenta do Google que mostra tanto dados de campo (do CrUX) quanto dados de laboratório (do Lighthouse). A seção de dados de campo mostra as pontuações reais de Core Web Vitals com base em usuários reais nos últimos 28 dias. Essa é a seção mais importante porque reflete o que o Google usa para o ranqueamento.
• Google Search Console: o relatório de Core Web Vitals agrupa suas URLs por status (bom, precisa de melhorias, ruim) com base em dados de usuários reais. Ajuda você a identificar padrões em todo o site, em vez de checar páginas individuais.
• Chrome User Experience Report (CrUX): o conjunto de dados bruto que alimenta o PageSpeed Insights e o Search Console. Você pode consultá-lo diretamente pela API do CrUX ou pelo BigQuery para análises personalizadas.
• Lighthouse: uma ferramenta de teste em laboratório embutida no DevTools do Chrome. Ela simula carregamentos de página em uma conexão limitada e relata LCP e CLS (o INP requer interação real do usuário e não pode ser medido de forma confiável em laboratório). Útil para depuração, mas não reflete a experiência real do usuário.
• Extensão Web Vitals do Chrome: uma extensão de navegador que mostra as pontuações das Core Web Vitals em tempo real enquanto você navega, facilitando identificar problemas durante desenvolvimento e testes.

Dados de usuários reais vs. dados de laboratório

Essa distinção importa mais do que muitos donos de site percebem. Os dados de laboratório (do Lighthouse ou ferramentas semelhantes) simulam um carregamento de página sob condições controladas: um dispositivo, velocidade de rede e localização específicos. São úteis para depurar e identificar problemas técnicos, mas não refletem o que os visitantes reais experimentam. Os dados de usuários reais (dados de campo) vêm de visitantes do Chrome reais ao seu site. Capturam toda a gama de dispositivos, velocidades de rede e localizações geográficas que seus visitantes usam. O algoritmo de ranqueamento do Google usa dados de campo, não dados de laboratório. Uma página pode pontuar 95 no Lighthouse e ainda ter Core Web Vitals ruins em campo porque usuários reais em dispositivos mais lentos têm uma experiência diferente.

Problemas comuns de LCP em sites WordPress

Sites WordPress frequentemente sofrem com LCP devido a vários problemas comuns:

• Imagens de herói grandes e não otimizadas: uma imagem de herói de 3 MB demora muito mais para baixar e renderizar do que uma versão WebP devidamente comprimida de 200 KB. Sempre comprima imagens, use formatos modernos (WebP ou AVIF) e entregue imagens com tamanho adequado para a tela do visitante.
• CSS e JavaScript que bloqueiam a renderização: quando o navegador encontra arquivos CSS ou JavaScript no <head>, precisa baixá-los e interpretá-los antes de renderizar qualquer conteúdo. Folhas de estilo demais ou grandes demais atrasam significativamente o LCP. Inclua CSS crítico inline e adie folhas de estilo não essenciais para resolver isso.
• Resposta lenta do servidor (TTFB): se seu servidor de hospedagem leva 2 segundos só para gerar o HTML, seu LCP não tem como ficar abaixo de 2,5 segundos. Atualize a hospedagem, habilite cache do lado do servidor e use uma CDN para reduzir o TTFB.
• Plugins demais: cada plugin potencialmente adiciona CSS e JavaScript a toda página. Sites com mais de 30 plugins ativos costumam ter dezenas de recursos que bloqueiam a renderização disputando largura de banda.
• Atributo fetchpriority ausente: o elemento de LCP deveria ter fetchpriority="high" para sinalizar ao navegador que o baixe primeiro. Sem ele, o navegador pode priorizar outros recursos no lugar do mais importante.

Problemas comuns de INP em sites WordPress

Os problemas de INP no WordPress geralmente remontam à execução de JavaScript:

• JavaScript pesado de plugins: sliders, popups, ferramentas de analytics, widgets de chat e plugins de compartilhamento social adicionam JavaScript que roda na thread principal. Quando um usuário clica em algo, o navegador pode precisar terminar de executar outros scripts antes de responder.
• Scripts de terceiros: Google Analytics, Facebook Pixel, scripts de publicidade e ferramentas de chat ao vivo frequentemente executam tarefas longas que bloqueiam a thread principal. Carregar esses scripts com async ou defer ajuda, mas eles ainda consomem tempo de processamento.
• DOM excessivamente grande: páginas com milhares de elementos DOM (comuns em construtores de página como Elementor ou Divi) levam mais tempo para o navegador atualizar quando há interações. Um clique que muda uma classe CSS pode disparar recálculos de estilo caros em milhares de elementos.
• Tarefas longas na thread principal: qualquer tarefa de JavaScript que rode mais de 50 milissegundos é considerada uma "tarefa longa" que bloqueia a responsividade. Quebrar tarefas grandes em pedaços menores usando padrões com requestAnimationFrame ou setTimeout pode ajudar.

Problemas comuns de CLS em sites WordPress

Deslocamentos de layout em sites WordPress são tipicamente causados por:

• Imagens sem atributos width e height: quando uma imagem é carregada sem dimensões explícitas, o navegador não sabe quanto espaço reservar. O conteúdo abaixo se desloca quando a imagem finalmente é renderizada. Sempre defina os atributos width e height nas imagens (o WordPress faz isso automaticamente para imagens adicionadas pela biblioteca de mídia).
• Carregamento de fontes web: fontes personalizadas que carregam após a renderização inicial podem fazer o texto refluir quando a fonte é trocada. Use font-display: swap combinado com preload de fontes para minimizar esse efeito, ou considere usar font-display: optional para fontes não críticas.
• Injeção de anúncios: anúncios que carregam dinamicamente empurram o conteúdo. Reserve espaço para slots de anúncio usando contêineres de tamanho fixo, mesmo antes de o anúncio carregar.
• Conteúdo injetado dinamicamente: banners de consentimento de cookies, popups de newsletter e barras de notificação que aparecem após o carregamento da página podem deslocar o conteúdo se forem inseridos no fluxo do documento em vez de sobrepostos.
• Embeds e iframes sem dimensões: vídeos do YouTube, tweets e outros conteúdos incorporados sem dimensões explícitas causam deslocamentos quando carregam.

Melhorando as Core Web Vitals para WordPress

Eis uma abordagem prática para melhorar cada métrica em um site WordPress:

• Para o LCP: otimize e comprima imagens (use WebP/AVIF), use uma CDN, habilite cache do lado do servidor, inclua CSS crítico inline, adie JavaScript não essencial e adicione fetchpriority="high" à imagem de LCP. Remova plugins não usados que acrescentam recursos que bloqueiam a renderização.
• Para o INP: audite e remova JavaScript desnecessário, adie scripts de terceiros, reduza o tamanho do DOM (considere construtores de página mais leves ou blocos nativos do WordPress) e quebre tarefas longas de JavaScript em pedaços menores. Use a aba Performance do DevTools do Chrome para identificar quais scripts bloqueiam a thread principal.
• Para o CLS: defina dimensões explícitas em todas as imagens, vídeos e iframes. Faça preload de fontes e use font-display: swap. Reserve espaço para anúncios e conteúdo dinâmico. Evite inserir conteúdo acima de conteúdo existente após o carregamento da página.

O que o InspectWP verifica

O InspectWP analisa múltiplos fatores que influenciam diretamente as pontuações de Core Web Vitals. Verifica a compressão HTTP (que afeta o LCP), uso de HTTP/2 (que permite carregamento paralelo de recursos), o número de arquivos JavaScript e CSS (que pode bloquear a renderização e afetar tanto LCP quanto INP), oportunidades de otimização de imagens, tamanho do documento HTML e outros indicadores relacionados a desempenho. Isso lhe dá um quadro claro do que precisa ser melhorado para alcançar melhores pontuações de Core Web Vitals.