Como deixar o WooCommerce rápido desde o início: performance antes do lançamento

A loja está pronta: hospedagem escolhida, WooCommerce instalado e configurado para o Brasil, pagamentos e frete testados, tema e plugins definidos com critério, segurança e backup em dia. Falta um passo antes de abrir as portas: garantir que a loja carregue rápido para quem chega.

Você está na Etapa 8 do guia completo de como criar uma loja WooCommerce no Brasil. Este artigo prepara a performance — a velocidade da loja — antes do lançamento, para você não correr atrás do prejuízo com a loja já no ar. Ao final, sua loja terá: linha de base registrada, cache configurado com as exclusões corretas, imagens e scripts tratados e o fluxo de compra validado em desktop e mobile.

O caminho tem três fases: medir → otimizar → validar. Primeiro, registrar a situação atual da loja. Depois, corrigir na ordem certa o que pesa: tempo de resposta do servidor, imagens, scripts e cache. Por fim, validar o resultado — incluindo o fluxo de compra real, que é o que paga as contas.

Um aviso honesto: este guia não promete nota 100 em ferramentas, nem um tempo universal de carregamento que valha para toda loja. Lojas são diferentes — e uma loja tem páginas dinâmicas, como carrinho e checkout, que mudam para cada cliente e não podem ser tratadas como um site institucional. O objetivo é uma loja rápida de forma mensurável e segura para vender.

Neste guia

• Medir antes de otimizar: crie a linha de base
• Quais páginas testar
• Core Web Vitals: os três sinais que o Google acompanha
• O tempo de resposta da hospedagem
• Cache de página: o que acelera e o que nunca deve ser cacheado
• Cache de objeto: o que é e quando faz sentido
• CDN: quando ajuda de verdade
• Imagens: o maior ganho prático
• Tema e plugins: o que pesa de verdade
• Scripts externos: cada terceiro tem um preço
• Banco de dados e tarefas em segundo plano
• HPOS: a estrutura moderna de pedidos
• PHP e versões: o básico que a hospedagem cuida
• O painel administrativo também conta
• Mobile: o teste que vale a pena
• Como acelerar loja WooCommerce: a ordem certa das mudanças
• Testar depois de cada mudança
• Checklist de performance antes do lançamento
• Erros comuns
• Quando chamar um especialista
• Perguntas frequentes

Medir antes de otimizar: crie a linha de base

Instalar um plugin de cache — que guarda cópias prontas das páginas — ou ativar uma CDN (rede de servidores que distribui arquivos estáticos) sem saber como a loja está hoje é otimizar no escuro. Você não sabe o que melhorou, o que piorou e o que nunca teve efeito.

A primeira tarefa é criar uma linha de base: um registro simples e datado da velocidade atual da loja. Anote em uma planilha ou documento:

• Data e horário do teste.
• Página testada (home, produto, checkout).
• Ferramenta usada e valores obtidos.
• Se o teste foi em desktop ou mobile.

Com isso, qualquer mudança futura pode ser comparada com a situação anterior — é esse antes/depois que mostra se uma otimização valeu a pena.

Onde medir:

• PageSpeed Insights: analisa uma URL pública em desktop e mobile e mostra as Core Web Vitals, que detalho adiante. Ele não testa loja local, privada ou protegida por senha — nesses casos, use o Lighthouse.
• Lighthouse, dentro do Chrome DevTools: roda no seu próprio computador, na mesma rede da loja — o caminho para testar loja local, privada ou protegida. Por ser um teste de laboratório, sem interações reais, ele não mede o INP de verdade; o TBT (tempo total de bloqueio) pode servir como aproximação.
• Relatório Core Web Vitals do Search Console: mostra como o Google percebe a velocidade da loja ao longo do tempo — útil depois que a loja estiver no ar e indexada. Os dados vêm de usuários reais (CrUX) e só aparecem quando a URL ou a origem atende aos critérios e tem volume suficiente de visitas; não espere dados logo após a indexação.

