Pra a maioria das lojas, o tempo de cálculo do Frete Offline é instantâneo. Mas com tabelas muito grandes ou servidores limitados, pode dar pra notar — especialmente em horários de pico.
Quando isso acontece, há cinco coisas que dão resultado, em ordem de impacto.
1. Modo banco de dados (resolve quase sempre)
A medida mais efetiva. Em tabelas grandes (1.000+ linhas) o ganho chega a 90% no tempo de cálculo.
O modo padrão lê o CSV inteiro a cada cotação. O modo banco de dados consulta o MySQL com índice por CEP — busca direta, sem varredura.
Detalhes e como ativar em Modo banco de dados.
2. Limitar resultados
A configuração Limitar resultados faz o plugin parar de procurar assim que encontra a primeira linha que casa.
Útil quando sua tabela tem regras sobrepostas (várias linhas que poderiam ser válidas pro mesmo cenário) e você quer só uma exibida.
Sem essa opção, o plugin checa todas as linhas até o fim, mesmo já tendo achado correspondências.
3. Otimizar o CSV
Tabelas mal otimizadas têm linhas redundantes que poderiam estar agrupadas. Exemplos:
- Várias linhas com o mesmo custo pra CEPs próximos → uma faixa única.
- Faixas de peso minúsculas (0-1, 1-2, 2-3, ...) com mesmo custo → faixas maiores.
Cada linha removida economiza um ciclo de validação por cotação.
4. Cortar peso máximo desnecessário
Se você vende roupa, não precisa de tabela cobrindo até 50 kg.
Tabelas que vão até pesos absurdos costumam ter dezenas de linhas inúteis pra um catálogo leve. Limitar o peso máximo da tabela ao real do seu catálogo pode reduzir o arquivo em 60-80%.
Se um cliente tentar comprar mais peso do que a tabela cobre, o método simplesmente não aparece — o que é o comportamento desejado de qualquer forma.
5. Dividir em áreas de entrega
Se sua tabela cobre o Brasil inteiro mas você atende com regras muito diferentes por região, vale dividir:
- Tabela 1: Sul + Sudeste (área de entrega "Sul/SE").
- Tabela 2: Norte + Nordeste (área de entrega "N/NE").
- Tabela 3: Centro-Oeste (área "CO").
Cada cliente cai em uma área só, com tabela menor. Resultado: cálculo mais rápido por requisição.
Áreas mais específicas (estados, cidades) precisam vir acima das mais amplas. Senão a primeira que casa é a ampla, e a específica nunca é alcançada.
Combinando estratégias
Em casos extremos (tabela com 100k+ linhas), o ideal é modo banco de dados + limite de resultados + dividir em áreas. Cada um adiciona melhoria sobre o anterior.
Servidor lento é outro problema
Se mesmo com tabela pequena o cálculo está lento, o gargalo pode ser:
- Hospedagem barata com I/O lento.
- Plugins extras rodando filtros sobre cada cálculo de frete.
- WooCommerce com banco de dados sem manutenção.
Antes de mexer na tabela, ative Debug Log e veja quanto tempo cada cálculo demora. Se o número for inconsistente entre execuções, é o ambiente — não a tabela.