Como aumentar a velocidade da sua loja virtual: guia prático

Para melhorar a velocidade da loja virtual, meça as páginas de categoria e de produto no PageSpeed Insights e ataque nesta ordem: fotos de produto, cache, CDN, plugins e apps, scripts de terceiros e, se o servidor ainda demorar a responder, a hospedagem. Quase sempre uma ou duas dessas causas respondem pela maior parte da lentidão.

Este guia mostra como medir, o que significa cada métrica das Core Web Vitals numa loja e o que fazer em cada frente, com uma lista de prioridades no final.

---

Por que a velocidade pesa nas vendas

Numa loja, cada página lenta é um degrau a mais entre o anúncio e a compra. O cliente que esperou a categoria abrir ainda vai esperar a página do produto, o carrinho e o checkout. Quem chega pelo celular, com rede móvel instável, sente isso primeiro.

O que dizem os estudos: uma pesquisa encomendada pelo Google e feita pela Deloitte com 37 marcas europeias e americanas encontrou aumento de 8,4% na taxa de conversão de sites de varejo quando a velocidade no celular melhorou 0,1 segundo em quatro métricas de carregamento, em todas as páginas do caminho até a compra (resumo do estudo no web.dev). É uma média daquelas lojas, não uma promessa: o efeito na sua depende do público, do produto e de quão lenta ela está hoje.

Velocidade também conta no Google. As Core Web Vitals entram na avaliação de experiência da página, mas não substituem um bom título, boa descrição de produto e preço competitivo. Pense nelas como desempate, não como atalho.

---

Como medir a velocidade da loja

Não teste só a página inicial. Ela costuma ser a mais trabalhada e a menos parecida com o resto da loja. Faça assim:

1. Separe quatro URLs: a home, uma categoria com muitos produtos, um produto campeão de vendas e a página do carrinho.
2. Cole cada uma no PageSpeed Insights e comece pela aba Celular.
3. Olhe primeiro o bloco de dados de campo, que vem de visitantes reais do Chrome nos últimos 28 dias. É ele que conta para as Core Web Vitals. Lojas com pouco tráfego podem não ter dados suficientes nesse bloco.
4. Depois, veja a nota de desempenho (dado de laboratório, de 0 a 100) e os diagnósticos logo abaixo. Eles apontam o que mais pesa: imagem grande, script bloqueando, servidor lento.
5. Anote os números numa planilha antes de mexer em qualquer coisa. Sem esse ponto de partida, você não saberá o que funcionou.

O PageSpeed Insights usa o Lighthouse por baixo. Se quiser investigar com mais calma, rode-o direto no Chrome seguindo o guia do Google Lighthouse. Para uma visão do site inteiro, use o relatório de Core Web Vitals do Google Search Console, que agrupa as páginas com o mesmo problema.

---

Core Web Vitals na loja: LCP, INP e CLS

As três métricas medem coisas diferentes, e cada uma tem um vilão típico em e-commerce. Para passar, a página precisa ficar no “bom” nas três em pelo menos 75% das visitas.

Métrica	O que mede	Bom	Vilão comum na loja
LCP (Largest Contentful Paint)	Quando o maior elemento visível aparece	até 2,5 s	Banner da home ou foto principal do produto pesada; servidor lento
INP (Interaction to Next Paint)	Quanto a página demora para reagir a toques e cliques	até 200 ms	Filtros de categoria, seletor de tamanho e cor, botão “comprar” travados por excesso de JavaScript
CLS (Cumulative Layout Shift)	Quanto o layout “pula” durante o carregamento	até 0,1	Faixa de frete grátis, pop-up de cupom, selo de avaliações ou banner de cookies que entram depois e empurram o conteúdo

Atualização: o INP substituiu o FID (First Input Delay) como Core Web Vital em março de 2024. O FID media só o primeiro clique; o INP considera todas as interações da visita, por isso filtros e variações de produto pesados aparecem bem mais agora. Se um tutorial ou plugin ainda fala em FID, ele está desatualizado.

---

Imagens de produto