Há dois tipos de dado: de laboratório, produzidos pelo Lighthouse em condições controladas, e de usuários reais, coletados pelo CrUX. O PageSpeed Insights reúne os dois quando há dados reais suficientes para a URL ou origem; quando não há, a análise fica baseada principalmente nos dados de laboratório do Lighthouse. Os dois se complementam — e carrinho e checkout, que dependem de sessão real, devem ser testados no navegador com um produto no carrinho e o DevTools aberto, não apenas pelo PageSpeed Insights.

Uma medição isolada não representa a experiência real. Rede, localização do visitante, horário e até o cache do navegador mudam os números. Meça mais de uma vez, em momentos diferentes, e use a comparação entre medições — não uma captura isolada — como referência.

Quais páginas testar

Um site institucional tem meia dúzia de páginas parecidas. Uma loja tem vários tipos de página, cada um com trabalho diferente no servidor. A home pode carregar rápido e o checkout demorar — e é o checkout que decide a venda.

Crie uma lista de páginas para testar:

• Home.
• Uma página de categoria (listagem de produtos).
• Uma página de produto (a que tem variações e botão de comprar).
• A página de busca, se você usa busca na loja.
• Carrinho.
• Checkout.
• Minha conta ou login, se sua loja exige conta ou oferece área do cliente.

As páginas de carrinho, checkout e conta são dinâmicas: mostram dados específicos do cliente — itens no carrinho, frete calculado, pedidos anteriores. Elas consultam o banco de dados a cada visita e não podem ser tratadas como páginas fixas. É por isso que o teste delas é separado e obrigatório.

Core Web Vitals: os três sinais que o Google acompanha

O Google acompanha três sinais principais de velocidade, definidos no artigo oficial sobre Core Web Vitals. Os nomes são técnicos, mas a ideia é simples:

• LCP (Largest Contentful Paint) — o carregamento do conteúdo principal: quanto tempo até o maior elemento visível da página (a imagem principal ou o título, por exemplo) aparecer.
• INP (Interaction to Next Paint) — a resposta às interações: quanto tempo a página leva para reagir quando o visitante toca ou clica em algo.
• CLS (Cumulative Layout Shift) — a estabilidade visual: se elementos da página “pulam” de lugar enquanto carregam, o CLS sobe — e isso confunde o cliente.

Os limites oficiais para uma experiência boa, segundo o web.dev: LCP de até 2,5 segundos, INP de até 200 milissegundos e CLS de até 0,1. Esses valores são medidos no percentil 75 dos carregamentos, separadamente para mobile e desktop.

São sinais úteis — não o único indicador de uma loja boa. Uma loja pode ter números decentes e ainda perder venda por um checkout confuso, e o contrário também acontece. Use as Core Web Vitals como referência de comparação, não como tribunal.

O tempo de resposta da hospedagem

Uma página pode estar perfeitamente otimizada no navegador e ainda demorar porque o servidor responde devagar. Toda visita começa com um pedido ao servidor, e existe um tempo até ele começar a responder — na sigla técnica, TTFB, o “tempo até o servidor começar a responder”. Você não precisa decorar a sigla; o comportamento é o que importa: se o servidor demora, tudo que vem depois demora junto.

Onde isso aparece com mais força:

• Carrinho, checkout e busca: páginas que dependem de dados calculados na hora.
• O painel administrativo: listar pedidos, editar produtos, gerar relatórios.
• Momentos de pico: uma promoção divulgada em redes sociais aumenta os acessos ao mesmo tempo e pode deixar o servidor sobrecarregado.

A hospedagem é a base de tudo — como vimos no guia de hospedagem da série. Antes de trocar de plano, porém, identifique o sinal: a hospedagem é o gargalo quando as páginas dinâmicas e o painel ficam lentos mesmo com a loja otimizada e o tráfego normal. Só com esse sinal um upgrade faz sentido.

Cache de página: o que acelera e o que nunca deve ser cacheado

O manual de performance do WordPress resume o assunto em uma frase: o cache é o maior benefício pelo menor esforço. Cache de página é uma cópia pronta da página, salva para ser entregue sem que o servidor refaça todo o trabalho a cada visita. Na primeira visita, a página é gerada e guardada; nas seguintes, o visitante recebe a cópia pronta. Para páginas que mudam pouco — home, categoria, produto — isso reduz o tempo de resposta e o esforço do servidor.

