Otimização de TTFB no WooCommerce: guia completo para lojas abaixo de 300 ms

Lojas WooCommerce perdem conversões durante picos de tráfego — Black Friday, produto viral, campanha paga chegando de uma vez — e, na maioria das auditorias que faço, o ponto de falha não é o bundle de frontend nem o peso das imagens. Ele está no servidor: Time to First Byte (TTFB) alto, provocado por execução PHP síncrona, idas não cacheadas ao banco e lógica de carrinho/sessão que o WordPress nunca foi arquitetado para atender em escala.

TTFB é o tempo entre a requisição do navegador e a chegada do primeiro byte da resposta. Numa página WooCommerce, PHP-FPM aceita a requisição, WordPress inicializa, plugins se conectam a init e wp_loaded, WooCommerce resolve sessão e carrinho, consultas dinâmicas (estoque, regras de preço, zonas de entrega) chegam ao MySQL e só então o servidor começa a transmitir HTML. Cada passo pode conter full-table scan, cache miss ou chamada externa bloqueante. Este guia cobre os mecanismos por trás de cada gargalo e correções concretas, da mais barata à mais invasiva.

Por que o TTFB do WooCommerce é estruturalmente diferente do TTFB do WordPress

Um post estático de blog pode ser servido inteiro do page cache — Varnish, cache FastCGI do Nginx ou um nó edge de CDN devolvem HTML sem tocar PHP ou MySQL. O WooCommerce quebra esse modelo, por desenho, em três tipos de página:

Páginas de carrinho e checkout precisam refletir estado em tempo real (itens, frete, validade de cupom), portanto cache de página inteiro é inseguro por padrão.
Páginas Minha conta são inerentemente por usuário e não podem ser cacheadas publicamente.
Páginas de catálogo com preço dinâmico (preço por perfil, flash sale, mensagens dependentes de estoque) invalidam regras ingênuas de cache.

É por isso que simplesmente aplicar uma configuração genérica de cache WordPress a uma loja WooCommerce produz carrinhos quebrados ou preços desatualizados, e não só ganhos de performance perdidos. Toda otimização abaixo precisa respeitar essa divisão entre conteúdo cacheável e não cacheável.

Diagnosticando TTFB antes de otimizá-lo

Não adivinhe. Otimizar no escuro desperdiça tempo de engenharia na camada errada.

Como medir onde o TTFB está sendo gasto de fato?

Adicione headers Server-Timing em cada etapa do bootstrap (banco, object cache, render de template) e leia-os na aba Network do navegador ou com curl -w:

// mu-plugins/server-timing.php
add_action('plugins_loaded', function () {
    $GLOBALS['__ts_start'] = microtime(true);
});

add_action('shutdown', function () {
    if (!headers_sent() && isset($GLOBALS['__ts_start'])) {
        $elapsed = (microtime(true) - $GLOBALS['__ts_start']) * 1000;
        header(sprintf('Server-Timing: wp-total;dur=%.2f', $elapsed));
    }
});

Para uma checagem rápida em CLI, sem overhead do navegador:

curl -o /dev/null -s -w "DNS: %{time_namelookup}s | TCP: %{time_connect}s | TTFB: %{time_starttransfer}s | Total: %{time_total}s\n" https://store.example.com/cart/

Como encontrar plugin ou query lenta?

Instale Query Monitor num ambiente de staging com volume de dados parecido com produção (não uma instalação nova com 10 produtos de teste; comportamento de índice e cache hit só aparece em escala realista). Observe:

O painel Queries, ordenado por tempo e filtrado por componente, que atribui consultas lentas ao plugin ou função de tema que as disparou.
O painel Hooks & Actions em init, wp e template_redirect: plugins mal escritos costumam executar lógica cara incondicionalmente em toda requisição, inclusive para bots e páginas não cacheáveis.
A contagem Database Queries → Duplicate Queries, forte sinal de padrões N+1.