Uma categoria com 40 produtos carrega 40 fotos de uma vez. Se cada uma sair da câmera ou do fornecedor sem tratamento, a página fica pesada antes de qualquer outro problema. É o ajuste com melhor retorno e o mais fácil de fazer.

• Redimensione antes de enviar. A miniatura da categoria não precisa da mesma foto de 3.000 px usada no zoom. Plataformas e temas atuais geram tamanhos diferentes automaticamente; confira se o tema está usando o tamanho certo em cada lugar.
• Use WebP ou AVIF. Comprimem mais que JPEG e PNG com qualidade parecida e funcionam nos navegadores atuais. Para testar a compressão de uma foto antes de mudar a loja toda, o Squoosh é gratuito e roda no próprio navegador.
• Lazy loading só abaixo da dobra. Produtos do fim da categoria e fotos secundárias da galeria podem carregar sob demanda. A foto principal do produto e o banner do topo, não: neles o lazy loading piora o LCP.
• Defina largura e altura. Assim o navegador reserva o espaço da foto e a grade de produtos não pula.
• Carrossel com moderação. Um banner rotativo com cinco imagens grandes na home carrega as cinco, mesmo que o cliente só veja a primeira.

Para padronizar fundo, ângulos e tamanhos das fotos, veja também como trabalhar com imagens no e-commerce.

---

Cache: o que pode e o que não pode ir

Em lojas feitas em WooCommerce, Magento, OpenCart e outras plataformas em PHP, cada página é montada na hora: o servidor executa código e consulta o banco. O cache de página guarda o HTML pronto e corta esse trabalho. Numa loja, o segredo é separar o que é igual para todos do que é pessoal.

Página	Cache de página?	Por quê
Home, categorias, produtos, páginas institucionais	Sim	São iguais para todos os visitantes e concentram o tráfego
Carrinho e checkout	Não	Mudam para cada cliente; em cache, um cliente veria o carrinho de outro
Minha conta, pedidos, lista de desejos	Não	Mostram dados pessoais
Busca interna e filtros	Depende	Combinações demais lotam o cache; costuma valer só para as buscas mais comuns

Para as páginas que não podem ir para o cache de página, o cache de objeto (Redis ou Memcached) ajuda guardando em memória o resultado de consultas repetidas ao banco. E o cache do navegador faz o cliente reaproveitar CSS, JavaScript, fontes e logotipo de uma página para a outra.

Cuidado com preço e estoque: ao ativar cache de página, confira se o plugin ou a plataforma limpa a página do produto quando o preço ou o estoque mudam. Senão, o cliente vê um preço velho e só descobre o novo no carrinho.

---

CDN para lojas com público espalhado

Uma CDN copia imagens, CSS e JavaScript para servidores em várias regiões e entrega cada arquivo a partir do ponto mais próximo do cliente. Ela faz diferença quando:

• a loja vende para o Brasil inteiro, ou para fora, e o servidor fica numa única cidade;
• o catálogo tem muitas fotos e o servidor gasta banda e processamento só para entregá-las;
• você espera picos, como Black Friday ou uma campanha com influenciador, e quer tirar carga do servidor.

A CDN não corrige um servidor lento para montar o HTML do carrinho ou do checkout. Ela complementa o cache e a hospedagem, não substitui.

---

Plugins, apps e extensões

Toda loja acumula plugins (WooCommerce, Magento) ou apps (plataformas prontas) ao longo do tempo: um para frete, outro para avaliações, outro para um pop-up de cupom usado numa campanha de dois anos atrás. Cada um pode adicionar consultas ao banco, arquivos CSS e scripts em todas as páginas. Uma auditoria simples:

1. Liste tudo o que está instalado e, ao lado, o que cada item faz pela venda.
2. Desative e remova o que ninguém usa mais. Desativado não basta em todos os casos: alguns deixam tarefas agendadas e tabelas no banco.
3. Procure funções duplicadas, como dois plugins de SEO ou dois de otimização de imagem.
4. Numa cópia da loja, desative os suspeitos um por vez e meça de novo. O que mais pesar merece uma alternativa mais leve.
5. Mantenha plataforma, tema e plugins atualizados. Versões novas costumam trazer correções de desempenho e de segurança.