Mas nem tudo pode ser servido como cópia estática. As páginas de carrinho, checkout e minha conta mostram dados específicos de cada cliente e da sessão atual: itens no carrinho, endereço, frete, pedidos. Se um cache servisse uma cópia fixa dessas páginas, o cliente veria o carrinho errado, estoque desatualizado — ou, pior, dados de outra pessoa.

A documentação oficial do WooCommerce sobre configuração de cache é explícita: essas três páginas não podem ser cacheadas e devem ser excluídas do cache de página. A boa notícia: o WooCommerce já envia aos sistemas de cache sinais de “não guardar” nessas páginas, e muitos plugins de cache já as excluem automaticamente, reconhecendo os cookies de carrinho e sessão da loja. Depois de instalar um cache, confira se as exclusões continuam aplicadas — principalmente após atualizações.

Dois plugins que seguem essa regra, na prática:

• WP Super Cache (mantido pela Automattic): a documentação oficial do WooCommerce afirma que ele é nativamente compatível — o WooCommerce envia informações ao plugin para que as páginas de Carrinho, Checkout e Minha conta não sejam cacheadas por padrão. As configurações recomendadas pelo próprio plugin: Simple caching, comprimir páginas, não cachear usuários conhecidos e cache rebuild.
• LiteSpeed Cache: os recursos de cache de página exigem uma solução LiteSpeed compatível no servidor ou o serviço QUIC.cloud; os recursos gerais de otimização podem funcionar em outros servidores. A FAQ oficial do plugin confirma que as páginas de Minha conta, Checkout e Carrinho do WooCommerce são excluídas do cache por padrão.

Algumas hospedagens oferecem cache próprio, no painel do provedor. Vale perguntar ao suporte como essa solução trata as páginas dinâmicas do WooCommerce — a resposta define se você a usa ou prefere um plugin.

Regra de ouro: um plugin de cache de página por vez. Nunca dois. Dois caches disputam o controle da mesma página, geram versões conflitantes e causam exatamente o tipo de erro que você está tentando evitar.

Um detalhe que dispensa ação: desde a versão 7.8 do WooCommerce, o script de atualização do mini carrinho só é carregado quando você realmente usa um widget de mini carrinho. Não há nada para desativar — o próprio WooCommerce cuida disso.

Cache de objeto: o que é e quando faz sentido

Cache de objeto é outra camada: ele guarda em memória o resultado de consultas repetidas ao banco de dados, para a loja não recalcular tudo a cada requisição. Enquanto o cache de página entrega cópias prontas de páginas inteiras, o cache de objeto acelera o trabalho dinâmico — carrinho, checkout, sessões, buscas.

Por padrão, o cache de objeto do WordPress não é persistente: dura apenas uma requisição e não serve para nada além dela. Para persistir entre requisições, a hospedagem precisa oferecer ou configurar uma solução de cache de objeto persistente — Redis e Memcached são exemplos comuns — e um plugin que se conecte a ela.

Quando faz sentido? Em catálogos grandes, com muitos produtos, ou lojas com muitas operações dinâmicas ao mesmo tempo — promoções com tráfego alto, por exemplo. Para uma loja nova, com dezenas ou centenas de produtos, o cache de objeto não é obrigatório: a prioridade é o cache de página bem configurado.

Se a sua hospedagem oferece Redis, vale conversar com o suporte sobre quando ativar. Se não oferece, não é motivo para trocar de plano — primeiro, o resto do processo.

CDN: quando ajuda de verdade

CDN (rede de distribuição de conteúdo) é um conjunto de servidores espalhados por várias regiões que guarda cópias dos arquivos estáticos da loja — imagens, CSS e JavaScript. Quando um visitante acessa a loja, ele recebe esses arquivos do servidor mais próximo, em vez de buscá-los sempre na origem.

O benefício real depende do seu público (onde ele está), da configuração e do tipo de página. A documentação do WordPress destaca que a CDN é mais eficaz quando combinada com um plugin de cache.