Em produção, evite Query Monitor ao vivo; habilite temporariamente o slow query log do MySQL e correlacione com tráfego da REST API e storefront.

# my.cnf — apenas para janela temporária de diagnóstico
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 0.2
log_queries_not_using_indexes = 1

Pilar 1: cache de objetos com Redis (não apenas page cache)

Page cache e object cache resolvem problemas distintos; confundi-los é o erro arquitetural mais comum em performance WooCommerce.

Camada	O que cacheia	Resolve	Não resolve
Page cache (Varnish, FastCGI cache, CDN edge)	Resposta HTML renderizada inteira	Requisições idênticas repetidas a páginas estáticas/de catálogo	Carrinho, checkout, conteúdo logado ou por usuário
Object cache (Redis/Memcached)	Objetos PHP, resultados de consultas, transients	Consultas e cálculos caros repetidos dentro ou entre requisições PHP	Nada se o padrão de query subjacente for o gargalo (índices ruins, N+1)
OPcache	Opcode PHP compilado	Reparse/recompilação de fontes PHP a cada requisição	Trabalho preso ao banco; é alívio de CPU, não de I/O
CDN edge cache	Assets estáticos + HTML dinâmico cacheável em PoPs próximos	Latência de rede e carga de origem para páginas cacheáveis	Páginas não cacheáveis (carrinho/checkout)

Por padrão, o object cache do WordPress é não persistente: vive apenas durante uma requisição e é descartado. Cada nova requisição reconstrói do zero as mesmas buscas de options, termos e meta. Em uma loja com tráfego concorrente, isso significa MySQL recebendo as mesmas leituras de wp_options e wp_postmeta milhares de vezes por minuto, sem reutilização entre requests.

O que um object cache persistente realmente corrige?

Ele converte leituras MySQL repetidas (options, transients, meta de produtos, relacionamentos de termos) em lookups Redis abaixo de milissegundo compartilhados por todos os workers PHP-FPM. É a mudança de maior alavancagem na maioria das instalações WooCommerce, porque core WordPress e WooCommerce já chamam extensivamente wp_cache_get()/wp_cache_set(); basta colocar backend persistente por trás dessas chamadas.

Configuração com o drop-in redis-cache:

wp plugin install redis-cache --activate
wp redis enable

// wp-config.php
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_TIMEOUT', 1);
define('WP_REDIS_READ_TIMEOUT', 1);
define('WP_REDIS_DATABASE', 0);
define('WP_CACHE', true);

Confirme que ele está conectado de verdade, não caindo silenciosamente no cache não persistente:

wp redis status

Redis vs. Memcached no WooCommerce — qual usar?

Redis suporta persistência, introspecção de expiração de chaves e, de modo decisivo para WooCommerce, grupos de cache com flush por padrão, importante quando um plugin precisa invalidar todas as chaves de produto após atualização de estoque sem limpar o cache inteiro. Por isso é o padrão de facto para object cache em WooCommerce.
Memcached pode ser marginalmente mais rápido em alguns benchmarks de gets puros de chave-valor, mas não tem persistência e possui ferramentas de introspecção mais fracas. Use-o apenas se Redis não estiver disponível no hosting.

A armadilha da sessão WooCommerce

Por padrão, WooCommerce guarda sessões de clientes em wp_woocommerce_sessions, uma tabela de banco, não no object cache. Com atividade concorrente de carrinho, ela recebe escritas constantes — cada mutação atualiza sessão — e é fonte comum de contenção de escrita que o object cache Redis sozinho não resolve, porque sessões ignoram o caminho do cache salvo configuração explícita. Se a implementação de WC_Session_Handler do host suportar, direcione sessões diretamente ao Redis e audite woocommerce_cookie_expiration e intervalos de cron de limpeza, evitando o acúmulo de sessões obsoletas.

Pilar 2: arquitetura de banco — índices, queries N+1 e bloat de autoload