Faça essas mudanças fora de datas de venda forte. Um conflito descoberto na véspera da Black Friday custa caro.

---

Scripts de terceiros: chat, pixels e avaliações

Pixels de anúncio, ferramentas de análise, chat, mapa de calor, selo de avaliações, recomendação de produtos: cada um baixa código de outro servidor e disputa o processador do celular com a sua loja. São a causa mais comum de INP alto em e-commerce.

• Abra o gerenciador de tags e liste todos os scripts ativos. É comum achar pixels de campanhas encerradas e ferramentas de teste esquecidas.
• Carregue cada script só onde ele é usado. O pixel de conversão precisa estar na página de obrigado, não necessariamente em todas.
• Atrase o chat e widgets parecidos: carregue o botão leve primeiro e o código completo só quando o cliente clicar ou depois de alguns segundos.
• Use defer ou async nos scripts que não precisam rodar antes de a página aparecer.

<!-- Bloqueia a página até baixar e executar -->
<script src="https://exemplo.com/widget-avaliacoes.js"></script>

<!-- Baixa em paralelo e executa depois que o HTML terminou -->
<script src="https://exemplo.com/widget-avaliacoes.js" defer></script>

---

Hospedagem: quando o gargalo é o servidor

Se o PageSpeed Insights aponta tempo de resposta do servidor alto (TTFB) mesmo com cache ativo, o problema está na infraestrutura. Sinais comuns: a loja fica lenta no horário de pico, o painel administrativo demora para abrir e o checkout trava quando há muitos pedidos ao mesmo tempo.

O que conferir com a sua hospedagem:

• Versão do PHP: versões atuais são mais rápidas e seguras. Teste numa cópia antes de trocar, porque plugins antigos podem quebrar.
• Recursos isolados: em ambiente compartilhado, outra conta consumindo demais pode deixar sua loja lenta. Tecnologias como o CloudLinux limitam e isolam os recursos de cada conta.
• HTTPS com HTTP/2 ou HTTP/3: os navegadores só usam esses protocolos em conexões seguras, então o certificado SSL ativo também abre caminho para a versão mais rápida.
• Folga para picos: se a loja cresce e as campanhas trazem picos fortes, um servidor com recursos dedicados, como um VPS, evita que o checkout dispute memória e processador com outros sites.

Se a sua loja roda numa plataforma pronta (SaaS), o servidor e a CDN ficam por conta dela. Seu controle está nas imagens, nos apps e nos scripts, que é justamente onde costuma estar o maior ganho.

Na SAN: a hospedagem de sites roda em Instâncias Cloud, com cPanel, CloudLinux isolando os recursos de cada conta e tráfego ilimitado. A migração da sua loja é gratuita e o suporte é em português. Quando a loja precisar de recursos dedicados, o Cloud Server VPS oferece acesso root e opção de cPanel/WHM.

---

Plano de ação em ordem de prioridade

Siga de cima para baixo, medindo depois de cada etapa. Faça backup antes de mexer em plugins, tema ou servidor.

Etapa	O que fazer	Métrica que costuma melhorar
1	Medir home, categoria, produto e carrinho no PageSpeed Insights e anotar os valores	Ponto de partida
2	Redimensionar e converter fotos de produto e banners para WebP ou AVIF	LCP
3	Tirar o lazy loading da foto principal e definir largura e altura das imagens	LCP e CLS
4	Ativar cache de página, com carrinho, checkout e conta excluídos	LCP e TTFB
5	Remover plugins e apps sem uso e revisar scripts de terceiros	INP
6	Reservar espaço para faixas, pop-ups e selos que entram depois	CLS
7	Avaliar CDN para imagens e arquivos estáticos	LCP para quem está longe
8	Se o TTFB continuar alto, revisar PHP e hospedagem	TTFB e LCP

Os dados de campo levam até 28 dias para refletir as melhorias. Para entender cada métrica em mais detalhe e ver exemplos de código, consulte o guia completo de velocidade do site.

---

Perguntas frequentes