Importante: CDN não conserta servidor lento, consulta ruim ou plugin pesado. Se a origem demora para responder, a CDN entrega arquivos rápidos — mas a página continua dependendo do servidor original para as partes dinâmicas.

A Cloudflare é um exemplo comum de provedor (a própria documentação do WooCommerce a cita, ao lado de Fastly e Amazon CloudFront). Não vou ensinar configuração de DNS aqui — o ponto é o papel da CDN na sua estratégia: avalie depois de resolver hospedagem, imagens e cache, e apenas se o seu público se beneficiar dela.

Imagens: o maior ganho prático

Imagens são o ganho prático mais imediato em quase toda loja. Elas costumam ser a maior parte do peso de uma página — e raramente exigem configuração avançada.

Quatro cuidados básicos:

• Dimensões adequadas: não suba uma foto de 4.000 pixels para exibi-la em 800. A imagem gigante é enviada inteira ao navegador, mesmo sendo exibida pequena. Redimensione antes de subir, nas medidas que a loja realmente usa.
• Formato moderno, quando suportado: o WordPress suporta WebP desde a versão 5.8 e AVIF desde a 6.5 — mas não converte automaticamente imagens JPEG para esses formatos por padrão. A conversão exige um plugin de otimização ou a exportação na ferramenta de edição. A nota oficial de desenvolvimento registra que o AVIF pode ser até 50% menor que o JPEG na mesma qualidade.
• Suporte do servidor: o AVIF exige suporte do servidor — confira em Ferramentas > Saúde do site, aba Informações, na seção de mídia do servidor (Media Handling). A documentação da tela de Saúde do site mostra onde olhar.
• Compressão: imagens comprimidas mantêm boa aparência com menos peso. A maioria das ferramentas de edição permite exportar para web; comprimir antes de subir resolve na origem.
• Não existe tamanho universal: nem em kilobytes nem em pixels. O certo é a imagem nas dimensões do layout, comprimida, no formato que o servidor suporta.

O WordPress já automatiza boa parte do trabalho. Ele gera vários tamanhos de cada imagem e entrega ao navegador o mais adequado, usando o mecanismo chamado srcset — um conjunto de versões da mesma imagem, com o navegador escolhendo a melhor para a tela e a conexão.

O lazy loading também é nativo: o WordPress aplica automaticamente o carregamento preguiçoso às imagens fora da primeira dobra. Isso não significa que a imagem só começa a baixar exatamente quando chega à área visível da tela (o viewport) — o navegador decide quando antecipar o carregamento, perto do momento em que ela vai aparecer. E, desde a versão 6.3, o WordPress aplica fetchpriority="high" por heurística à imagem considerada provável LCP (o conteúdo principal da página) — não a toda imagem do topo: uma imagem abaixo da primeira dobra não é automaticamente prioritária.

Um cuidado: se o seu tema permite marcar manualmente uma imagem como “carregar preguiçosamente”, não marque as que devem carregar primeiro. E nunca combine loading="lazy" com fetchpriority="high" na mesma imagem — a orientação oficial é explícita. Um slider pesado no topo, com várias imagens grandes, é um dos erros mais comuns — evite se não houver necessidade real.

Tema e plugins: o que pesa de verdade

A quantidade de plugins instalados, por si só, não determina a velocidade da loja. O que pesa é o que cada plugin executa em cada página:

• Scripts e estilos carregados em todas as páginas, mesmo onde não são usados.
• Consultas ao banco de dados a cada visita.
• Chamadas a serviços externos.
• Tarefas agendadas em segundo plano.
• Funções duplicadas — dois plugins fazendo o mesmo trabalho.

Você já definiu tema e plugins com critério na escolha de tema e plugins essenciais. Aqui, o reforço: um plugin útil, bem-feito e atualizado pesa menos que um plugin ocioso que você esqueceu ativo. Construtores de páginas e complementos adicionam recursos e podem aumentar o peso — não são automaticamente ruins. O que não faz sentido é mantê-los sem uso.

O manual de performance do WordPress recomenda remover plugins que você não usa. Faça uma revisão antes do lançamento: desative o que sobrou de testes, o que duplica função e o que está sem manutenção.

Scripts externos: cada terceiro tem um preço