Object cache esconde queries lentas; não as corrige. Se uma consulta é lenta em cache miss, caches frios (pós-deploy, pós-flush ou bot rastreando URLs long-tail) ainda causam picos de TTFB.

O que causa padrões N+1 no WooCommerce?

O caso clássico é um hook de renderização de carrinho ou shop loop que chama get_post_meta() ou getter do data store WooCommerce dentro de um loop de produtos, em vez de aquecer o cache antes. Cada iteração dispara um SELECT separado em wp_postmeta, não uma query em lote. Isso é muito comum em:

Templates de tema customizados que percorrem resultados de wc_get_products() e chamam $product->get_meta('_custom_field') por item sem update_postmeta_cache aquecido.
Plugins de terceiros em woocommerce_before_shop_loop_item que fazem suas próprias queries de meta ou termos por produto.
Plugins de badge/label que verificam atributo ou estoque por produto sem batching.

Padrão de correção: aqueça o cache de meta antes do loop:

$product_ids = wp_list_pluck($products, 'ID');
update_meta_cache('post', $product_ids); // batches all postmeta into one query
update_object_term_cache($product_ids, 'product');

Como corrigir full table scans em wp_postmeta?

wp_postmeta é uma tabela EAV (entity-attribute-value) sem índice composto padrão em (meta_key, meta_value) — há apenas meta_id (primário) e post_id. Qualquer query que filtre ou ordene por meta_value para determinada meta_key, como filtro de faixa de preço ou atributo customizado, faz scan proporcional ao tamanho da tabela.

Duas formas de remediar:

Adicionar um índice composto direcionado ao padrão de query de maior tráfego:

ALTER TABLE wp_postmeta
  ADD INDEX idx_meta_key_value (meta_key(191), meta_value(100));

Teste em staging com EXPLAIN: indexar em excesso deixa escritas mais lentas e aumenta a tabela. Adicione índices apenas para meta keys realmente filtradas/ordenadas em padrões confirmados pelo slow query log.

Mover dados estruturados de alta leitura para fora do modelo EAV e para tabela customizada com colunas tipadas e índices adequados — indicado para agregados de avaliação, estoque consultado por sistemas externos ou faixas de preço customizadas, lidas muito mais que escritas.

HPOS (High-Performance Order Storage) — é realmente mais rápido?

Sim, por estrutura. HPOS troca o modelo legado, que armazena pedidos como linhas em wp_posts com metadata espalhada em wp_postmeta, por tabelas dedicadas (wp_wc_orders, wp_wc_order_operational_data, wp_wc_order_addresses etc.) com colunas tipadas e índices de status, cliente e totais. Isso elimina classes de padrões N+1 e scans completos que afetavam consultas de pedidos, filtro da lista administrativa e relatórios.

Considerações de performance da migração:

O processo de sync é caro em históricos grandes: HPOS executa migração em background e mantém tabelas legadas e novas sincronizadas durante a transição (compatibility mode), criando carga adicional de escrita até desativar o modo e usar apenas HPOS.
Execute a migração em janelas de baixo tráfego e monitore o Action Scheduler, pois o sync é despachado por ele.
Audite compatibilidade HPOS de plugins de terceiros antes de migrar: plugins que consultam wp_postmeta diretamente para dados de pedidos, em vez de usar CRUD API do WooCommerce, quebrarão silenciosamente ou lerão dados obsoletos. Verifique compatibilidade declarada por wc_get_container() ou pela tela de HPOS em Status.
Depois de estável, desativar compatibility mode remove a sobrecarga de dupla escrita; é aí que aparece o benefício de TTFB em queries pesadas de pedidos (administração, relatórios, assinaturas).

Action Scheduler: o assassino silencioso de TTFB

Action Scheduler alimenta o processamento de fundo do WooCommerce — webhooks, renovações de assinatura, sync de estoque, filas de e-mail — e armazena jobs em wp_actionscheduler_actions/wp_actionscheduler_logs. Dois modos de falha atingem o TTFB diretamente:

