← Voltar ao blog

Core Web Vitals no Magento 2: como corrigir LCP, INP e CLS

Rodrigo Biazzi

Core Web Vitals são as três métricas de experiência de página que o Google mede a partir de usuários reais do Chrome: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) e Cumulative Layout Shift (CLS). Lojas Magento baseadas em Luma costumam sofrer com as três no mobile, por motivos bem previsíveis quando você sabe onde olhar.

Este artigo passa por cada métrica, pelas causas mais comuns no Magento 2.4.8 e pelas correções que eu verifico primeiro. O foco é Luma, já que lojas em Hyvä partem de uma base muito melhor.

Dados de laboratório x dados de campo

Antes de mudar qualquer coisa, deixe claro de quais números você está falando.

  • Dados de campo vêm do Chrome User Experience Report. É o que o Google usa, aparece no topo do PageSpeed Insights e no relatório de Core Web Vitals do Search Console, e é medido no percentil 75 das visitas reais em 28 dias.
  • Dados de laboratório vêm de uma única execução do Lighthouse em um dispositivo simulado. Servem para depurar, mas não são a nota que conta.

Os limites para um bom resultado são LCP até 2,5 segundos, INP até 200 milissegundos e CLS até 0,1. Como os dados de campo atrasam quatro semanas, uma correção que você publica hoje aparece aos poucos. Não julgue uma mudança pelo relatório do dia seguinte.

Meça por tipo de página. Do ponto de vista de performance, uma loja Magento são na verdade quatro ou cinco sites diferentes: home, categoria, produto, carrinho e checkout. O Search Console agrupa URLs com problemas parecidos, o que normalmente coincide com esses tipos de página.

LCP: Largest Contentful Paint

O LCP mede quando o maior elemento visível termina de renderizar, normalmente o banner principal da home, as primeiras imagens de produto na página de categoria e a imagem principal na página de produto. No Magento, o LCP é a soma de quatro partes, e você precisa saber qual delas domina.

1. Tempo de resposta do servidor

Nada renderiza até o HTML chegar. Se o time to first byte está alto, olhe o servidor antes do frontend. Páginas de categoria e produto devem sair do full page cache. Confira nos headers da resposta se houve cache hit e se nenhum bloco da página usa cacheable="false", que desativa o cache da página inteira.

O artigo sobre full page cache com Varnish cobre a configuração e as taxas de hit. Páginas sem cache, como o carrinho, são um trabalho separado de ajuste no servidor.

2. CSS que bloqueia a renderização

O Luma carrega styles-m.css e styles-l.css no head. Eles são grandes e bloqueiam a renderização. O Magento consegue inlinar o CSS crítico e carregar o resto de forma assíncrona:

bin/magento config:set dev/css/use_css_critical_path 1

Isso espera um arquivo web/css/critical.css no seu tema. O Magento não gera esse arquivo para você. Gere com uma ferramenta de critical CSS rodando nos seus templates reais e mantenha pequeno. Ativar a configuração sem um bom arquivo de critical CSS causa um flash de conteúdo sem estilo, o que pode prejudicar o CLS.

3. Fontes

Web fonts atrasam a renderização do texto. Faça preload de uma ou duas fontes usadas acima da dobra e use font-display: swap nas regras @font-face. No layout XML, o head aceita um elemento font que gera um link de preload:

<head>
    <font src="fonts/inter/inter-regular.woff2"/>
</head>

Confira no head os preloads de fontes herdados do tema pai, como Open Sans, e remova os que o seu tema não usa. Uma fonte com preload é baixada mesmo que o CSS não a utilize.

4. A própria imagem do LCP

Nas páginas de produto, a imagem principal é renderizada pelo JavaScript da galeria Fotorama. Até a galeria inicializar, o Luma mostra um placeholder, então a imagem real aparece tarde. Opções, da mais simples à que dá mais trabalho:

  • Garanta que a imagem entregue tem o tamanho certo para o espaço e usa um formato moderno. O artigo sobre otimização de imagens de produto cobre tamanhos e WebP.
  • Renderize a primeira imagem da galeria como um img simples no template, para que ela esteja no HTML desde o início, e deixe a galeria assumir depois.
  • Troque o Fotorama por uma galeria mais leve.

Nos banners da home e na primeira linha de produtos da categoria, não faça lazy load das imagens acima da dobra. Aplicar lazy loading na imagem do LCP atrasa ela. Adicione fetchpriority="high" na única imagem que é o elemento do LCP e mantenha loading="lazy" em tudo que vem abaixo.

INP: Interaction to Next Paint

O INP substituiu o First Input Delay como Core Web Vital em março de 2024. Ele mede quanto tempo a página leva para responder visualmente a cliques, toques e teclas, ao longo de toda a visita. No Luma, um INP ruim vem da main thread ocupada.

JavaScript demais rodando no carregamento