Cada serviço de terceiros — analytics, pixel de anúncios, chat, mapa, fontes externas, widget de avaliação, ferramenta de marketing — adiciona arquivos carregados pelo visitante e uma dependência externa. Se o servidor do terceiro estiver lento, a página pode esperar por ele.

Não é uma cruzada contra ferramentas de marketing: cada uma delas pode ser essencial para o seu negócio. A regra é consciência:

• Meça o impacto antes de remover qualquer coisa que importa para o negócio — um pixel de conversão vale mais que meio segundo em uma página de produto.
• Carregue cada ferramenta só onde ela faz sentido. Um chat de atendimento, por exemplo, serve na página de produto e no checkout — não precisa estar em todas as páginas do site.
• Consolide: ferramentas que fazem a mesma coisa (dois scripts de mapa, três widgets de avaliação) podem virar uma.

A revisão de scripts externos faz parte da linha de base: registre o que está instalado, meça a página com e sem cada script (as ferramentas de teste permitem isso) e decida com dados, não por impulso.

Banco de dados e tarefas em segundo plano

Com o tempo, o WooCommerce acumula pedidos, sessões, logs e tarefas em segundo plano. Nada disso é problema por si — é o funcionamento normal da loja. O ponto de atenção são as tarefas agendadas.

O WooCommerce e muitos plugins agendam trabalhos para rodar em segundo plano: enviar e-mails de pedido, processar pagamentos, atualizar status, sincronizar com serviços externos. Esse motor se chama Action Scheduler, e ele roda por meio do WP-Cron — o sistema de agendamento do WordPress, que executa tarefas quando a loja recebe visitas.

Onde ver: WooCommerce > Status > Ações agendadas. A documentação oficial explica a tela. O que merece atenção:

• Tarefas pendentes há muito tempo: podem indicar que o cron não está rodando bem.
• Tarefas falhando: podem atrasar e-mails, pagamentos e integrações.
• Acúmulo em lojas movimentadas: muitos pedidos geram muitas tarefas.

Atenção ao oposto: não saia limpando o banco de dados. Não há SQL manual aqui, nem remoção de tabelas, nem limpeza agressiva de logs — esses procedimentos causam mais estrago que benefício sem análise técnica. Se as tarefas acumulam ou o banco cresce demais, o caminho é um especialista fazer a manutenção com critério.

HPOS: a estrutura moderna de pedidos

HPOS (High-Performance Order Storage) é a estrutura moderna de armazenamento de pedidos do WooCommerce: em vez de registrar pedidos como se fossem publicações comuns do WordPress, a loja os guarda em tabelas próprias, mais adequadas a volumes de vendas. O nome técnico não importa; o resultado é uma fundação melhor para pedidos, relatórios e integrações.

Desde a versão 8.2 (outubro de 2023), o HPOS está ativo por padrão em lojas novas — ou seja, a sua loja, criada recentemente, provavelmente já usa. A documentação oficial não promete um ganho específico de velocidade, e este guia também não vai prometer: o ponto de atenção é a compatibilidade das extensões — se algum plugin importante não for compatível com HPOS, ele pode apresentar problemas com pedidos. Se tudo o que você instalou declara compatibilidade, siga em frente sem preocupação.

PHP e versões: o básico que a hospedagem cuida

Versões atualizadas resolvem dois problemas ao mesmo tempo: corrigem falhas de segurança e trazem melhorias de desempenho. Hoje, o WordPress está na versão 7.0.4 (lançada em 12 de agosto de 2026, com correções de segurança) e o WooCommerce na 11.0.1 (10 de agosto de 2026, também de segurança). Manter os dois em dia é a base de qualquer discussão de velocidade.

O PHP — a linguagem que executa o WordPress — tem papel direto nisso. Os requisitos oficiais do WooCommerce pedem PHP 8.3 ou superior como recomendado (testado até a 8.4), com o mínimo de 7.4 — versão que chegou ao fim da vida em novembro de 2022 e não recebe mais correções. O blog oficial do WooCommerce (janeiro de 2026) reforça: versões a partir do PHP 8.1 estão em boa forma, e o 8.3 é o recomendado.