Crescimento descontrolado da fila: ações falhas ou com retry infinito se acumulam, algo comum com endpoint de webhook quebrado ou integração mal configurada, levando as tabelas a milhões de linhas. Elas têm índices, mas uma tabela inflada aumenta o custo de todo poll do scheduler e, se consultada inline, vaza para o tempo da requisição.
Dispatch de cron rodando inline no page load: WP-Cron é pseudo-cron, disparado pela requisição de visitante quando wp-cron.php não rodou recentemente. Sem cron de sistema, uma requisição aleatória pode disparar sincronamente lote de ações antes de enviar a resposta.

Correções:

// wp-config.php — desabilite o pseudo-cron disparado por carregamentos de página
define('DISABLE_WP_CRON', true);

# cron real de sistema, desacoplado das requisições de visitantes
*/1 * * * * curl -s https://store.example.com/wp-cron.php >/dev/null 2>&1

Depois, audite e elimine periodicamente ações antigas ou falhas:

wp action-scheduler clean --batch-size=500 --status=complete
wp action-scheduler clean --batch-size=500 --status=failed

Defina action_scheduler_retention_period menor que o padrão de 30 dias quando integrações gerarem alto volume e um mês de histórico não for necessário para debug.

Bloat de opções autocarregadas

Toda option em wp_options com autoload = 'yes' é carregada na memória em toda requisição, antes de roteamento ou template, independentemente de a página precisar dela. Plugins que guardam arrays serializados grandes, transients salvos incorretamente com autoload ou resíduos de feature flags de plugins desativados podem levar o payload a vários megabytes e acrescentar tempo mensurável a todo bootstrap.

Audite o peso de autoload atual:

SELECT option_name, LENGTH(option_value) AS size_bytes
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size_bytes DESC
LIMIT 25;

-- payload total autocarregado — uma loja saudável deve ficar bem abaixo de 1 MB
SELECT SUM(LENGTH(option_value)) AS total_bytes
FROM wp_options
WHERE autoload = 'yes';

Ofensores frequentes: transients expirados com autoload = 'yes' em vez de 'no', dados de revisão de page builders e options órfãs deixadas por plugins desativados. Para transients, a própria API WordPress só remove autoload corretamente quando não há object cache persistente; com Redis, transients vão para o object cache, outra razão pela qual ele indiretamente reduz bloat de autoload.

wp transient delete-expired
wp option list --autoload=yes --format=table  # audit before deleting anything

Nunca apague options em massa sem saber qual plugin as possui: algumas realmente precisam de autoload para correção, como configuração global lida em toda requisição.

Pilar 3: performance no nível PHP — OPcache e ajuste de PHP-FPM

Banco e cache tratam latência de I/O. OPcache e PHP-FPM tratam latência presa a CPU e concorrência — problema diferente, correção diferente.

Configuração OPcache para cargas WooCommerce

Sem OPcache, toda requisição reanalisa e recompila toda a árvore PHP — core WordPress, WooCommerce, plugins ativos e tema — puro desperdício, pois o código não muda entre deploys.

; php.ini
opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0
opcache.revalidate_freq=0

validate_timestamps=0 é a configuração importante de produção: OPcache para de consultar mtime de arquivos a cada request e confia no cache. Isso exige reset explícito do OPcache em todo deploy (opcache_reset() ou reload do servidor), ou código antigo continuará servido. max_accelerated_files precisa de margem acima da contagem real: WooCommerce com conjunto moderado de plugins frequentemente passa de 10.000 arquivos PHP; pouco espaço causa churn de cache e recompilação em pleno tráfego.

Ajuste do pool PHP-FPM — por que defaults causam picos de TTFB sob carga

Os defaults pm = dynamic da maioria dos hosts atendem WordPress genérico, não o custo maior por requisição do WooCommerce (sessão/carrinho, cálculo de imposto e frete, gateways no checkout). Pools subdimensionados fazem requisições entrarem em fila aguardando worker PHP-FPM livre; toda essa espera aparece como TTFB, sem surgir no profiling de aplicação porque o request nem começou.

