Core Web Vitals: LCP, INP e CLS

Módulo 4: Velocidade, dispositivos móveis e https · Tempo de leitura: 13 minutos

Objetivo de aprendizagem: No final desta lição, saberá explicar as três Core Web Vitals e os respetivos valores-limite, distinguir dados de campo de dados de laboratório, ler uma medição do PageSpeed Insights, tratar as causas mais importantes de uma má pontuação e avaliar com honestidade o peso que a velocidade tem nos resultados de pesquisa.

Conceitos chave: Core Web Vitals, LCP (Largest Contentful Paint), INP (Interaction to Next Paint), CLS (Cumulative Layout Shift), percentil 75, dados de campo (CrUX), dados de laboratório (Lighthouse), PageSpeed Insights, relatório Core Web Vitals no Search Console, TTFB, compressão, width e height nas imagens, loading="lazy", experiência de página

A velocidade em três números

"O meu site é rápido?" é uma pergunta vaga. A Google e os criadores do Chrome transformaram-na em três perguntas mensuráveis, as Core Web Vitals:

Alguns pontos que convém compreender bem:

• O LCP mede o momento em que aparece o maior elemento visível. Normalmente é uma fotografia grande no topo (a "hero") ou um bloco de texto grande. No caso do Bloemenatelier Lotte, é a fotografia do arranjo floral na página inicial.
• O INP analisa todos os cliques, toques e teclas premidas durante a visita e indica a reação (quase) mais lenta. Em 12 de março de 2024, o INP substituiu a métrica mais antiga FID (First Input Delay), que só considerava o primeiro clique e apenas o tempo de espera antes do processamento. Se encontrar o FID num artigo antigo, saiba que essa informação está desatualizada.
• O CLS não é um tempo, mas uma pontuação sem unidade. Aumenta quando os elementos se deslocam enquanto o utilizador lê: quer tocar num botão e, nesse instante, surge um banner por cima, pelo que acaba por tocar noutra coisa.

O percentil 75

Uma página "cumpre" as Core Web Vitals quando 75 por cento das visitas obtêm uma boa pontuação nas três métricas, medidas separadamente para dispositivos móveis e computador. A isto chama-se o percentil 75. Significa que não conta o seu próprio computador rápido com fibra ótica, mas sim a experiência da maioria dos visitantes, incluindo quem usa um telemóvel mais antigo com 4G.

Dados de campo e dados de laboratório

Existem dois tipos de medição, e muitas vezes dão números diferentes.

• Os dados de campo vêm de visitantes reais. O Chrome recolhe de forma anónima (junto dos utilizadores que o autorizam) a rapidez das páginas, no Chrome User Experience Report (CrUX). O PageSpeed Insights mostra os dados de campo dos últimos 28 dias. O relatório Core Web Vitals no Search Console utiliza a mesma fonte. Se a sua página tiver poucos visitantes, o PageSpeed Insights mostra os números de todo o site (a "origin"); se também esses forem insuficientes, não há dados de campo.
• Os dados de laboratório vêm de um teste simulado com o Lighthouse: um único carregamento num telemóvel e numa ligação de gama média simulados. O Lighthouse não consegue medir o INP (ninguém clica) e, por isso, apresenta outros números, como o Total Blocking Time, que dão uma indicação do INP.

Para a avaliação contam os dados de campo. Os dados de laboratório são úteis para encontrar causas e para ver de imediato, após uma melhoria, se esta ajuda, sem ter de esperar 28 dias.

Qual é o peso real?

Há muito exagero sobre este tema. Eis o que a própria Google afirma na documentação sobre a experiência de página:

• "Core Web Vitals are used by our ranking systems": ou seja, contam.
• Não existe um "sinal de experiência de página" separado. Segundo a Google, outros aspetos de uma boa experiência de página (https, ausência de pop-ups intrusivos, boa utilização em dispositivos móveis) não ajudam diretamente a subir na classificação, mas tornam o seu site mais agradável.
• "Google Search always seeks to show the most relevant content, even if the page experience is sub-par." Uma página lenta com a melhor resposta pode, portanto, aparecer em primeiro lugar.
• Segundo a Google, procurar uma pontuação perfeita apenas por causa do SEO "pode não ser a melhor utilização do seu tempo".

Conclusão: procure estar na zona verde ou, pelo menos, na laranja, sobretudo porque os visitantes abandonam páginas lentas ou instáveis. Passar de 90 para 100 pontos no Lighthouse pouco acrescenta nos resultados de pesquisa.

As causas que pode resolver por si

Uma primeira resposta lenta (TTFB)

Tudo começa no momento em que chega o primeiro byte do HTML, o Time to First Byte. O TTFB não é, em si, uma Core Web Vital, mas um TTFB lento torna quase impossível um bom LCP. O web.dev indica como valor de referência: bom é 0,8 segundos ou menos, fraco é mais de 1,8 segundos. Causas segundo o web.dev: pouca capacidade de processamento no alojamento, ausência de cache (cada página é gerada de novo, o que é típico no WordPress sem plugin de cache), redirecionamentos (lição 4.1) e um servidor distante sem CDN.

A compressão também conta: o servidor deve enviar o HTML, o CSS e o JavaScript comprimidos com gzip ou Brotli. Pode verificá-lo pelo cabeçalho Content-Encoding: gzip ou br. Quase todos os alojamentos fazem isto por predefinição, mas uma configuração errada ou um servidor antigo pode desativá-lo.

Imagens

As imagens são a causa mais frequente de um mau LCP e de um mau CLS:

1. Demasiado grandes. Uma fotografia com 4.000 píxeis de largura e 5 MB para um espaço de 800 píxeis. Reduza o tamanho antes de carregar e utilize um formato moderno como WebP ou AVIF.