Você não precisa fazer nada de servidor: a troca de versão é responsabilidade da hospedagem. Seu papel é verificar a versão atual em Ferramentas > Saúde do site: a aba Status mostra se a versão do PHP está atualizada, e a aba Informações, na seção Servidor, exibe a versão exata. Se estiver abaixo do recomendado, peça ao suporte do provedor a atualização. Se o provedor não oferece versões recentes, esse é um sinal sobre a qualidade da hospedagem — não sobre o que você faz no painel.

O painel administrativo também conta

A velocidade do painel administrativo também faz parte da prontidão para o lançamento. Listar pedidos, editar produtos, abrir o WooCommerce Analytics, aplicar atualizações — tudo isso usa os mesmos recursos da loja: servidor, banco de dados e tarefas em segundo plano.

Se o painel estiver lento logo no início, com a loja ainda pequena, o problema tende a piorar com pedidos, produtos e histórico. Registre a sensação como parte da linha de base e trate o gargalo antes de lançar: a causa costuma estar na hospedagem, no banco ou no cron — os mesmos pontos que você já conferiu neste guia.

Mobile: o teste que vale a pena

Uma parte relevante das visitas de e-commerce acontece no celular — e é lá que a lentidão mais se sente. Teste em uma conexão móvel real, não apenas no desktop com Wi-Fi de escritório. Desligue o Wi-Fi, use dados móveis e percorra o fluxo: home, produto, carrinho, checkout.

No celular, preste atenção em:

• Botões e variações de produto: respondem rápido ao toque?
• Carrinho e checkout: o formulário flui sem travamentos?
• Imagens e scripts: em aparelhos e conexões limitados, o peso cobra caro.

Teste também anônimo e logado: o visitante anônimo representa a maioria dos clientes de uma loja nova, e a sessão logada mostra o comportamento de quem tem conta. Se um dos dois estiver lento, você descobriu um gargalo antes do lançamento — que é exatamente o objetivo deste guia.

Como acelerar loja WooCommerce: a ordem certa das mudanças

A ordem importa porque cada etapa reduz o trabalho das seguintes. Otimizar o cache antes de resolver as imagens, por exemplo, significa cachear uma página ainda pesada.

1. Meça e registre a linha de base. Sem ela, nada é comparável.
2. Resolva hospedagem e tempo de resposta, se houver sinal de gargalo — páginas dinâmicas e painel lentos com a loja otimizada.
3. Trate as imagens: dimensões, formato e compressão.
4. Remova funções e scripts desnecessários: plugins sem uso, serviços externos duplicados.
5. Configure o cache de página corretamente, com carrinho, checkout e minha conta fora dele.
6. Avalie CDN e cache de objeto apenas se fizer sentido para o seu público e o seu catálogo.
7. Teste tudo de novo e compare com a linha de base.
8. Valide o fluxo de compra em desktop e mobile: carrinho, cupom, frete, pagamento.

Se você não tem sinal de gargalo de hospedagem, pule a etapa 2 por ora — mas volte a ela se os sinais aparecerem. O processo é o mesmo para lojas já no ar: a diferença é que, com a loja aberta, cada mudança exige cuidado redobrado.

Testar depois de cada mudança

Teste depois de cada mudança, não depois de todas. Quando várias alterações entram de uma vez, não dá para saber qual delas melhorou — ou piorou — o quê.

O roteiro de teste:

• Repita as mesmas páginas da linha de base, na mesma ordem.
• Teste deslogado ou anônimo, em uma janela anônima ou privativa limpa, e logado, em uma sessão normal autenticada.
• Percorra o fluxo completo: produto → carrinho → cupom → frete → checkout → pagamento.
• Teste em mobile, na conexão móvel.
• Limpe o cache do navegador ou use uma janela anônima entre medições, para não comparar números enganosos.

Nenhuma mudança em performance justifica arriscar uma compra real. Use o modo de teste da loja ou faça a validação manual do fluxo — o objetivo é confirmar que carrinho, checkout e pagamento continuam funcionando, não gerar pedidos de verdade.

Checklist de performance antes do lançamento

Checklist de performance antes do lançamento

