De 40 para 98 PageSpeed: como transformei uma loja WooCommerce

Cada segundo conta no e-commerce. Para uma loja WooCommerce que processa milhares de encomendas por mes, isso traduz-se diretamente em receita perdida. Este estudo de caso documenta como, na WPPoland, transformei uma loja europeia de móveis e-commerce em dificuldades, de uma pontuação PageSpeed de 40 para 98 - e o que isso significou para os seus resultados financeiros.

#Loja de móveis em WooCommerce na Europa

O meu cliente opera uma loja de móveis online de médio porte que serve clientes na Europa Central e Ocidental. Com um catálogo de mais de 3500 produtos e 12 000 imagens de produtos, muito estava em jogo. A sua loja WooCommerce tinha crescido organicamente ao longo de cinco anos, acumulando dívida técnica com cada instalação de plugin, personalização de tema e integração de terceiros.

No início de 2026, a loja estava a perder receita. Concorrentes com sites mais rápidos estavam a ultrapassa-los nos resultados de pesquisa, e os utilizadores móveis - que representavam 64 por cento do tráfego - estavam a abandonar o site em massa.

#Porque é que a loja WooCommerce era lenta

Quando auditei o site pela primeira vez, encontrei um padrão familiar mas grave de degradação de desempenho:

• 38 plugins ativos, muitos com funcionalidades sobrepostas
• Alojamento partilhado sem caching ao nível do servidor
• Base de dados não otimizada com mais de 2,3 milhões de transients expirados
• 12 000 imagens de produtos servidas como ficheiros PNG e JPEG não comprimidos
• Sem CDN - todos os recursos servidos a partir de um único servidor de origem na Alemanha
• JavaScript bloqueador de renderização de 14 plugins carregados em todas as páginas
• Processo de checkout de 5 passos com 22 campos de formulário

O resultado era um site que parecia partido em dispositivos móveis. As páginas demoravam 8 segundos a carregar, o layout saltavá a medida que os elementos eram renderizados, é o processo de checkout era tão pesado que 68 por cento dos visitantes abandonavam o site antes de completar uma compra.

#Métricas do WooCommerce antes da otimização

#Como acelerar o WooCommerce em 7 fases

Sigo uma abordagem sistemática e orientada por dados para a otimização de velocidade WordPress. Cada fase constrói-se sobre a anterior, e meço o impacto de cada alteração isoladamente antes de avancar para a seguinte.

#Fase 1: Auditoria técnica (dias 1-3)

Antes de tocar numa única linha de código, passei três dias a analisar cada aspeto do site:

• Análise GTmetrix Waterfall para identificar as cadeias de pedidos mais longas
• Testes WebPageTest multi-localização a partir de Frankfurt, Londres e Varsovia
• Chrome DevTools Performance Panel para analisar a atividade da thread principal
• Registo de consultas a base de dados com o plugin Query Monitor para encontrar consultas lentas
• Análise de plugins para medir o impacto de cada plugin no tempo de carregamento

A auditoria revelou que 73 por cento do tempo de carregamento era atribuível a três fatores: imagens não otimizadas (31 por cento), JavaScript excessivo (26 por cento) e consultas lentas a base de dados (16 por cento).

#Fase 2: Otimização do servidor (dias 4-7)

A fundação de qualquer site rápido é o servidor. Migrei o cliente de alojamento partilhado para um VPS dedicado com o seguinte stack:

• Servidor Web LiteSpeed com suporte HTTP/3 e QUIC
• Redis Object Cache para caching persistente de objetos WordPress
• MariaDB 11.4 com configuração my.cnf otimizada
• PHP 8.3 com preloading OPcache ativado

A configuração LiteSpeed incluiu afinação específica para WooCommerce:

# Regras de cache LiteSpeed para WooCommerce
<IfModule LiteSpeed>
  CacheLookup on
  RewriteRule .* - [E=Cache-Control:no-autoflush]
  RewriteRule ^/cart.* - [E=Cache-Control:no-cache]
  RewriteRule ^/checkout.* - [E=Cache-Control:no-cache]
  RewriteRule ^/my-account.* - [E=Cache-Control:no-cache]
</IfModule>

A configuração Redis foi afinada para o tratamento de sessões WooCommerce:

// Adicoes ao wp-config.php para Redis
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_DATABASE', 0);
define('WP_REDIS_MAXTTL', 86400);
define('WP_REDIS_PREFIX', 'wc_store_');
define('WP_REDIS_SELECTIVE_FLUSH', true);

Impacto após Fase 2: TTFB desceu de 2,4 segundos para 180 milissegundos.

#Fase 3: Limpeza da base de dados (dias 8-11)

