Sua loja virtual é lenta? O que realmente pesa no carregamento
Core Web Vitals sem mistério e as causas mais comuns de lentidão em e-commerce.
Por MFactor · · 3 min de leitura
Quando um lojista diz que o site "está lento", quase sempre ele testou no computador do escritório, com internet boa. O cliente dele está no celular, no 4G, às vezes dentro de um ônibus. A experiência é outra.
Desde 2021 o Google usa um conjunto de métricas chamado Core Web Vitals entre os sinais de ranqueamento. Mais do que pelo SEO, elas valem porque descrevem bem o que o cliente sente quando abre a página.
As três métricas
LCP (Largest Contentful Paint) mede quanto tempo o maior elemento visível leva para aparecer. Numa página de produto, quase sempre é a foto principal. O recomendado é até 2,5 segundos.
INP (Interaction to Next Paint) mede quanto a página demora para reagir quando o cliente toca em algo: escolher o tamanho, adicionar ao carrinho, abrir o menu. Ela substituiu o antigo FID em março de 2024. O bom é ficar até 200 milissegundos.
CLS (Cumulative Layout Shift) mede o quanto o conteúdo pula enquanto carrega. Sabe quando você vai tocar num botão e ele desce porque apareceu um banner? É isso. O ideal é ficar abaixo de 0,1.
Um detalhe que muda a leitura: o Google olha o percentil 75 dos acessos reais. Não adianta a página abrir rápido no seu teste. Ela precisa abrir rápido para a maioria dos clientes, nos aparelhos deles.
Onde olhar
O PageSpeed Insights mostra duas coisas diferentes, e é comum confundir. Em cima aparecem os dados de campo, coletados de usuários reais do Chrome nos últimos 28 dias. Embaixo vem o teste de laboratório, uma simulação feita na hora. Os dados de campo são os que contam. O laboratório serve para achar a causa.
No Search Console, o relatório de Core Web Vitals agrupa as páginas com problema, o que ajuda a decidir por onde começar.
As causas mais comuns
Foto de produto pesada. É a campeã. Imagem de 3 MB no tamanho original da câmera, servida igual para celular e computador. Converter para WebP ou AVIF, gerar tamanhos diferentes com srcset e ajustar a compressão costuma derrubar o LCP mais do que qualquer outra mudança.
Lazy loading na foto principal. Carregar imagens só quando aparecem na tela é ótimo para o que está mais embaixo da página. Aplicado na foto principal, atrasa justamente o elemento que o LCP mede. Essa imagem deveria carregar com prioridade alta.
Scripts de terceiros. Pixel de anúncio, chat, avaliações, mapa de calor, recomendação de produtos. Cada um parece leve sozinho. Juntos, ocupam o processador do celular e são a principal causa de INP ruim. Vale revisar a lista a cada trimestre e perguntar quem ainda usa cada um. Os que ficam podem carregar depois que a página já estiver respondendo.
Espaço não reservado. Imagem sem largura e altura definidas, banner que entra depois e fonte que muda de tamanho ao carregar são as causas clássicas de CLS. Reservar o espaço no layout resolve quase tudo.
Servidor lento na primeira resposta. Se o HTML leva mais de 800 milissegundos para começar a chegar, o resto não compensa. Aqui entram cache de página, CDN e consultas mais enxutas ao banco.
Por onde começar
Se fosse para escolher uma ordem, seria esta: abrir os dados de campo das páginas que mais vendem (normalmente a home, a de categoria e a de produto), corrigir as imagens, revisar os scripts de terceiros e só depois olhar para o servidor.
Em muitas lojas, os dois primeiros passos já resolvem boa parte do problema, sem trocar de plataforma e sem reescrever nada. É por essa ordem que a MReach, frente de e-commerce da MFactor Tecnologia, começa qualquer revisão de performance.
Assuntos: E-commerce, Core Web Vitals, Performance, MReach
Continue lendo
- Entrega progressiva: feature flags, canary e blue-green — Como separar deploy de release com flags avaliadas por hash determinístico, escolher entre blue-green e canary, e deixar métricas de guarda decidirem a promoção ou o rollback com Argo Rollouts.
- Semântica de entrega em sistemas de mensageria: at-least-once, idempotência e dead-letter queues — Por que o broker entrega mais de uma vez, como o consumidor converte repetição em efeito único com uma tabela de mensagens processadas na mesma transação, e o que fazer com a mensagem que falha sempre.
- Estratégias de cache e invalidação em sistemas web — Como escolher entre cache-aside, read-through e write-behind, decidir entre TTL e invalidação por evento, conter o thundering herd com stale-while-revalidate e coalescing em Redis, e usar as camadas de cache do Next.js com revalidateTag.
Quer aplicar isto no seu sistema? Fale com a MFactor: contato ou WhatsApp +55 (19) 99778-9831.