; www.conf
pm = dynamic
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 15
pm.max_requests = 500

Dimensione pm.max_children pela RAM disponível ÷ footprint médio do processo PHP (meça; processos de checkout são mais pesados que páginas estáticas), não por default genérico.
pm.max_requests recicla workers para proteger contra memory leaks em plugins de longa execução; sem ele, bloat gradual degrada o processo até ser morto e reiniciado de modo menos previsível.
Se o log PHP-FPM disser server reached pm.max_children setting, é sinal direto e inequívoco de que a fila está inflando TTFB; não é hipótese, é evidência registrada.

Pilar 4: cache edge e de página para a superfície cacheável

Depois de object cache e trabalho de query estarem sólidos, a alavanca restante é evitar inteiramente a execução PHP nas páginas cacheáveis.

Quais páginas WooCommerce são seguras para cachear na edge?

Tipo de página	Cacheável?	Observações
Loja / categoria / listagem	Sim, com TTL curto	Invalide em alteração de estoque/preço por hooks de purge, não apenas expiração
Produto único	Sim	Mesma exigência de invalidação; cuidado com widgets “vistos recentemente” por visitante
Carrinho	Não (padrão)	Reflete sessão em tempo real
Checkout	Não	Sensível a pagamento/sessão; alguns hosts permitem micro-cache com bypass estrito por cookie, alto risco se errado
Minha conta	Não	Por usuário
Páginas estáticas (sobre, políticas)	Sim, agressivamente	Sem dependência dinâmica

Como ignorar o cache corretamente para visitantes logados/com carrinho?

Faça gate pelos cookies que WooCommerce realmente define, não por uma checagem ampla de “logado” que também exclui sessões com apenas admin bar:

# Bypass condicional de cache na edge/proxy reverso
if ($http_cookie ~* "woocommerce_items_in_cart|wp_woocommerce_session_") {
    set $skip_cache 1;
}
if ($http_cookie ~* "wordpress_logged_in_") {
    set $skip_cache 1;
}

O erro a evitar é bypass em presença de qualquer cookie, inclusive cookies de analytics/marketing sem relação com estado WooCommerce, derrotando silenciosamente o cache da maioria do tráfego anônimo que deveria ser cacheável.

E cache CDN edge para pessoas logadas em escala?

Em lojas com alto tráfego logado (membership, B2B, atacado), regras ingênuas de “sem cache se logado” fazem a maioria das requisições chegar à origem. Setups avançados usam edge-side includes (ESI) ou fragment caching: cacheiam a casca da página (grid de produto, conteúdo estático) na edge e carregam só fragmentos realmente personalizados (contador do mini-carrinho, saudação da conta) via AJAX leve contra endpoint rápido e cacheado, não por bootstrap completo do WordPress. Isso separa “este HTML pode ser cacheado?” de “este visitante tem dado personalizado?”, que é a restrição real.

Causas comuns de TTFB e correções — referência rápida

Sintoma	Causa provável	Correção
TTFB bom em visitas repetidas, lento com cache frio	Sem object cache persistente	Instale o drop-in Redis object cache
Picos de TTFB correlacionam com tráfego parecido com cron	WP-Cron roda inline em page loads	Desative pseudo-cron e use cron de sistema
Lentidão constante apenas em categoria/filtro	Índice composto ausente em `wp_postmeta`	Adicione índice direcionado à `meta_key` filtrada
Lentidão cresce com catálogo	Queries N+1 no shop loop	Pré-aqueça cache de meta/termos em lote antes do loop
TTFB piora em carga concorrente, bom isoladamente	Pool PHP-FPM pequeno	Ajuste `pm.max_children`, consulte log por `reached pm.max_children`
Toda request fica mais lenta após plugin	Bloat de opções autocarregadas	Audite o payload autoload de `wp_options`
Telas administrativas de pedidos lentas, storefront bom	Armazenamento legado em posts	Migre para HPOS; valide plugins antes
Action Scheduler tem centenas de milhares de linhas	Ações falhas/retrying não foram limpas	`wp action-scheduler clean`, corrija integração de origem
Primeiro request depois de deploy muito lento	OPcache frio após reset	Aqueça caminhos críticos após deploy; esperado e limitado

