Core Web Vitals s\u00e3o tr\u00eas m\u00e9tricas que o Google usa para avaliar a experi\u00eancia do usu\u00e1rio em uma p\u00e1gina: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) e Cumulative Layout Shift (CLS). Medir e melhorar INP, LCP e CLS exige ferramentas espec\u00edficas, mudan\u00e7as t\u00e9cnicas no servidor e no front-end, e um processo cont\u00ednuo de monitoramento. Neste artigo, voc\u00ea vai aprender exatamente o que cada m\u00e9trica significa, como diagnosticar problemas e quais a\u00e7\u00f5es trazem resultados reais.<\/p>\n
Se voc\u00ea gerencia um site que depende de tr\u00e1fego org\u00e2nico, sabe que o Google prioriza p\u00e1ginas com boa experi\u00eancia. As Core Web Vitals viraram um sinal de ranqueamento em 2021, mas a vers\u00e3o de 2024 incluiu o INP no lugar do First Input Delay. Quem ignora essas m\u00e9tricas perde visibilidade. Quem as otimiza ganha vantagem competitiva. O problema \u00e9 que a maioria dos guias simplifica demais ou complica sem necessidade. A realidade est\u00e1 no meio do caminho: melhorar Core Web Vitals exige trabalho t\u00e9cnico, sim, mas tamb\u00e9m disciplina de processo e escolhas corretas de arquitetura.<\/p>\n
Core Web Vitals \u00e9 um conjunto de tr\u00eas m\u00e9tricas de campo que o Google coleta de usu\u00e1rios reais atrav\u00e9s do Chrome User Experience Report (CrUX). Ao contr\u00e1rio de m\u00e9tricas de laborat\u00f3rio, essas refletem a experi\u00eancia real de quem acessa seu site. Isso as torna mais relevantes para ranqueamento e tamb\u00e9m mais dif\u00edceis de manipular.<\/p>\n
LCP (Largest Contentful Paint) mede quanto tempo leva para o maior elemento vis\u00edvel na janela de visualiza\u00e7\u00e3o ser renderizado. Pode ser uma imagem, um v\u00eddeo, um bloco de texto grande ou um fundo CSS. O INP (Interaction to Next Paint) substituiu o FID em mar\u00e7o de 2024 e avalia a lat\u00eancia de todas as intera\u00e7\u00f5es do usu\u00e1rio, n\u00e3o apenas a primeira. CLS (Cumulative Layout Shift) mede deslocamentos inesperados do layout enquanto a p\u00e1gina carrega.<\/p>\n
A partir de maio de 2024, o Google passou a considerar INP, LCP e CLS juntos como um \u00fanico sinal de experi\u00eancia de p\u00e1gina no ranqueamento m\u00f3vel. Isso significa que uma \u00fanica m\u00e9trica ruim pode comprometer todo o esfor\u00e7o de otimiza\u00e7\u00e3o.<\/p>\n
Medir sem ferramenta confi\u00e1vel \u00e9 chute. E chute n\u00e3o serve para decis\u00e3o t\u00e9cnica. Voc\u00ea precisa de dados de campo e de laborat\u00f3rio.<\/p>\n
Insira sua URL no PageSpeed Insights. Voc\u00ea receber\u00e1 dados de campo (CrUX) e de laborat\u00f3rio (Lighthouse). A se\u00e7\u00e3o “Dados de campo” mostra o percentil p75 da m\u00e9trica para os \u00faltimos 28 dias. Se o LCP estiver acima de 4 segundos ou o CLS acima de 0,25, a p\u00e1gina est\u00e1 no grupo “Ruim”. Abaixo de 2,5 segundos e 0,1, respectivamente, \u00e9 “Bom”.<\/p>\n
Se voc\u00ea gerencia v\u00e1rios sites, o CrUX Dashboard<\/a> no Looker Studio \u00e9 mais \u00fatil. Conecte seu projeto Google Cloud e veja a evolu\u00e7\u00e3o das m\u00e9tricas por origem ao longo do tempo. D\u00e1 para filtrar por dispositivo e at\u00e9 por tipo de conex\u00e3o.<\/p>\n O Google Search Console fornece um relat\u00f3rio espec\u00edfico de Core Web Vitals que agrupa URLs por status (Bom, Precisa de melhorias, Ruim). Ele j\u00e1 usa os dados de campo do CrUX. O valor principal aqui \u00e9 a segmenta\u00e7\u00e3o por problema: voc\u00ea v\u00ea quantas URLs est\u00e3o com LCP alto, CLS ruim ou INP lento. Isso orienta a prioriza\u00e7\u00e3o de corre\u00e7\u00f5es.<\/p>\n Insight pr\u00e1tico:<\/strong> Na nossa experi\u00eancia com dezenas de projetos de SEO t\u00e9cnico, o erro mais comum \u00e9 come\u00e7ar a corrigir sem entender qual m\u00e9trica est\u00e1 pior. Sempre analise o relat\u00f3rio do Search Console primeiro. Se 80% das URLs reprovadas s\u00e3o por CLS, n\u00e3o perca tempo otimizando imagens para LCP. At\u00e9 porque uma \u00fanica corre\u00e7\u00e3o estrutural de layout pode resolver centenas de p\u00e1ginas de uma vez.<\/p><\/blockquote>\n O LCP costuma ser a m\u00e9trica mais dif\u00edcil de levar abaixo de 2,5 segundos porque envolve toda a cadeia de carregamento: servidor, rede, HTML, CSS, fontes, imagens e JavaScript. Cada elo pode atrasar.<\/p>\n O TTFB (Time to First Byte) \u00e9 o tempo que o servidor leva para come\u00e7ar a enviar a resposta. Se seu servidor demora mais de 600 ms, o LCP dificilmente ficar\u00e1 abaixo de 2,5 segundos. Use um CDN, escolha uma hospedagem com servidores pr\u00f3ximos ao seu p\u00fablico e implemente cache de p\u00e1gina inteira. Plugins de cache para WordPress ou Varnish no servidor reduzem o TTFB em 40% a 60%.<\/p>\n O maior elemento vis\u00edvel da p\u00e1gina costuma ser uma imagem. Otimize o formato (WebP ou AVIF), dimensione para o tamanho real de exibi\u00e7\u00e3o e adicione Folhas de estilo CSS e scripts JavaScript que bloqueiam a renderiza\u00e7\u00e3o atrasam o LCP. Diferencie o CSS cr\u00edtico (acima da dobra) e carregue o restante de forma ass\u00edncrona. Use O INP mede a pior lat\u00eancia de intera\u00e7\u00e3o durante toda a visita. Isso inclui cliques em bot\u00f5es, toques em links, digita\u00e7\u00e3o em campos e qualquer outra a\u00e7\u00e3o que dispare um evento no navegador. O objetivo \u00e9 que o navegador responda em menos de 200 ms.<\/p>\n Voc\u00ea n\u00e3o consegue medir INP apenas com Lighthouse. Ele precisa de dados de campo. Use o PageSpeed Insights ou o Chrome DevTools com a grava\u00e7\u00e3o de performance. Olhe para a aba “Timings” e procure por tarefas longas (long tasks) acima de 50 ms. Cada tarefa longa atrasa a resposta do navegador. Se houver uma tarefa de 300 ms, o INP ser\u00e1 pelo menos 300 ms.<\/p>\n A causa mais comum de INP alto \u00e9 JavaScript que roda no thread principal e bloqueia a interface. Frameworks pesados como React, Angular e Vue podem gerar longas tarefas durante a reidrata\u00e7\u00e3o. Solu\u00e7\u00f5es: dividir o c\u00f3digo em chunks menores com code splitting, remover bibliotecas n\u00e3o utilizadas e evitar manipula\u00e7\u00e3o excessiva do DOM durante a intera\u00e7\u00e3o.<\/p>\n Um caso real que encontramos: um site de e-commerce tinha INP de 800 ms porque o carrinho de compras recalculava o frete inteiro a cada clique usando uma biblioteca jQuery desatualizada. Substitu\u00edmos a l\u00f3gica por uma API que retornava apenas o valor do frete e reduzimos o INP para 150 ms. \u00c0s vezes a solu\u00e7\u00e3o est\u00e1 no back-end, n\u00e3o no front-end.<\/p>\n Para tarefas computacionais pesadas (processamento de imagens, c\u00e1lculos, filtros), mova o trabalho para Web Workers. Eles rodam em um thread separado e n\u00e3o bloqueiam a interface. Isso reduz drasticamente as long tasks e melhora o INP.<\/p>\n O CLS mede a estabilidade visual da p\u00e1gina. Um escore abaixo de 0,1 \u00e9 bom. Acima de 0,25 \u00e9 ruim. O problema cl\u00e1ssico \u00e9 o usu\u00e1rio tentar clicar em um bot\u00e3o e o layout mudar no \u00faltimo momento, fazendo o clique ir para outro elemento. Isso gera frustra\u00e7\u00e3o e abandono.<\/p>\n O m\u00e9todo mais eficaz que aplicamos em projetos de grande porte \u00e9 a auditoria de layout shift. Grave a navega\u00e7\u00e3o em c\u00e2mera lenta no DevTools e marque cada mudan\u00e7a inesperada. Depois, corrija uma causa por vez, sempre verificando o escore no laborat\u00f3rio e no campo. Pequenas corre\u00e7\u00f5es acumuladas fazem o CLS cair de 0,3 para 0,05 em poucas semanas.<\/p>\nSearch Console: relat\u00f3rio Core Web Vitals<\/h3>\n
Como melhorar o LCP (Largest Contentful Paint)<\/h2>\n
Otimiza\u00e7\u00e3o do tempo de resposta do servidor (TTFB)<\/h3>\n
Carregamento eficiente de imagens<\/h3>\n
loading=\"lazy\"<\/code> para imagens abaixo da dobra. A imagem que \u00e9 o LCP n\u00e3o deve ter lazy loading. Precarregue ela com <link rel=\"preload\" as=\"image\" href=\"imagem.webp\"><\/code> no head da p\u00e1gina.<\/p>\nRemo\u00e7\u00e3o de render-blocking resources<\/h3>\n
defer<\/code> em scripts que n\u00e3o precisam executar imediatamente. Uma dica pr\u00e1tica: teste uma vers\u00e3o da p\u00e1gina com todo o JavaScript desativado. Se o LCP cair drasticamente, voc\u00ea sabe que o JS \u00e9 o principal vil\u00e3o.<\/p>\nComo melhorar o INP (Interaction to Next Paint)<\/h2>\n
Diagn\u00f3stico do INP: onde est\u00e1 o gargalo<\/h3>\n
Redu\u00e7\u00e3o de JavaScript pesado<\/h3>\n
Considere o uso de Web Workers<\/h3>\n
Como melhorar o CLS (Cumulative Layout Shift)<\/h2>\n
Causas comuns de CLS elevado<\/h3>\n
\n
width<\/code> e height<\/code> para reservar o espa\u00e7o antes do carregamento.<\/li>\nfont-display: optional<\/code> ou swap<\/code> e defina uma fallback que ocupe espa\u00e7o similar.<\/li>\nCorre\u00e7\u00e3o sistem\u00e1tica de CLS<\/h3>\n
Tabela comparativa: ferramentas para medir Core Web Vitals<\/h2>\n