A pergunta errada que custa dinheiro
Quando uma loja virtual está lenta, a decisão mais comum é: "Vamos fazer upgrade do servidor." Às vezes está certa — mas frequentemente é a resposta para a pergunta errada. Um servidor novo resolveria o problema se o problema fosse o servidor. Se for cache desativado, query sem índice ou script de terceiro carregado de forma síncrona, o upgrade apenas redistribui o custo sem eliminar o gargalo.
A pergunta correta é: onde está o tempo sendo gasto? E essa resposta precisa ser baseada em dados — não em intuição, não em "o plano de hosting está velho", não em "talvez seja o tema".
Conceito central: TTFB (Time to First Byte) é o indicador mais direto do desempenho do servidor + backend. Se o TTFB é baixo e a página ainda carrega devagar, o problema é frontend. Se o TTFB é alto, o problema está no servidor, no código de backend, ou no banco de dados.
Passo 1: medir o TTFB com precisão
Use o WebPageTest (webpagetest.org) ou o Chrome DevTools (aba Network, waterfall) para medir o TTFB de uma página de produto real — não a home. Páginas de produto têm queries mais complexas e refletem melhor o comportamento real.
Valores de referência:
- TTFB abaixo de 200ms: servidor respondendo bem. O problema, se existir, está no frontend.
- TTFB entre 200ms e 600ms: margem de atenção. Verificar cache e queries.
- TTFB acima de 600ms: problema claro de backend/infraestrutura. Investigar antes de qualquer outra coisa.
Passo 2: verificar se o cache está ativo
A causa mais comum de TTFB alto em e-commerces não é o servidor — é o cache desativado ou mal configurado. Em Magento, o Full Page Cache desativado pode elevar o TTFB de 80ms para 3s+ na mesma infraestrutura. Em WooCommerce, a ausência de cache de objeto e de página completa produz o mesmo efeito.
Verifique nos headers da resposta HTTP: X-Cache: HIT indica que o cache está funcionando. X-Cache: MISS em todas as requisições significa que nada está sendo cacheado.
O que pode estar desativando o cache
- Plugin de personalização ou A/B test que força bypass do cache por sessão
- Carrinho persistente sem separação de cache por estado de sessão
- Cookie de afiliado ou UTM sendo tratado como variável de cache
- Configuração incorreta de Varnish ou Redis expirando muito rápido
Passo 3: identificar queries lentas no banco
Se o TTFB é alto e o cache está funcionando (ou não há cache configurado), o próximo passo é o banco de dados. Ative o slow query log do MySQL/MariaDB com threshold de 1 segundo e analise as queries mais frequentes e mais lentas.
Padrões comuns em e-commerce:
- Listagem de produtos sem índice em
priceoustatus - Tabela de opções (wp_options no WordPress) varrida sem índice
autoload - JOINs desnecessários em queries de pedido com milhares de registros
- Queries N+1 em loops de renderização de produto
Como separar servidor de código
| Sintoma | Provável origem | Próximo passo |
|---|---|---|
| TTFB alto, cache HIT | Servidor subdimensionado | Testar com cache warm; comparar planos |
| TTFB alto, cache MISS | Cache desativado ou mal configurado | Ativar e configurar cache corretamente |
| TTFB baixo, LCP alto | Frontend — imagens, scripts | Auditar assets, lazy load, scripts síncronos |
| TTFB variável (às vezes rápido) | Cold start de cache ou conexões esgotadas | Verificar configuração de conexões do banco |
| Lento só em horário de pico | Recursos insuficientes (CPU/RAM) | Analisar métricas de servidor durante pico |
Regra prática: Antes de contratar um plano de servidor mais caro, ative o cache, analise as queries lentas e desative scripts de terceiros desnecessários. Na maioria dos casos, essas três ações sozinhas resolvem o problema sem custo adicional de infraestrutura.
Precisa de um diagnóstico de velocidade para sua loja?
Análise completa de TTFB, cache, queries lentas e scripts de terceiros — com relatório identificando se o problema é infraestrutura, código ou configuração.