• Linha de base registrada (data, páginas, valores, desktop e mobile)
• Home, categoria, produto, busca, carrinho, checkout e minha conta testados
• Fluxo de compra validado em mobile e desktop
• Imagens redimensionadas, comprimidas e no formato com suporte do servidor
• Cache de página configurado, com carrinho, checkout e minha conta fora do cache
• Scripts externos revisados — cada um com função e impacto conhecidos
• Plugins sem uso removidos
• HTTPS ativo e sem erros no navegador
• Ações agendadas conferidas em WooCommerce > Status
• Backup feito antes de cada mudança — o processo está no guia de segurança e backup da série
• Validação final: números comparados com a linha de base e compra de teste concluída

Erros comuns

1. Correr atrás da nota 100 do PageSpeed. A nota é referência, não objetivo — otimizar a nota e esquecer a experiência real é o erro clássico.
2. Medir apenas a home. A página mais rápida da loja pode esconder um checkout lento — e é o checkout que decide a venda.
3. Instalar dois plugins de cache. Dois caches disputam a mesma página e geram erros; a regra é um por vez.
4. Cachear carrinho e checkout. Servir cópias fixas de páginas dinâmicas mostra carrinhos errados e dados de outro cliente — a exclusão é obrigatória.
5. Ativar minificação e combinação de arquivos sem testar. A documentação oficial de cache do WooCommerce recomenda evitar a minificação de JavaScript nesse contexto — ela pode quebrar o fluxo de compra —, enquanto a documentação de performance a apresenta como técnica possível. Qualquer otimização desse tipo precisa ser testada: se o checkout, o gateway ou algum componente quebrar, desative ou exclua os scripts problemáticos. A funcionalidade do fluxo de compra vem antes de qualquer ganho marginal.
6. Subir imagens gigantes. Uma foto de 4.000 pixels exibida em 800 é peso desperdiçado em toda visita.
7. Empilhar scripts de marketing sem medir. Cada pixel, chat e widget adiciona tempo e dependência — meça antes de adicionar e antes de remover.
8. Trocar de hospedagem sem identificar o gargalo. Upgrade sem sinal de problema na infraestrutura troca o custo, não a causa.
9. Fazer muitas mudanças de uma vez. Sem teste entre mudanças, ninguém sabe o que funcionou — e o que quebrou.
10. Limpar o banco de dados de forma agressiva. Remoção de registros, logs e tabelas sem análise técnica é receita para dados perdidos.
11. Testar só no desktop. É no celular que a lentidão mais aparece — e é lá que o cliente real vai comprar.
12. Otimizar sem refazer o fluxo de compra. Uma loja veloz com checkout quebrado é só uma loja veloz que não vende.

Quando chamar um especialista

Alguns cenários passam do que o painel resolve:

• Checkout lento mesmo com cache configurado corretamente.
• Servidor lento sob carga normal — ou em picos de promoção.
• Painel administrativo travado com poucos pedidos.
• Muitas tarefas agendadas atrasadas ou falhando.
• Erros depois de ativar minificação, CDN ou cache.
• CDN ou cache interferindo em sessão, carrinho ou login.
• Catálogo grande, com milhares de produtos, e origem do gargalo indefinida.
• Muitos plugins sem identificar qual pesa de verdade — nesse caso, um perfil técnico aponta o responsável com dados, não por palpite.

Se a sua loja já está no ar e lenta, o guia de diagnóstico de loja lenta mostra o caminho de investigação. E se você prefere entregar a análise a quem faz isso todos os dias:

Performance antes do lançamento, sem quebrar o que funciona.

• Linha de base, identificação de gargalos e correção na ordem certa
• Cache configurado sem tocar em carrinho e checkout
• Validação do fluxo de compra em desktop e mobile

Solicitar análise inicial da minha loja

Perguntas frequentes

Como saber se meu WooCommerce está lento?

Não dá para saber por impressão. Meça: abra as páginas públicas (home, produto) no PageSpeed Insights e registre os valores. Carrinho e checkout dependem de sessão real — teste-os no navegador, com um produto no carrinho e o DevTools aberto. Depois, percorra o fluxo de compra no celular, com dados móveis, como se fosse um cliente. Se as páginas dinâmicas — carrinho, checkout, painel — demoram ou travam, há um gargalo real. A comparação com a linha de base é o que separa sensação de diagnóstico.