2. Sem largura e altura. Sem width e height, o navegador não sabe quanto espaço a imagem ocupa, e o texto por baixo desloca-se assim que a imagem chega. O web.dev recomenda colocar width e height em cada <img>:

   <img src="bloemstuk.webp" width="800" height="600" alt="Bruidsboeket met witte rozen">

3. Carregar a fotografia principal em diferido. loading="lazy" faz com que uma imagem só seja carregada quando entra no ecrã. É ótimo para fotografias mais abaixo, mas o web.dev é claro: as imagens que já estão visíveis ao abrir a página, e sobretudo a imagem do LCP, não devem ser carregadas em diferido. Caso contrário, o navegador atrasa precisamente a fotografia que determina o seu LCP.

Conteúdo que se desloca e reações lentas

Outras causas de CLS segundo o web.dev: tipos de letra que mudam de tamanho durante o carregamento, anúncios e widgets incorporados que aumentam de tamanho e conteúdo inserido mais tarde por cima do conteúdo existente (como uma barra de cookies que empurra a página para baixo em vez de ficar por cima dela). Um mau INP deve-se quase sempre a demasiado JavaScript: temas pesados, sliders, widgets de chat e rastreadores de terceiros. Analise com espírito crítico cada plugin ou serviço incorporado; aqui, menos é mesmo mais.

Na prática: medir com o PageSpeed Insights

Aceda a pagespeed.web.dev, introduza o endereço da sua página inicial e clique em Analyze (Analisar). Obtém dois separadores (Mobile e Desktop). No topo surge a avaliação das Core Web Vitals com base nos dados de campo, se existirem. Por baixo está o teste do Lighthouse com uma pontuação e uma lista "Diagnostics" com pontos concretos, por exemplo sobre imagens maiores do que o necessário ou uma imagem do LCP carregada em diferido (os nomes exatos mudam com as novas versões do Lighthouse). Comece por Mobile: normalmente os resultados são piores e a Google analisa primeiro a versão móvel (lição 4.2).

Se tiver o seu site no Search Console (módulo 2), consulte também Experiência, Core Web Vitals. Aí vê grupos de páginas semelhantes com o respetivo estado, incluindo páginas que não testou.

Um site criado com o AI Builder define a largura e a altura das imagens cujo tamanho é conhecido, carrega a primeira fotografia da página de imediato e com prioridade (fetchpriority="high") e as restantes em diferido, e, ao publicar, cria uma variante com 800 píxeis de largura das fotografias grandes. No WordPress, o que mais ajuda é um plugin de cache e a redução do tamanho das imagens; o curso de WordPress aprofunda este tema no módulo 6. Noutros criadores de sites e empresas de alojamento funciona de forma semelhante: os botões são diferentes, as causas são as mesmas.

Resumo

• As Core Web Vitals são o LCP (bom até 2,5 s), o INP (bom até 200 ms, em vez do FID desde março de 2024) e o CLS (bom até 0,1), medidos no percentil 75 por tipo de dispositivo.
• Os dados de campo (CrUX, 28 dias) determinam a avaliação; os dados de laboratório (Lighthouse) ajudam a encontrar causas.
• A Google utiliza as Core Web Vitals na classificação, mas a relevância vem primeiro: uma pontuação perfeita não é um objetivo em si.
• Maiores ganhos: resposta rápida do servidor com cache e compressão, imagens leves com width e height, não carregar a fotografia principal em diferido, menos JavaScript de terceiros.

Questionário

Exercício

Exercício A4.3: Resposta rápida e imagens leves. Introduza o endereço de uma página. O programa mede três vezes o tempo até ao primeiro byte (TTFB) a partir do nosso servidor e utiliza o valor do meio, verifica se o HTML é enviado comprimido (gzip, Brotli ou zstd), conta as imagens sem width e height e verifica se a imagem principal no topo não é carregada com loading="lazy". Atenção: trata-se de uma medição a partir de um único local, não de uma medição dos seus visitantes. Não tem site próprio? Utilize www.wikipedia.org.

Exercício D4.3: As suas Core Web Vitals. Execute o PageSpeed Insights na sua página inicial e noutra página importante, primeiro em Mobile. Anote para cada página: se existem dados de campo (da página ou de todo o site), o LCP, o INP e o CLS dos dados de campo, a pontuação do Lighthouse e o elemento que o Lighthouse indica como elemento LCP. Escolha a melhoria que, na sua opinião, traz mais benefícios e explique porquê.

Para saber mais

• web.dev, Web Vitals: https://web.dev/articles/vitals
• web.dev, Largest Contentful Paint (LCP): https://web.dev/articles/lcp
• web.dev, Interaction to Next Paint (INP): https://web.dev/articles/inp
• web.dev, Cumulative Layout Shift (CLS): https://web.dev/articles/cls
• web.dev, Time to First Byte (TTFB): https://web.dev/articles/ttfb
• web.dev, Browser-level image lazy loading: https://web.dev/articles/browser-level-image-lazy-loading
• Google Search Central, Understanding page experience in Google Search results: https://developers.google.com/search/docs/appearance/page-experience
• PageSpeed Insights, About PageSpeed Insights: https://developers.google.com/speed/docs/insights/v5/about
• Ajuda do Search Console, Core Web Vitals report: https://support.google.com/webmasters/answer/9205520
• Como ler o PageSpeed Insights: Core Web Vitals em linguagem simples
• O meu website está lento ou utiliza demasiado CPU: saiba como o tornar mais rápido
• Curso gratuito de WordPress 6.1: O que torna uma site lenta, e como se mede?
• Curso gratuito de WordPress 6.3: Imagens, PHP e outros ganhos de velocidade