Cinco anos de operação tinham deixado a base de dados em estado crítico. Realizei uma limpeza metódica:

1. Remoção de 2,3 milhões de transients expirados - a tabela wp_options tinha crescido para 847 MB
2. Otimização de 47 consultas lentas identificadas durante a fase de auditoria
3. Adição de índices em falta nas tabelas wp_postmeta e wp_wc_order_stats
4. Limpeza de post meta orfaos - 340 000 linhas de metadados de produtos eliminados
5. Conversão de tabelas para InnoDB onde MyISAM ainda estava em uso

Os índices personalizados melhoraram significativamente a pesquisa e filtragem de produtos:

-- Indices personalizados para consultas de produtos WooCommerce
ALTER TABLE wp_postmeta ADD INDEX idx_meta_lookup (meta_key, meta_value(32));
ALTER TABLE wp_wc_product_meta_lookup ADD INDEX idx_price_stock (min_price, max_price, stock_status);
ALTER TABLE wp_woocommerce_order_items ADD INDEX idx_order_type (order_id, order_item_type);

Impacto após Fase 3: O tempo de consulta a base de dados desceu 84 por cento, e a tabela wp_options encolheu de 847 MB para 12 MB.

#Fase 4: Otimização de imagens (dias 12-15)

Com 12 000 imagens de produtos, esta fase teve o maior impacto individual no peso da página:

• Conversão de todas as imagens para AVIF com fallback WebP para navegadores mais antigos
• Implementação de srcset responsivo com breakpoints a 320, 640, 960, 1280 e 1920 pixeis
• Adição de lazy loading com loading="lazy" nativo para todas as imagens abaixo da dobra
• Definição de dimensões explícitas em cada tag <img> para eliminar CLS do carregamento de imagens
• Implementação de placeholders blur-up usando Low Quality Image Placeholders (LQIP)

O processamento de imagens foi automatizado com dois filtros do WordPress e o WP-CLI:

// Saída AVIF para os tamanhos de imagem gerados (WordPress 6.5+)
add_filter('image_editor_output_format', function ($formats) {
    $formats['image/jpeg'] = 'image/avif';
    $formats['image/png'] = 'image/avif';
    return $formats;
});

// Qualidade AVIF 75, restantes formatos sem alterações
add_filter('wp_editor_set_quality', function ($quality, $mime_type) {
    return 'image/avif' === $mime_type ? 75 : $quality;
}, 10, 2);

wp media regenerate --yes

Impacto após Fase 4: O peso médio da página desceu de 6,8 MB para 1,2 MB. O LCP melhorou de 5,1 segundos (após otimização do servidor) para 1,4 segundos.

#Fase 5: Auditoria JavaScript (dias 16-19)

A auditoria JavaScript foi cirurgica. Categorizei cada script no site:

Para os scripts de análise, implementei um padrão de carregamento atrasado:

// Adiar scripts não críticos ate interacao do utilizador
const loadDeferredScripts = () => {
  const scripts = document.querySelectorAll('script[data-defer-src]');
  scripts.forEach(script => {
    const newScript = document.createElement('script');
    newScript.src = script.dataset.deferSrc;
    newScript.async = true;
    document.body.appendChild(newScript);
  });
};

['mouseover', 'touchstart', 'scroll', 'keydown'].forEach(event => {
  window.addEventListener(event, loadDeferredScripts, { once: true });
});

Também eliminei CSS bloqueador de renderização ao incorporar estilos críticos é adiar a folha de estilos completa:

<link rel="preload" href="/wp-content/themes/theme/style.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/wp-content/themes/theme/style.css"></noscript>

Impacto após Fase 5: INP desceu de 680ms para 62ms. O payload total de JavaScript foi reduzido em 78 por cento.

#Fase 6: Otimização da finalização da compra (dias 20-23)

Um site rápido não significa nada se a finalização da compra matar conversões. Reconstruí todo o processo de finalização da compra:

• Redução de 5 passos para 2 (envio + pagamento numa página, confirmação na seguinte)
• Remoção de 14 campos de formulário desnecessários (nome da empresa, telefone 2, fax, etc.)
• Adição de pagamento expresso (Apple Pay, Google Pay, Klarna)
• Implementação de preenchimento automático de morada usando a Google Places API
• Adição de válidação de formulário em tempo real para prevenir erros na submissão

// Remover campos de checkout WooCommerce desnecessários
add_filter('woocommerce_checkout_fields', function ($fields) {
    unset($fields['billing']['billing_company']);
    unset($fields['billing']['billing_phone_2']);
    unset($fields['billing']['billing_fax']);
    unset($fields['order']['order_comments']);
    return $fields;
});