RequireJS, jQuery, Knockout e o framework de UI components executam em toda página. Depois cada módulo inicializa seus widgets. Enquanto isso roda, um toque no menu ou em um swatch fica esperando. A solução é carregar menos e executar menos:

  • Desative módulos que você não usa. Um módulo habilitado adiciona seu JavaScript pelos arquivos de layout mesmo que ninguém use a funcionalidade, então veja o que a página carrega e não só a lista de funcionalidades.
  • Faça bundle por tipo de página em vez de carregar uma longa cadeia de arquivos. Veja o artigo sobre bundling de JavaScript.
  • Inicialize widgets pesados só quando ficarem visíveis ou quando o usuário interagir com eles.

Scripts de terceiros

Widgets de chat, de avaliações, tag managers, heatmaps e ferramentas de teste A/B costumam ser o maior problema de INP, e são os mais difíceis de corrigir porque pertencem a outra pessoa. Faça uma lista de todos os scripts de terceiros, de quem é cada um e para que serve. Remova o que ninguém usa. Carregue o resto depois que a página estiver interativa ou depois da primeira interação, quando o fornecedor permitir. Para tracking, uma configuração limpa do GTM com menos tags ajuda mais do que qualquer mudança no Magento. O artigo sobre tracking com GA4 e GTM mostra como manter isso enxuto.

Event handlers caros

Cliques em swatches de produtos configuráveis recalculam preços, imagens e estoque em JavaScript. Com muitas opções, isso pode demorar o suficiente para aparecer no INP. Use o painel Performance do Chrome DevTools, grave um toque em um swatch com CPU throttling e veja quais funções consomem o tempo.

CLS: Cumulative Layout Shift

O CLS mede conteúdo que se move depois de aparecer. O Magento tem algumas fontes clássicas:

  • Imagens sem dimensões. Todo img precisa de atributos width e height, ou de um aspect ratio em CSS, para o navegador reservar o espaço. Confira templates customizados e conteúdo de CMS, que muitas vezes não têm.
  • Conteúdo injetado por JavaScript. As customer data sections preenchem os links do header, o contador do minicart e as mensagens depois do carregamento. Dê tamanho fixo a esses contêineres para que o preenchimento não empurre a página para baixo.
  • Componentes estilizados tarde. Sliders e carrosséis que renderizam como uma lista empilhada até o JavaScript rodar e depois colapsam em uma linha. Estilize o estado inicial para ficar igual ao final.
  • Banners e avisos no topo. Barras de cookies, faixas promocionais e banners de app que aparecem acima do conteúdo depois do carregamento. Faça como overlay ou reserve o espaço.
  • Web fonts. Uma grande diferença entre a fonte de fallback e a web font desloca o texto quando a fonte carrega. Escolha um fallback parecido ou ajuste com size-adjust na regra @font-face.

No DevTools, o painel Performance marca os layout shifts e os elementos que se moveram. Comece pelo maior no mobile.

Uma ordem que funciona

  1. Confirme os hits de full page cache nas páginas de catálogo e corrija o tempo de resposta do servidor.
  2. Faça uma auditoria dos scripts de terceiros e remova ou adie o que der.
  3. Corrija as dimensões das imagens e a imagem do LCP em cada tipo de página.
  4. Reserve espaço para tudo que é injetado depois do carregamento.
  5. Trabalhe na entrega de CSS e nas fontes.
  6. Reduza e faça bundle do JavaScript do Luma.

Cada passo é mensurável sozinho. Publique um de cada vez para saber qual mudança moveu qual métrica.

FAQ

Uma loja Luma consegue passar nos Core Web Vitals?

Consegue, mas exige trabalho deliberado em cache, imagens, scripts de terceiros e JavaScript. De fábrica, o Luma normalmente sofre no mobile, principalmente com INP nas páginas de produto.

Por que minha nota no PageSpeed é boa mas o Search Console ainda mostra URLs ruins?

A nota é dado de laboratório de uma única execução simulada. O Search Console usa dados de campo de visitantes reais em 28 dias no percentil 75, o que inclui celulares lentos, redes lentas e scripts de terceiros que uma execução de laboratório pode não disparar.

O Varnish resolve os Core Web Vitals?

Resolve a parte de servidor do LCP em páginas cacheáveis. Não faz nada pela execução de JavaScript, pelos layout shifts nem pelo tempo que as imagens levam para carregar.

Devo fazer lazy load de todas as imagens?

Não. Faça lazy load só das imagens abaixo da dobra. A imagem do LCP e as outras visíveis no primeiro carregamento devem carregar de imediato, e a imagem do LCP pode receber fetchpriority high.

Atendo como freelancer em Magento e Adobe Commerce, incluindo auditorias e correções de Core Web Vitals. Se você precisa de ajuda com isso, fale comigo.

Artigos relacionados