Qual nota do PageSpeed Insights é boa para WooCommerce?

O PageSpeed Insights usa uma escala de 0 a 100, mas a nota não é o objetivo. O que importa são os valores das Core Web Vitals (LCP, INP e CLS) dentro dos limites oficiais — e a experiência real de compra. Uma home com nota alta não compensa um checkout lento. Use a ferramenta para enxergar problemas, não para perseguir um número.

Plugin de cache melhora WooCommerce?

Sim — o manual de performance do WordPress aponta o cache como o maior benefício pelo menor esforço. Um plugin de cache bem configurado reduz o trabalho do servidor em páginas repetidas, como home, categoria e produto. O requisito é a configuração correta: carrinho, checkout e minha conta excluídos do cache, e apenas um plugin ativo por vez.

Posso usar cache no carrinho e checkout?

Não — e não é opinião: a documentação oficial do WooCommerce orienta excluir Carrinho, Checkout e Minha conta do cache de página. Essas páginas mostram dados específicos de cada cliente e da sessão, e uma cópia fixa exibiria carrinho errado, estoque desatualizado ou dados de outra pessoa. Os plugins de cache sérios já fazem essa exclusão por padrão — confira depois de instalar e após atualizações.

CDN deixa WooCommerce mais rápido?

Pode deixar — depende. Uma CDN entrega arquivos estáticos (imagens, CSS, JavaScript) de servidores próximos ao visitante, e a documentação do WordPress diz que ela é mais eficaz combinada com um plugin de cache. Mas ela não resolve servidor lento nem plugin pesado: as partes dinâmicas, como carrinho e checkout, continuam dependendo do servidor original. Avalie depois de resolver a base.

Muitos plugins deixam WooCommerce lento?

Não é a quantidade, é o que cada um executa. Scripts e estilos carregados em todas as páginas, consultas ao banco, chamadas externas e tarefas agendadas — isso pesa. Um plugin útil e atualizado pesa menos que três plugins ociosos. A recomendação oficial é simples: remova o que você não usa, e avalie cada plugin pelo trabalho que ele faz, não pelo número na lista.

Qual tamanho de imagem usar no WooCommerce?

Não existe tamanho universal. A regra prática: use as dimensões que o layout realmente exibe, comprimidas, e deixe o WordPress cuidar do resto — ele gera os tamanhos de cada imagem e entrega a versão mais adequada a cada tela. Se o servidor suportar AVIF (confira em Ferramentas > Saúde do site), o formato pode reduzir até 50% o peso em relação ao JPEG na mesma qualidade.

Redis é necessário para WooCommerce?

Não para toda loja. O cache de objeto com Redis guarda em memória o resultado de consultas repetidas e ajuda em catálogos grandes ou lojas com muitas operações dinâmicas. Para uma loja nova, o cache de página bem configurado vem primeiro. Se a hospedagem oferece Redis, converse com o suporte sobre quando ativar; se não oferece, siga o processo normal.

O que fazer quando a home é rápida, mas o checkout é lento?

Isso é um sinal clássico: o problema não está no navegador, está no que o checkout depende — servidor, banco de dados, consultas, integrações de pagamento e frete. Confira a ordem deste guia. Comece pelo tempo de resposta da hospedagem, pelas ações agendadas e pelos scripts externos carregados na página de checkout. Se o cache está configurado (com o checkout excluído, como deve ser), a lentidão é do trabalho dinâmico — e pode exigir diagnóstico técnico.

---

Com a linha de base registrada, o cache configurado, as imagens tratadas e o fluxo de compra validado em desktop e mobile, a loja está pronta para a última etapa da série: o checklist de lançamento, que reúne todas as verificações finais antes de abrir as portas.

Se você precisar revisitar qualquer etapa anterior, o guia completo da série continua disponível como ponto de partida. A loja rápida, como a loja segura, é construída antes do lançamento — e você acabou de construir a sua.