--- title: "WooCommerce lento: otimização de velocidade na ordem certa" id: "588" type: "post" slug: "otimizacao-velocidade-woocommerce" published_at: "2026-10-06T20:00:50+00:00" modified_at: "2026-10-06T20:22:47+00:00" url: "https://danielpazwp.com/pt/otimizacao-velocidade-woocommerce/" markdown_url: "https://danielpazwp.com/pt/otimizacao-velocidade-woocommerce.md" excerpt: "Como resolver um WooCommerce lento: exceções de cache para carrinho e checkout, cart fragments, cache de objetos, HPOS, banco e páginas de produto." taxonomy_category: - "Performance" --- [Performance](https://danielpazwp.com/pt/category/performance-pt/) 8 min de leitura # WooCommerce lento: otimização de velocidade na ordem certa Como resolver um WooCommerce lento: exceções de cache para carrinho e checkout, cart fragments, cache de objetos, HPOS, banco e páginas de produto. Publicado **06/10/2026**8 min de leitura [Escrito porDaniel Paz](https://danielpazwp.com/pt/author/daniel-paz/) Para resolver um WooCommerce lento, parta de um fato: a loja tem dois tipos de página. As de catálogo (home, categorias, produtos) podem sair do cache de página como qualquer página WordPress. Carrinho, checkout e minha conta não podem, porque mudam para cada cliente. A otimização de velocidade do WooCommerce, então, é cachear o catálogo com força, excluir carrinho, checkout e minha conta desse cache e deixar rápida a parte sem cache, com cache de objetos persistente, banco de dados enxuto, High-Performance Order Storage (HPOS) e o mínimo possível de requisições de cart fragments. Depois vêm imagens, scripts e tags de terceiros nas páginas de produto. A maioria das lojas lentas que eu audito é lenta por estrutura, não por causa de um plugin ruim. Este guia segue a ordem em que eu trabalho numa loja WooCommerce e faz parte do guia de [como acelerar o WordPress](https://danielpazwp.com/pt/como-acelerar-wordpress/) . Se o problema é o relatório de Core Web Vitals reprovado no Search Console, leia também [Core Web Vitals no WooCommerce](https://danielpazwp.com/pt/core-web-vitals-woocommerce/) , que vai métrica por métrica. ## O que deixa o WooCommerce lento? Um blog entrega o mesmo HTML para quase todo mundo. Uma loja tem sessão, carrinho, preço que muda com regra de imposto e moeda, estoque e cliente logado. Cada um desses itens dificulta o cache. Quando a requisição não acha cache, o WordPress carrega o WooCommerce, consulta produtos e seus metadados, confere a sessão e monta a página em PHP. Numa loja com muitos produtos, variações e extensões, esse caminho é longo. O segundo motivo são os plugins. Loja costuma acumular extensão de frete, pagamento, avaliações, lista de desejos, filtros, upsell e tags de marketing, e cada uma pode somar consultas ao banco, scripts e requisições externas. ## O que o cache de página deve incluir e excluir? Acerte isto primeiro, porque é o que decide quantas requisições chegam ao PHP. | Página ou requisição | Cachear? | Por quê | | --- | --- | --- | | Home, categorias e produtos para visitante com carrinho vazio | Sim | Mesmo HTML para todos | | Carrinho, checkout e minha conta | Não | Conteúdo pessoal e fluxo de pagamento | | Qualquer requisição com os cookies de carrinho ou sessão (woocommerce_items_in_cart, woocommerce_cart_hash, wp_woocommerce_session_*) | Em geral não, ou servir a página em cache sem as partes pessoais | O visitante tem carrinho | | Requisições com add-to-cart na query string | Não | Elas mudam estado | | Endpoints ?wc-ajax= | Não | São dinâmicos por natureza | | Cliente logado | Depende da camada de cache | Muitas configurações pulam o cache para eles | A maioria dos plugins de cache que conhecem o WooCommerce e das hospedagens gerenciadas já configura essas exceções. Confira mesmo assim, principalmente depois de mudar a URL do carrinho ou do checkout ou de adicionar um segundo idioma, porque a exceção costuma estar presa à página, e não à função dela. Se as campanhas colocam UTM em todo link, garanta que o cache ignore esses parâmetros em vez de criar uma entrada nova ou pular o cache. Para entender como cache de página, de objetos e de borda se encaixam, leia [page cache, object cache e edge cache](https://danielpazwp.com/pt/page-cache-object-cache-edge-cache-qual-voce-precisa/) . ## O que são cart fragments e vale desativar? Cart fragments é o mecanismo clássico do WooCommerce para manter atualizado o mini carrinho do cabeçalho em páginas cacheadas. O script `wc-cart-fragments` faz uma requisição AJAX para `?wc-ajax=get_refreshed_fragments` depois que a página carrega, e essa requisição nunca é cacheada. Resultado: WordPress e WooCommerce rodam a cada visualização de página. As versões recentes do WooCommerce deixaram de carregar esse script em todas as páginas por padrão; ele entra onde o widget legado de carrinho precisa. Na prática ainda encontro o script em todo lugar, porque tema e plugin fazem o enqueue por conta própria. Meu jeito de tratar: - Procurar na aba de rede requisições `get_refreshed_fragments` em páginas que não mostram carrinho. - Se o carrinho do cabeçalho do tema depende dele, manter, mas tirar das páginas em que o cabeçalho não mostra contador, ou trocar pelo bloco de mini carrinho, que funciona de outro jeito. - Se ninguém precisa, remover o script. Depois testar o adicionar ao carrinho numa página cacheada e confirmar que o contador ainda atualiza onde aparece. Essa é uma das mudanças que também meço do lado do servidor, porque tirar uma requisição sem cache de cada visualização de página baixa a carga de PHP nos picos de tráfego. ## O WooCommerce precisa de cache de objetos persistente? Para loja com tráfego de verdade, precisa. Sem cache de objetos persistente, o WordPress guarda resultado de consulta só durante uma requisição. Com Redis ou Memcached, opções, dados de produto, consultas de termos e transients ficam em memória entre requisições, e toda requisição sem cache fica mais curta: carrinho, checkout, minha conta e painel. Dois cuidados que aprendi em auditoria: o cache de objetos só ajuda se a hospedagem der memória suficiente para ele, e as sessões de cliente do WooCommerce ficam numa tabela própria no banco, então o cache de objetos não substitui um banco saudável. Configuração e testes estão no guia de [Redis object cache no WordPress](https://danielpazwp.com/pt/redis-object-cache-wordpress/) . ## Vale migrar para o High-Performance Order Storage? O HPOS guarda os pedidos em tabelas dedicadas, em vez de espalhá-los por `wp_posts` e `wp_postmeta`. As consultas de pedido ficam mais simples e as tabelas de posts e postmeta ficam menores, o que ajuda tanto a gravação no checkout quanto as telas de pedido do painel. Lojas novas já usam HPOS por padrão nas versões recentes; lojas antigas precisam migrar. A opção fica em WooCommerce > Configurações > Avançado > Recursos. Minha rotina de migração: - Confirmar que todas as extensões ativas declaram compatibilidade com HPOS. O WooCommerce mostra um aviso quando alguma não declara. - Ligar o modo de compatibilidade para os pedidos sincronizarem nos dois armazenamentos e esperar a sincronização terminar. - Trocar o armazenamento principal para HPOS em staging e testar checkout, reembolso, e-mails de pedido e qualquer integração que leia pedidos (ERP, nota fiscal, frete). - Repetir em produção, acompanhar por um tempo e então desligar o modo de compatibilidade. Deixar a sincronização ligada para sempre significa gravar cada pedido duas vezes. ## O que mais deixa lenta a parte sem cache? Depois de cache e HPOS, é nas requisições sem cache que a loja perde tempo. As causas de sempre: - Opções autoload grandes em `wp_options`, carregadas em toda requisição. O WordPress 6.6 trouxe uma verificação de tamanho de autoload na Saúde do Site. O guia de [otimização do banco de dados do WordPress](https://danielpazwp.com/pt/otimizacao-banco-de-dados-wordpress/) mostra como achar as linhas pesadas. - Transients expirados e uma tabela `wp_actionscheduler_actions` com anos de ações concluídas. - Filtros de produto que rodam meta queries sem índice em catálogos grandes. - Extensões chamando API externa (cálculo de frete, serviço de imposto, verificação de licença) durante a requisição. - Poucos PHP workers para o tráfego do checkout, e as requisições fazem fila no servidor. O Query Monitor, em staging ou só para um usuário administrador, mostra as consultas lentas e as chamadas HTTP externas de cada requisição. É por ali que começo quando o TTFB do checkout está alto. ## Como acelerar as páginas de produto e de categoria? São as páginas que o Google mais mede, e quase tudo que vale para qualquer página WordPress vale aqui. O que é específico de loja: - Galeria de produto. A imagem principal costuma ser o elemento LCP. Não aplique lazy load nela, entregue no tamanho em que aparece e em WebP ou AVIF, e confira se o script da galeria não troca a imagem depois do carregamento. - Seletores de variação e zoom da galeria acrescentam JavaScript que roda na interação. Teste o INP num produto com muitas variações, não num produto simples. - Páginas de categoria com filtros. Plugin de filtro costuma carregar script e CSS completos em todas as páginas. Restrinja à loja e às categorias. - Tags de terceiros. Pixel de anúncio, widget de avaliações e chat muitas vezes somam mais JavaScript que o próprio WooCommerce. Revise com o time de marketing e tire as que ninguém consulta. O detalhe por métrica está em [Core Web Vitals no WooCommerce](https://danielpazwp.com/pt/core-web-vitals-woocommerce/) e no guia de [como corrigir o INP no WordPress](https://danielpazwp.com/pt/inp-no-wordpress/) . ## O que medir na otimização de velocidade do WooCommerce? Meça catálogo e checkout separados, porque eles falham por motivos diferentes: - LCP, INP e CLS de campo para os templates de produto e categoria, no Search Console ou no CrUX - TTFB numa página de produto em cache e numa requisição sem cache de carrinho ou checkout - quantidade de requisições `wc-ajax` sem cache por visualização de página - consultas lentas e chamadas HTTP externas no checkout, pelo Query Monitor - tempo de carregamento da lista de pedidos no painel, antes e depois do HPOS Se o que dói é o painel, escrevi um guia separado sobre [admin do WooCommerce lento](https://danielpazwp.com/pt/admin-woocommerce-lento/) . ## Perguntas frequentes ### Dá para cachear o checkout do WooCommerce? Não. O checkout precisa ser gerado para cada cliente. O caminho é deixar rápida a requisição sem cache, com cache de objetos, banco enxuto, PHP workers suficientes e poucas chamadas externas. ### Preciso de uma hospedagem específica para WooCommerce? Você precisa de uma hospedagem que entenda as exceções de cache acima, ofereça Redis ou Memcached e tenha PHP workers suficientes para os picos. Algumas vendem isso como hospedagem WooCommerce; confira os recursos, não o rótulo. ### Desativar cart fragments é seguro? É seguro quando nenhum elemento visível depende deles. Depois de remover, teste o fluxo de adicionar ao carrinho e o carrinho do cabeçalho numa página cacheada. Se a sua loja perde tempo no checkout ou reprova nos Core Web Vitals nas páginas de produto e você quer alguém para achar a causa, é exatamente esse o meu trabalho como [consultor WooCommerce](https://danielpazwp.com/pt/consultor-woocommerce/) : diagnostico a loja, priorizo as correções e confiro tudo com dados de campo. Quando o plano precisa de mão na massa, [a equipe da WebOption faz a implementação](https://weboption.com.br/performance-seguranca/) . [Trabalhe com o Daniel](https://danielpazwp.com/pt/#book) [Mais em Performance](https://danielpazwp.com/pt/category/performance-pt/) [Sobre o autorPágina do autor](https://danielpazwp.com/pt/author/daniel-paz/) ## Artigos relacionados [Todos os artigos](https://danielpazwp.com/pt/artigos/) [Performance out 2026Page cache vs object cache vs edge cache: qual você precisa](https://danielpazwp.com/pt/page-cache-object-cache-edge-cache-qual-voce-precisa/) [Performance out 2026Core Web Vitals: dados de campo vs laboratório](https://danielpazwp.com/pt/core-web-vitals-dados-de-campo-vs-laboratorio/) [Performance out 2026WordPress lento: os motivos estruturais e a ordem para corrigir](https://danielpazwp.com/pt/por-que-seu-wordpress-e-lento-motivos-estruturais/)