Com object cache, queries indexadas, HPOS, fila Action Scheduler limpa, PHP-FPM ajustado e cache edge na superfície cacheável, lojas WooCommerce de alto tráfego podem sustentar TTFB abaixo de 300ms — inclusive no checkout, em que o caminho não cacheável é o que mais importa para conversão. Números exatos de antes/depois dependem da linha de base de cada loja e devem ser medidos contra ela, não presumidos.

FAQ técnico

WooCommerce suporta full-page cache pronto para uso?

Não. WooCommerce não traz uma camada de page caching porque estado de carrinho e checkout é inerentemente dinâmico. Page cache é implementado no hosting/infraestrutura (Varnish, cache FastCGI Nginx ou CDN) com regras explícitas de bypass para carrinho, checkout e conta, ou por plugin de cache consciente de WooCommerce que aplica essas exclusões automaticamente.

Redis object cache é seguro em setup WooCommerce com vários servidores?

Sim, e é necessário nesse cenário: uma instância Redis compartilhada por todos os web servers fornece visão consistente de cache. Sem object cache persistente compartilhado, cada servidor mantém cache restrito à requisição, os cache hits efetivamente se dividem pelo número de servidores e a invalidação após uma atualização de estoque não se propaga pela frota.

Adicionar índices a wp_postmeta quebra WooCommerce ou atualizações de plugins?

Não. WooCommerce e WordPress core não gerenciam a lista de índices dessa tabela além dos padrões; índices customizados persistem nas atualizações. O risco está exclusivamente na escrita: mais índices tornam INSERT/UPDATE em wp_postmeta um pouco mais lentos, logo adicione somente os justificados por evidência confirmada de slow query, não especulativamente.

Devo migrar imediatamente para HPOS ou o armazenamento legado ainda é viável?

HPOS é a direção que o core WooCommerce está padronizando e resolve problemas estruturais reais de performance de query no modelo baseado em posts. A ressalva é o ecossistema de plugins: audite todo plugin que toca pedidos em busca de compatibilidade HPOS declarada antes da migração, pois plugins que consultam wp_postmeta diretamente podem se comportar mal silenciosamente depois. Em lojas com poucas integrações customizadas de pedidos, migrar mais cedo tem risco menor que esperar.

Posso cachear totalmente a página de checkout?

Não com full-page caching padrão: checkout renderiza totais específicos da sessão, métodos de pagamento salvos e nonces de segurança. O possível é cachear a casca da página — layout e texto estático — enquanto campos dinâmicos carregam via AJAX contra endpoints rápidos e estreitos; isso reduz trabalho PHP por requisição sem servir dados transacionais antigos.

Por que o TTFB dispara especificamente em picos de tráfego, em vez de permanecer proporcionalmente lento?

É o padrão de fila de workers PHP-FPM: abaixo do teto de concorrência do pool, requisições executam imediatamente e TTFB reflete processamento. Quando requisições simultâneas passam de pm.max_children, as adicionais esperam worker livre; essa espera é invisível ao profiling da aplicação, mas totalmente visível no TTFB. Parece um penhasco, não uma inclinação gradual, porque é limite rígido de capacidade.

Ativar object cache elimina a necessidade de trabalho de indexação de banco?

Não. Object cache reduz a frequência com que uma query chega ao MySQL, mas todo cache miss — cache frio após deploy, eviction sob pressão de memória ou query com parâmetros únicos que não pode ser cacheada — ainda executa a consulta na velocidade nativa. Um full table scan continua sendo full table scan em cache miss; object cache reduz a frequência de queries lentas, não o custo inerente delas.