O que são os Core Web Vitals? LCP, INP e CLS explicados (2026)
Tudo o que precisa de saber sobre os Core Web Vitals: métricas, limites, ferramentas de medição e como passar.
Partilhar
Os Core Web Vitals são três métricas da Google, medidas em visitantes reais: Largest Contentful Paint (LCP) para o carregamento, bom abaixo de 2,5 segundos; Interaction to Next Paint (INP) para a capacidade de resposta, bom abaixo de 200 milissegundos; e Cumulative Layout Shift (CLS) para a estabilidade visual, bom abaixo de 0,1. A Google avalia-os no percentil 75 das visitas.
Os Core Web Vitals em resumo
A Google usa os Core Web Vitals para avaliar como as páginas carregam, respondem e se mantêm estáveis. São três: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) e Cumulative Layout Shift (CLS).
O que são os Core Web Vitals?
Cada Core Web Vital abrange um momento da visita. Os dados vêm de utilizadores reais do Chrome:
- Carregamento (LCP): quanto tempo demora até o conteúdo principal estar no ecrã
- Interatividade (INP): quanto tempo a página demora a reagir a um clique, toque ou pressão de tecla
- Estabilidade (CLS): quanto é que o conteúdo se move enquanto carrega
O conjunto vai mudando. Em março de 2024, o INP substituiu o First Input Delay (FID). O FID media apenas a espera até a primeira interação ser processada. O INP mede todas as interações do início ao fim, e muitos mais sites falham.
Quando é que passa nos Core Web Vitals?
A Google classifica cada métrica como Bom, Precisa de melhorias ou Fraco. O site passa quando pelo menos 75% das visitas à página no CrUX têm um bom LCP, um bom INP e um bom CLS. A Google avalia primeiro o URL. Quando esse URL tem pouco tráfego, recorre a um grupo de URL semelhantes ou a toda a origem. O PageSpeed Insights mostra o resultado acima de tudo o resto na página: "Core Web Vitals Assessment: Passed" ou "Failed".
| Bom | Precisa de melhorias | Fraco | |
|---|---|---|---|
| Largest Contentful Paint | < 2500ms | 2500ms - 4000ms | > 4000ms |
| Interaction to Next Paint | < 200ms | 200ms - 500ms | > 500ms |
| Cumulative Layout Shift | < 0,1 | 0,1 - 0,25 | > 0,25 |
Porquê o percentil 75?
A mediana só mostra a metade mais rápida dos visitantes. Um percentil mais rigoroso faria com que algumas visitas a partir de um comboio com um traço de rede chumbassem a página inteira. O p75 fica a meio caminho: três em cada quatro visitas têm de ser boas.
O portátil no Wi-Fi do escritório diz muito pouco. As visitas que decidem o p75 são os telemóveis mais lentos em redes móveis.
As três métricas dos Core Web Vitals
Largest Contentful Paint (LCP): carregamento
O Largest Contentful Paint mede o carregamento: o tempo desde o início da navegação até o maior elemento na viewport ser desenhado no ecrã.
Esse elemento tem de ter conteúdo: uma imagem (imagens de fundo e posters de vídeo também contam) ou um bloco de texto. Na maioria das páginas, o elemento LCP é a imagem hero ou o título principal.
Um resultado bom fica abaixo de 2,5 segundos. No lançamento do CrUX de agosto de 2026, 68,1% das origens conseguiram essa marca — o valor mais baixo dos três.
O LCP acompanha o que o visitante vê. Quando o maior elemento surge no ecrã, a maioria das pessoas pensa que a página terminou de carregar, mesmo que ainda haja scripts a carregar. A métrica foi criada para responder a uma pergunta: 'Quando é que o conteúdo de uma página fica visível?'.
Quando o elemento LCP demora a surgir, o motivo costuma ser banal. loading="lazy" na imagem hero. Uma imagem hero definida como background em CSS, pelo que o browser só a encontra depois de descarregar a folha de estilos. Um script de slider que tem de correr antes de o primeiro slide aparecer. Corrija primeiro a descoberta; depois, faça o preload da imagem se o HTML ainda a ocultar, aplique fetchpriority="high" e reduza o tamanho do ficheiro. O guia do Largest Contentful Paint aborda as quatro fases do LCP.
Interaction to Next Paint (INP): interatividade
O Interaction to Next Paint mede a interatividade: quanto tempo demora até o ecrã atualizar após um visitante clicar, tocar ou premir uma tecla. Scroll e hover não contam.
Cada interação é cronometrada desde a ação do utilizador, passando pelo JavaScript acionado, até ao frame seguinte no ecrã. A página assume o tempo da sua interação mais lenta. Em páginas com muitas interações, a Google ignora um outlier por cada 50 interações, o que equivale sensivelmente ao percentil 98.
Uma execução normal do Lighthouse não consegue medir o INP. Carrega a página e nunca clica em nada. O valor de laboratório mais próximo é o Total Blocking Time. O INP costuma ser muito mais baixo do que o TBT, mas quando o TBT desce, o INP tende a acompanhar.
Muitas vezes, o próprio click handler é rápido. O problema é a main thread estar ocupada com outra coisa quando o clique surge: um gestor de tags, um widget de chat ou uma framework ainda a hidratar. A maior parte desse JavaScript pode ser adiada ou agendada. 85,3% das origens tinham um bom INP em agosto de 2026, uma quebra face aos 87,2% em março (notas de lançamento do CrUX). É o único Core Web Vital que piorou no último ano. O guia do Interaction to Next Paint mostra como encontrar as interações lentas.
Cumulative Layout Shift (CLS): estabilidade visual
O Cumulative Layout Shift mede a estabilidade visual: quanto conteúdo visível se move sem que o visitante o tenha solicitado. Tenta tocar num link e a página salta.
Cada deslocamento recebe uma pontuação: a fração de impacto (quanto da viewport é afetada) multiplicada pela fração de distância (a distância percorrida pelo conteúdo, em relação à viewport). Os deslocamentos que ocorrem em sucessão rápida são somados numa janela de sessão. O CLS da página é a sua pior janela de sessão.
As causas habituais: imagens sem width e height; anúncios, barras de cookies e embeds que empurram o conteúdo para baixo quando surgem; e uma web font mais larga ou mais alta do que o respetivo fallback. Para as fontes, aloje-as no próprio servidor e escolha a definição correta de font-display. O CLS é a métrica em que a maioria dos sites tem sucesso: 81,5% das origens tinham um bom CLS em agosto de 2026. Mais detalhes no guia do Cumulative Layout Shift.
Porque é que os Core Web Vitals são importantes?
- Os visitantes vão embora. Um botão que não faz nada durante meio segundo recebe dois cliques e é abandonado. A Google reuniu estudos de caso de sites que corrigiram os Core Web Vitals e obtiveram taxas de rejeição mais baixas e mais conversões.
- Rankings. Os Core Web Vitals são um fator de posicionamento da Google. Um fator pequeno. Quando duas páginas são igualmente boas, a mais rápida leva vantagem.
- Telemóvel. A maior parte do tráfego vem provavelmente de um telemóvel, e é aí que as páginas falham. O Web Almanac de 2025 (a edição mais recente) revelou que 48% das páginas móveis passam, contra 56% em computador.
- Google Ads. A experiência da página de destino faz parte do Quality Score. Uma página de destino lenta puxa o índice para baixo e cada clique fica mais caro.
A Google também documenta com rigor como cada métrica é medida, até ao código do browser. Para um fator de posicionamento, isso quase nunca acontece.
Estudo de caso da Vodafone
A Vodafone Itália melhorou o seu Largest Contentful Paint em 31% e obteve mais 8% de vendas, mais 15% de leads e uma melhoria de 11% na taxa de carrinho por visita (fonte: estudo de caso no web.dev).
Field data vs. lab data
A field data (também chamada Real User Monitoring ou dados de RUM) vem dos visitantes reais, nos seus próprios dispositivos e redes. O dataset do CrUX da Google é composto por field data de utilizadores do Chrome que aceitaram participar. Os Core Web Vitals baseiam-se exclusivamente em field data.
A lab data vem de um teste num dispositivo simulado numa configuração fixa. O Lighthouse e o WebPageTest produzem lab data. Um teste de laboratório dá praticamente o mesmo resultado a cada execução, o que o torna ótimo para debugging. Não mostra o que os visitantes realmente recebem.
O Lighthouse dá 100, então porque é que falho?
Porque a Google posiciona com base no CrUX, e o Lighthouse testa uma única visita simulada. Os visitantes usam telemóveis Android baratos e ligações Wi-Fi fracas de hotéis, e clicam em elementos em que o Lighthouse nunca toca. O INP nem sequer existe numa execução do Lighthouse.
O CrUX indica se passa ou se falha por grupo de URL. Para descobrir que página, dispositivo e elemento estão por trás da falha, uso Real User Monitoring: o CoreDash, que criei exatamente para isso. Divide os dados por dispositivo, país e template de página, e aponta para o elemento LCP ou para a interação que está lenta.
Como medir os Core Web Vitals
Comparativo de ferramentas de medição
| Ferramenta | Tipo de dados | Mede os CWV? | Ideal para |
|---|---|---|---|
| CrUX (Chrome User Experience Report) | Field | Sim (oficial) | Os números que a Google usa, por origem ou URL |
| PageSpeed Insights | Field + Lab | Sim (via CrUX) | Verificação rápida: dados do CrUX mais uma execução do Lighthouse |
| Lighthouse | Apenas lab | Não | Encontrar problemas numa única página |
| Chrome DevTools | Apenas lab | Não | Analisar um trace, o waterfall, o elemento LCP |
| CoreDash (RUM) | Field | Sim | Dados do próprio dia, por página, dispositivo e elemento |
| Google Search Console | Field (CrUX) | Sim | Que grupos de URL passam e quais falham |
Dados do CrUX
O dataset do CrUX guarda os Core Web Vitals de todos os sites com tráfego suficiente no Chrome. É o conjunto de dados oficial do programa Web Vitals. Pode aceder-lhe de várias formas:
- O CrUX Vis mostra a pontuação de uma origem ou URL ao longo dos últimos meses. Veio substituir o antigo CrUX Dashboard no Looker Studio, que a Google descontinuou no final de 2025.
- O CrUX no BigQuery disponibiliza os dados ao nível da origem de cada site no CrUX, com histogramas completos por métrica, atualizados mensalmente. Ideal para comparar um site com a concorrência.
- A API do CrUX fornece os dados por página ou origem, filtrados por tipo de dispositivo e métrica, para quando quer integrar os números nas suas próprias ferramentas.
- O PageSpeed Insights mostra os dados do CrUX de um URL acima de um relatório do Lighthouse. Abre no separador móvel. Mantenha-se aí: o separador de computador está quase sempre verde e leva as pessoas a pensar que passam.
Monitorização com RUM
Os dados de RUM vêm de um pequeno script no próprio site que mede cada visita. Mede os mesmos Core Web Vitals que o CrUX, mas com os pormenores que o CrUX omite. O CrUX é anonimizado, fica-se pelo nível do URL e analisa sempre os últimos 28 dias. O RUM mostra os dados de ontem, por página, dispositivo, país e browser, e revela que elemento causou o LCP lento ou o layout shift. É por isso que a maioria dos profissionais que otimizam Core Web Vitals usa RUM a par do CrUX.
Lighthouse
O Lighthouse não mede os Core Web Vitals. Carrega uma página, uma única vez, num telemóvel simulado com uma ligação limitada. Começa com a cache vazia, nunca navega para uma segunda página e nunca faz cliques.
Continua a ser a forma mais rápida de ver o que está a bloquear a renderização, qual é a imagem do elemento LCP e que scripts mantêm a main thread ocupada. Mas ignore metade da lista. Minificar CSS poupa uns míseros kilobytes e nenhum visitante vai notar.
Execute-o no PageSpeed Insights, nas Chrome DevTools ou através da ferramenta de linha de comandos do Lighthouse.
Quantos sites passam?
A equipa do Chrome publica os números do CrUX todos os meses, na segunda terça-feira, nas notas de lançamento do CrUX. Eis a percentagem de origens com uma boa pontuação, juntando todos os dispositivos:
| Métrica | Agosto de 2025 | Agosto de 2026 | Notas |
|---|---|---|---|
| LCP | 66,7% | 68,1% | O mais baixo dos três; por isso, na maioria dos sites, o LCP dita a aprovação |
| INP | 85,7% | 85,3% | A descer todos os meses desde março; a Google ainda não tem justificação |
| CLS | 80,1% | 81,5% | O melhor dos três |
| As três | 53,5% | 55,6% | Num total de 18,3 milhões de origens |
Compare o mesmo mês de ano para ano. Dezembro oscila todos os anos (a equipa do Chrome nota isso desde o lançamento do CrUX), pelo que um mês mau diz pouco. Para o TTFB e o FCP, que não constam das notas de lançamento, consulte o guia do Time to First Byte e o guia do First Contentful Paint.
Como melhorar os Core Web Vitals
Por onde começo: o p75 por métrica em dispositivos móveis, depois o grupo de URL assinalado pelo Search Console e, por fim, a tendência. Uma quebra repentina costuma apontar para um deploy. Uma descida gradual resulta de scripts de terceiros a acumular-se, uma tag de cada vez.
Cada release pode voltar a estragar algo, por isso continue a acompanhar a field data depois de a correção entrar em produção. Além disso, as métricas afetam-se mutuamente. O font-display: swap coloca o texto no ecrã mais cedo, o que pode ajudar o LCP; mas quando a web font tem um tamanho diferente do fallback, a substituição provoca um layout shift. Um guia por métrica:
- Melhorar o Largest Contentful Paint
- Melhorar o Interaction to Next Paint
- Melhorar o Cumulative Layout Shift
Duas métricas de diagnóstico atrasam o LCP:
- Time to First Byte (TTFB): o browser não pode começar a construir a página antes de o HTML chegar. Com um TTFB lento, conseguir um bom LCP é quase impossível. Fazer cache do HTML na CDN costuma ser a vitória mais rápida.
- First Contentful Paint (FCP): a primeira renderização de qualquer conteúdo. Até lá, o visitante fica a olhar para um ecrã em branco.
Para uma lista passo a passo, use a Checklist dos Core Web Vitals.
Core Web Vitals no Search Console
A Google costumava agrupar os Core Web Vitals com HTTPS, compatibilidade com dispositivos móveis e anúncios intersticiais invasivos sob o conceito de "experiência de página". A Google removeu o relatório de Experiência de Página do Search Console em novembro de 2024. O relatório dos Core Web Vitals continua lá, na secção 'Experiência'.
Esse relatório agrupa os seus URL por template e indica que grupos passam. Cobre os últimos 28 dias; por isso, duas semanas após a entrada de uma correção em produção, metade do que mostra ainda reflete o site antigo.
Precisa de um site mais rápido?
Sou o Arjen e há 17 anos que corrijo sites lentos. Se tem problemas que não consegue resolver sozinho, envie-me o seu URL e falamos.
Envie-me o seu URLPorque é que o nosso fix não está a funcionar?
Por vezes a CDN ainda serve o HTML antigo, ou o fix foi feito no template de desktop e o mobile usa outro. Envie-me o seu URL e o problema, e respondo com alguns horários. Primeiro analiso os seus field data, depois dedicamos uma hora ao seu site, e no prazo de um dia tem as minhas notas por escrito. 350 € sem IVA.
Envie-me o seu URLSem programador para fazer o fix? Faço eu o trabalho, numa cópia do seu site.
Perguntas frequentes sobre os Core Web Vitals
Aprender sobre os Core Web Vitals
O que deve aprender para se tornar especialista em Core Web Vitals?
Alguns problemas nos Core Web Vitals resolvem-se em cinco minutos. Outros exigem anos de experiência. Precisa de quatro coisas.
Primeiro, como funcionam os browsers. Analise um trace no painel Performance até conseguir distinguir parsing, style, layout e paint sem olhar para os rótulos.
Segundo, JavaScript. Passo grande parte do meu tempo a explicar a developers por que razão o código deles é lento. Código lento prejudica o INP e, normalmente, também o LCP e o FCP.
Terceiro, HTML e CSS. Há quase sempre uma forma rápida e uma forma lenta de construir o mesmo componente.
Quarto, redes e servidores: caching headers, compressão, HTTP/2 e HTTP/3. As grandes empresas têm bons developers e vão fazer perguntas sobre estes quatro temas.
Melhorar os Core Web Vitals
Os plugins de Core Web Vitals funcionam?
Às vezes. Há muitos plugins que prometem melhorar os Core Web Vitals, como o WP Rocket. Podia falar sobre eles durante horas, por isso vou ser breve.
Depende do problema. Imagens sem lazy loading, scripts que não foram adiados: um plugin resolve isso. Já um slider que reconstrói o layout com JavaScript ou um DOM com 5000 elementos mantêm-se como estão. E o truque de "adiar todo o JavaScript até à primeira interação" transfere esse trabalho todo para o primeiro clique — precisamente o que o INP mede.
Um plugin faz o que um bom developer faz em poucas horas. No fim, os problemas difíceis continuam lá.
Devo focar-me no telemóvel ou no computador?
No telemóvel. Os telemóveis têm menos largura de banda, menos memória e um processador mais lento do que a média dos computadores. Se passar em dispositivos móveis, normalmente também passa em computador.
Há exceções. A viewport do computador é maior, pelo que o elemento LCP pode diferir: no telemóvel é muitas vezes um título; no computador, uma imagem mais abaixo. O ecrã de computador também tem mais elementos que podem sofrer deslocamento, o que pode agravar o CLS.
Medição: CrUX, RUM e dados sintéticos
Se não houver dados ao nível do URL, como é que a Google avalia os Core Web Vitals?
A Google usa primeiro os dados do CrUX para o URL. Se esse URL tiver pouco tráfego, a Google pode recorrer a um grupo de URL semelhantes (o Search Console mostra esses grupos). Sem dados de grupo, utiliza os dados de toda a origem.
Os dados dos Core Web Vitals são em tempo real?
Não, mas também não têm 28 dias de atraso. Os dados do CrUX têm cerca de dois dias. O que vê é o p75 dos últimos 28 dias; por isso, uma correção que entrou hoje em produção representará amanhã um dia em 28. Num site que estava no limiar, o p75 pode mexer no espaço de uma ou duas semanas. Num site que era lento em todo o lado, espere as quatro semanas completas. Mais sobre a janela de 28 dias.
Porque é que não há dados no Search Console ou noutra ferramenta do CrUX?
A Google não tem visitas suficientes de utilizadores do Chrome no seu site. O CrUX só apresenta páginas e origens acima de um limite mínimo de tráfego. Sites novos, sites pequenos e páginas com autenticação muitas vezes não têm dados nenhuns.
As pontuações do Lighthouse afetam os Core Web Vitals?
Não. A Google usa field data do CrUX, e a pontuação do Lighthouse não faz parte dela. Use o Lighthouse para descobrir o que abranda a página. Os Core Web Vitals só mudam quando os visitantes reais recebem uma página mais rápida.
Dúvidas comuns sobre os Core Web Vitals
Quais são os 3 Core Web Vitals?
Largest Contentful Paint (LCP) para o carregamento, bom abaixo de 2,5 segundos; Interaction to Next Paint (INP) para a capacidade de resposta, bom abaixo de 200 milissegundos; e Cumulative Layout Shift (CLS) para a estabilidade visual, bom abaixo de 0,1. Uma página passa quando os três são bons no percentil 75.
Existe uma pontuação dos Core Web Vitals?
Não. Não existe um número único. Cada métrica é classificada como bom, precisa de melhorias ou fraco no p75, e um URL passa quando todas as três são boas. A pontuação de 0 a 100 no PageSpeed Insights é a pontuação de desempenho do Lighthouse. Trata-se de uma pontuação de laboratório, e a Google não a usa para posicionamento.
Os Core Web Vitals são um fator de posicionamento?
Sim, desde junho de 2021. Um fator pequeno. Uma página lenta com a melhor resposta continua a posicionar-se à frente de uma página rápida com uma resposta fraca. Quando duas páginas são praticamente iguais, a que passa leva vantagem.
Qual é a diferença entre field data e lab data?
A field data vem de visitantes reais, medida pelos seus próprios browsers nos seus próprios dispositivos e redes. A lab data vem de um teste num dispositivo simulado, como o Lighthouse ou o WebPageTest. A lab data é reproduzível e ótima para debugging. A Google apenas usa field data para os Core Web Vitals; por isso, uma pontuação perfeita no Lighthouse não significa aprovação, e uma pontuação má não significa que vá chumbar.