Os Core Web Vitals são três métricas definidas pelo Google para medir a qualidade da experiência do utilizador numa página web. Introduzidas em 2020 e integradas no algoritmo de classificação do Google em 2021 através da atualização Page Experience, são hoje um fator de SEO oficial. Para as lojas de e-commerce, compreender e otimizar estes três indicadores — LCP, INP e CLS — tornou-se tão importante quanto o trabalho de conteúdo ou de link building.
O que são os Core Web Vitals?
Antes dos Core Web Vitals, a velocidade de uma página web era medida por métricas técnicas como o Time to First Byte (TTFB) ou o First Contentful Paint (FCP) — indicadores úteis para os programadores, mas que não refletiam com fidelidade o que um utilizador realmente experiencia. O Google quis preencher essa lacuna definindo três métricas centradas na experiência percebida: com que rapidez aparece o conteúdo principal? A página responde rapidamente às interações? O conteúdo desloca-se de forma inesperada?
Estas três perguntas correspondem exatamente aos três Core Web Vitals: LCP para a velocidade de carregamento, INP para a capacidade de resposta e CLS para a estabilidade visual. O Google recolhe estes dados de forma agregada através do Chrome (o Chrome User Experience Report, ou CrUX) e utiliza-os no seu algoritmo para recompensar as páginas que oferecem uma boa experiência de utilizador.
LCP — Largest Contentful Paint: a velocidade de apresentação do conteúdo principal
O LCP (Largest Contentful Paint) mede o tempo decorrido desde o início do carregamento de uma página até ao momento em que o seu maior elemento visível é totalmente renderizado no ecrã. Este elemento pode ser uma imagem, uma tag de vídeo, um bloco de texto ou qualquer outro conteúdo na área visível sem deslocamento (above the fold).
Para as lojas de e-commerce, o LCP é quase sempre determinado pela imagem principal do produto — a fotografia packshot que ocupa grande parte do ecrã no topo da ficha de produto. Esta imagem é geralmente a mais pesada da página e, por isso, a que demora mais tempo a carregar. É por isso que a otimização do LCP no contexto do e-commerce passa prioritariamente pela melhoria da entrega de imagens.
LCP bom
Inferior a 2,5 segundos. O Google considera que a experiência do utilizador é satisfatória.
LCP a melhorar
Entre 2,5 e 4 segundos. A página está na zona laranja — são necessárias melhorias.
LCP fraco
Superior a 4 segundos. O Google penaliza a página nos seus resultados de pesquisa.
As principais causas de um LCP fraco nas lojas de e-commerce são: imagens de produto demasiado pesadas (JPEG não otimizado), um alojamento lento com TTFB elevado, a ausência de CDN que causa latência geográfica e o lazy loading aplicado incorretamente à imagem principal. Este último erro é frequente: o atributo loading="lazy" não deve ser aplicado à imagem above the fold, pois impede o browser de carregar rapidamente o elemento que o Google usa para calcular o LCP.
INP — Interaction to Next Paint: a capacidade de resposta da página
O INP (Interaction to Next Paint) substituiu o FID (First Input Delay) em março de 2024 como Core Web Vital oficial. Enquanto o FID apenas media o atraso de resposta à primeira interação, o INP mede a latência de todas as interações do utilizador durante toda a vida da página — cliques, toques no mobile, entradas de teclado — e retém o valor no percentil 98.
Em termos práticos, o INP mede o tempo entre o momento em que o utilizador interage (por exemplo, clica num botão «Adicionar ao carrinho») e o momento em que o browser apresenta visualmente a resposta a essa interação. Se o JavaScript for pesado e monopolizar a thread principal do browser, o INP será elevado: a página parece «congelada» ou lenta a responder.
INP bom
Inferior a 200 milissegundos. A interação parece instantânea para o utilizador.
INP a melhorar
Entre 200 e 500 milissegundos. O utilizador percebe um ligeiro atraso.
INP fraco
Superior a 500 milissegundos. A interação parece lenta e degradada.
Para as lojas de e-commerce, as principais causas de um INP fraco são: JavaScript de terceiros excessivo (widgets de chat, trackers de analytics, scripts de comparadores de preços), handlers de eventos demasiado pesados e bibliotecas de UI volumosas carregadas de forma síncrona. A otimização do INP passa pela auditoria e redução do JavaScript não essencial e pelo adiamento do carregamento de scripts de terceiros para após a interação do utilizador.
CLS — Cumulative Layout Shift: a estabilidade visual da página
O CLS (Cumulative Layout Shift) mede em que medida os elementos visíveis da página se deslocam de forma inesperada durante o carregamento. Cada vez que um elemento visível se move — um texto que salta porque uma imagem carrega sem dimensões reservadas, um banner publicitário que se insere e empurra o conteúdo para baixo — o CLS aumenta.
Um CLS elevado é particularmente frustrante no mobile: o utilizador está prestes a tocar num link e, no momento em que o dedo toca no ecrã, uma imagem carrega e desloca o conteúdo. Acaba por tocar noutro link — por vezes em «Adicionar ao carrinho» quando queria ler a descrição. É uma experiência degradada que o Google penaliza.
CLS bom
Inferior a 0,1. A página é visualmente estável durante o carregamento.
CLS a melhorar
Entre 0,1 e 0,25. Deslocamentos notáveis afetam a experiência.
CLS fraco
Superior a 0,25. A página é instável e penalizada pelo Google.
A principal causa de CLS elevado nas lojas de e-commerce é a ausência de dimensões explícitas nas imagens (atributos width e height no HTML). Quando o browser analisa o HTML e encontra uma tag img sem dimensões, não consegue reservar o espaço necessário no layout. Quando a imagem carrega e revela as suas dimensões reais, o layout é recalculado e tudo se desloca. A solução é simples: especificar sempre width e height nas tags img, ou utilizar a propriedade CSS aspect-ratio.
Como os Core Web Vitals influenciam o posicionamento no Google
O Google utiliza os Core Web Vitals como sinal de classificação desde junho de 2021. Tecnicamente, fazem parte de um sinal mais amplo chamado «Page Experience», que inclui também a compatibilidade com mobile, a segurança HTTPS e a ausência de conteúdos intersticiais intrusivos. O Google esclareceu que o conteúdo de qualidade continua a ser o sinal dominante, mas que os Core Web Vitals podem fazer a diferença entre duas páginas de qualidade equivalente.
Na prática, o Google avalia os Core Web Vitals através de duas fontes de dados: os dados de campo (field data), recolhidos anonimamente através do Chrome a partir de visitas reais de utilizadores, e os dados de laboratório (lab data), calculados por ferramentas como o Lighthouse em condições controladas. Os dados de campo — agregados no Chrome User Experience Report (CrUX) — são os que alimentam o algoritmo. Uma página precisa de receber tráfego Chrome suficiente para aparecer no CrUX; as páginas com pouco tráfego são avaliadas ao nível do domínio ou do URL raiz.
Mobile-first: os Core Web Vitals são avaliados prioritariamente no mobile
Desafios específicos do e-commerce
As lojas online concentram vários desafios que tornam a otimização dos Core Web Vitals particularmente difícil. Em primeiro lugar, o volume de imagens: uma loja com 1.000 referências e 5 fotos por produto tem de gerir 5.000 imagens, cada uma das quais deve ser otimizada em termos de tamanho, formato e dimensões. Depois, a complexidade das páginas: fichas de produto com galerias, carrosséis, zooms, separadores de descrição, widgets de avaliações de clientes, configuradores de variantes — todos são componentes JavaScript que podem degradar o INP.
- Imagens de produto pesadas sem otimização de formato (JPEG não otimizado vs. WebP/AVIF)
- Carrosséis e galerias com JavaScript de terceiros que bloqueia a thread principal
- Lazy loading mal configurado aplicado à imagem hero (degrada o LCP)
- Imagens sem atributos width/height explícitos nos templates (degrada o CLS)
- Scripts de rastreamento de analytics e remarketing carregados de forma síncrona (degrada o INP)
- Alojamento partilhado lento com TTFB elevado que impacta todos os Core Web Vitals
Como o Lexiik melhora os seus Core Web Vitals
O Lexiik atua principalmente no LCP e no CLS — os dois Core Web Vitals mais diretamente ligados às imagens. Para o LCP, o CDN Cloudflare reduz drasticamente o tempo de entrega da imagem principal do produto, servindo-a a partir de um nó geograficamente próximo do visitante, com cabeçalhos de cache de um ano. Para o CLS, o Lexiik garante que as imagens servidas pelo CDN mantenham as suas dimensões originais, permitindo ao browser reservar o espaço correto antes do carregamento completo.
A conversão automática para WebP e AVIF reduz o tamanho das imagens entre 30 e 50% sem perda visível de qualidade, o que não só acelera o LCP como também melhora o conjunto das métricas de performance percebidas. Em ligações mobile 4G, passar de uma imagem JPEG de 400 KB para uma imagem WebP de 120 KB pode fazer o LCP baixar de 3,5 segundos para menos de 1,5 segundos.
Como verificar as suas pontuações de Core Web Vitals
Várias ferramentas permitem medir e monitorizar os seus Core Web Vitals. O Google Search Console é a ferramenta de referência para os dados de campo reais (CrUX): a secção «Experiência na página» mostra a percentagem de URLs do seu site classificadas como «Boa experiência», «A melhorar» ou «Má experiência», com um detalhe por métrica. É esta ferramenta que reflete o que o Google realmente vê.
- Google Search Console (search.google.com/search-console): dados de campo reais, por URL ou grupo de URLs
- PageSpeed Insights (pagespeed.web.dev): dados de campo + dados de laboratório para um URL específico
- Google Lighthouse (integrado no Chrome DevTools): apenas dados de laboratório, útil para o desenvolvimento
- Chrome DevTools > separador Desempenho: análise detalhada de eventos de renderização e interações
- web.dev/measure: ferramenta do Google para uma análise rápida online