// Adicionar suporte para gateway de pagamento expresso
add_action('woocommerce_review_order_before_payment', function () {
    if (class_exists('WC_Payment_Gateway')) {
        echo '<div id="express-checkout-buttons" class="express-payment-wrapper">';
        do_action('woocommerce_express_checkout_buttons');
        echo '</div>';
    }
});

Impacto após Fase 6: A taxa de abandono de carrinho desceu 34 por cento. O tempo médio de conclusão do checkout reduziu de 4 minutos e 12 segundos para 1 minuto e 38 segundos.

#Fase 7: CDN e edge caching (dias 24-28)

A última camada de otimização garantiu que os ganhos de desempenho fossem consistentes em todos os mercados europeus:

• Cloudflare Pro com regras de página personalizadas para WooCommerce
• Edge caching para páginas de produtos estáticas com TTL de 4 horas
• Cabeçalhos de cache do navegador com cache-busting via hashing de conteúdo
• Compressão Brotli ativada no edge para todos os recursos baseados em texto
• Early Hints (103) para recursos críticos

# Regras de página Cloudflare
URL: *example.com/product/*
Cache Level: Cache Everything
Edge Cache TTL: 4 hours
Browser Cache TTL: 1 hour

URL: *example.com/cart*
Cache Level: Bypass

URL: *example.com/checkout*
Cache Level: Bypass

Impacto após Fase 7: TTFB global desceu para menos de 100 milissegundos. Utilizadores na Europa Ocidental experienciaram carregamentos completos de página abaixo de 800ms.

#PageSpeed do WooCommerce antes e depois

Após quatro semanas de otimização sistemática, a transformação foi dramatica:

#Como ler as Core Web Vitals de uma loja WooCommerce

A coluna de classificação das tabelas acima segue os limiares que a Google publica no web.dev. Um Largest Contentful Paint bom acontece nos primeiros 2,5 segundos após a página começar a carregar, um Interaction to Next Paint bom é de 200 milissegundos ou menos e um Cumulative Layout Shift bom é de 0,1 ou menos. A Google avalia cada métrica no percentil 75 dos carregamentos de página, separando telemóvel e computador, pelo que uma página só passa quando três em cada quatro visitas cumprem o limiar.

As pontuações PageSpeed de 40 e 98 são outro tipo de número. São pontuações de laboratório obtidas com um carregamento simulado, úteis para comparar uma versão do site com a seguinte durante um projeto como este. O mesmo guia do web.dev diz que a medição em laboratório não substitui a medição de campo, porque as Core Web Vitals são métricas de campo recolhidas junto de visitantes reais. Depois de um lançamento, os números a acompanhar são os dados de campo do PageSpeed Insights e o relatório Core Web Vitals da Search Console, algumas semanas depois, quando já houver visitas reais suficientes registadas.

#Como a velocidade afeta a conversão no WooCommerce

Métricas técnicas são satisfatorias, mas métricas de negócio justificam o investimento:

• A taxa de conversão praticamente duplicou
• A receita móvel aumentou - utilizadores móveis finalmente podiam comprar sem frustração
• A taxa de rejeição caiu praticamente para metade - visitantes ficavam e navegavam em vez de sair
• O projeto pagou-se em semanas, não em trimestres
• O valor médio de encomenda subiu - navegação de produtos mais rápida levou a mais itens no carrinho
• O tráfego orgânico cresceu - Core Web Vitals melhorados contribuiram para melhores rankings de pesquisa em 8 semanas

#Lições de otimização de desempenho WooCommerce

Cada projeto de otimização ensina-me algo novo. Aqui estão as principais conclusões deste projeto:

#1. Quanto o alojamento afeta a velocidade do WooCommerce

Nenhuma quantidade de otimização de frontend pode compensar um servidor lento. A migração de alojamento partilhado para um VPS LiteSpeed otimizado representou 35 por cento da melhoria total de desempenho.

#2. Porquê limpar a base de dados do WooCommerce regularmente

Lojas WooCommerce geram enormes quantidades de dados transientes. Sem limpeza regular, a tabela wp_options torna-se um estrangulamento que afeta cada carregamento de página. Limpeza semanal automatizada deveria ser padrão para qualquer loja WooCommerce.

#3. Como os plugins tornam a loja WooCommerce lenta

Dos 38 plugins instalados, 14 estavam sem uso, eram redundantes ou substituíveis por snippets de código leves. Cada plugin adiciona consultas a base de dados, JavaScript e CSS - mesmo quando a sua funcionalidade não e necessária na página atual.

#4. Quanto as imagens AVIF reduzem o peso da página

A conversão para AVIF e implementação de imagens responsivas reduziu o peso da página em mais de 80 por cento. Está única alteração, que pode ser amplamente automatizada, proporciona a melhoria mais visível para os utilizadores finais.

#5. Como a UX da finalização da compra afeta a receita

O redesenho da finalização da compra, embora não seja uma otimização de “desempenho” tradicional, teve o impacto mais direto na receita. Reduzir a fricção no processo de compra é tão valioso como reduzir tempos de carregamento.

#6. Como medir o impacto de cada otimização

Ao implementar alterações em fases e medir após cada uma, pude quantificar o impacto exato de cada otimização. Esta abordagem orientada por dados previne esforço desperdiçado e constrói uma narrativa clara para as partes interessadas.

#Quanto tempo demora otimizar o WooCommerce

#Como aplicar estes métodos no WordPress e no WooCommerce em 2026

Três dos métodos acima dependem de funcionalidades do WordPress, do WooCommerce e da Cloudflare que mudaram desde que muitos tutoriais foram escritos. Eis como cada um funciona segundo a documentação dos próprios fornecedores.

#Como gerar imagens AVIF no WordPress

O WordPress suporta AVIF desde a versão 6.5, como foi anunciado no Make WordPress Core. O suporte depende da biblioteca de imagens do servidor: o WordPress funciona com Imagick e com GD, e a secção de tratamento de multimédia na informação de saúde do site mostra se o AVIF está disponível. Para converter os ficheiros JPEG carregados em AVIF, a equipa de core documenta o filtro image_editor_output_format. O filtro wp_editor_set_quality define a compressão entre 1 e 100 para um determinado tipo MIME. Segundo o anúncio, o AVIF usa por omissão compressão com perdas com qualidade 82, e a qualidade 100 muda-o para o modo sem perdas.

O wp media regenerate não tem opções de formato nem de qualidade. As opções são os ID dos anexos, --image_size, --skip-delete, --only-missing, --delete-unknown, --update-attachment-refs (apenas nas versões nightly) e --yes (documentação do WP-CLI). Os filtros decidem o formato e a qualidade, e o comando reconstrói os tamanhos de imagem, por isso o exemplo da Fase 4 usa ambos.

#Como apagar transients expirados no WooCommerce

O WP-CLI apaga os transients expirados com wp transient delete --expired, e wp transient delete --all remove todos (documentação do WP-CLI). Com uma cache de objetos persistente como o Redis, os transients podem ficar nessa cache em vez de na tabela wp_options, e o manual da Transients API avisa que o código nunca deve assumir que um transient está na base de dados. A função de core delete_expired_transients(), introduzida no WordPress 4.9, não faz nada quando há uma cache de objetos externa ativa. As linhas expiradas escritas antes de ligar a cache de objetos ficam por isso na tabela até algo as apagar diretamente da base de dados, que foi o trabalho da Fase 3.

#Que páginas e cookies do WooCommerce excluir da cache

A documentação para programadores do WooCommerce diz para excluir da cache de página o carrinho, a conta do cliente e a finalização da compra, porque estas páginas mostram informação do cliente atual e do seu carrinho. Enumera também os cookies que se pode indicar à cache para ignorar: woocommerce_cart_hash, woocommerce_items_in_cart, wp_woocommerce_session_, woocommerce_recently_viewed e store_notice[notice id]. As regras do LiteSpeed da Fase 2 excluem as três páginas, e o exemplo da Cloudflare da Fase 7 mostra o carrinho e a finalização da compra.

A Cloudflare está a substituir as Page Rules por um conjunto de produtos Rules dedicados e migra automaticamente as Page Rules existentes (guia de migração). Uma configuração nova exprime a mesma lógica com Cache Rules: definir a elegibilidade de cache como elegível substitui o Cache Everything, as definições Edge TTL e Browser TTL recebem os valores de TTL, e uma regra que deteta um cookie com a elegibilidade em bypass mantém fora da cache partilhada os visitantes com uma sessão de carrinho ativa.

#Auditoria gratuita de desempenho WooCommerce

Se a sua loja pontua abaixo de 70 no PageSpeed Insights, está a perder clientes todos os dias. O meu serviço de otimização WooCommerce segue a mesma metodologia comprovada descrita neste estudo de caso, adaptada sua loja e infraestrutura específicas.

Ofereço uma auditoria de desempenho inicial gratuita - um relatório detalhado que mostra exatamente onde a sua loja está a perder velocidade e quanto de receita isso lhe custa. Sem obrigações, sem discurso de vendas, apenas dados.

Contacte a WPPoland para agendar a sua auditoria, ou saiba mais sobre os meus serviços de otimização de velocidade WordPress.

#Recursos relacionados

• Alcançar 100/100 Core Web Vitals para WordPress em 2026
• Otimização de desempenho WooCommerce
• Otimização de velocidade WordPress