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 a a nossa equipa na WPPoland transformou uma loja europeia de móveis e-commerce em dificuldades, de uma pontuação PageSpeed de 40 para 98 - é o que isso significou para os seus resultados financeiros.
O Cliente: Uma Loja Europeia de Móveis E-Commerce
O nosso 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.
O Desafio: Morte por Mil Plugins
Quando auditamos o site pela primeira vez, encontramos 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 Antes
| Métrica | Valor | Avaliação |
|---|---|---|
| Pontuação PageSpeed (Mobile) | 40 | Fraco |
| Largest Contentful Paint (LCP) | 8,2s | Fraco |
| Interaction to Next Paint (INP) | 680ms | Fraco |
| Cumulative Layout Shift (CLS) | 0,35 | Fraco |
| Taxa de conversão | Abaixo da media do setor | Fraco |
| Taxa de rejeição | 68% | Crítico |
| Time to First Byte (TTFB) | 2,4s | Fraco |
| Peso total da página | 6,8 MB | Excessivo |
A Nossa Abordagem: Metodologia de Otimização em 7 Fases
Seguimos uma abordagem sistemática é orientada por dados para a otimização de velocidade WordPress. Cada fase constrói-se sobre a anterior, e medimos 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, passamos 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. Migramos 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.cnfotimizada - 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. Realizamos uma limpeza metodica:
- Remoção de 2,3 milhões de transients expirados - a tabela
wp_optionstinha crescido para 847 MB - Otimização de 47 consultas lentas identificadas durante a fase de auditoria
- Adição de índices em falta nas tabelas
wp_postmetaewp_wc_order_stats - Limpeza de post meta orfaos - 340 000 linhas de metadados de produtos eliminados
- 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
srcsetresponsivo 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 pipeline de processamento de imagens foi automatizado com um comando WP-CLI personalizado:
wp media regenerate --image_size=all --format=avif --quality=75Impacto 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. Categorizamos cada script no site:
| Categoria | Scripts | Ação |
|---|---|---|
| Crítico (checkout, carrinho) | 4 | Mantido, otimizado |
| Análise e rastreamento | 3 | Movido para Web Worker |
| Scripts de plugins não usados | 14 | Removidos completamente |
| Melhorias de UI | 6 | Adiados, carregados condicionalmente |
Para os scripts de análise, implementamos 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 eliminamos 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. Redesenhámos 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: BypassImpacto 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.
Os Resultados: Métricas Depois
Após quatro semanas de otimização sistemática, a transformação foi dramatica:
| Métrica | Antes | Depois | Melhoria |
|---|---|---|---|
| Pontuação PageSpeed (Mobile) | 40 | 98 | +145% |
| Largest Contentful Paint (LCP) | 8,2s | 0,8s | -90% |
| Interaction to Next Paint (INP) | 680ms | 45ms | -93% |
| Cumulative Layout Shift (CLS) | 0,35 | 0,02 | -94% |
| Taxa de conversão | Base | Praticamente o dobro | Melhorada |
| Taxa de rejeição | 68% | 34% | -50% |
| Time to First Byte (TTFB) | 2,4s | 0,09s | -96% |
| Peso total da página | 6,8 MB | 1,1 MB | -84% |
Impacto no negócio: o que mudou realmente
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 Aprendidas
Cada projeto de otimização ensina-nos algo novo. Aqui estão as principais conclusões deste projeto:
1. Infraestrutura de servidor é a fundação
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. Higiene da base de dados não é negociável
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. Menos plugins, loja mais rápida
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. Imagens são o ganho mais fácil
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. A UX da finalização da compra é uma alavanca de 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. Medir tudo isoladamente
Ao implementar alterações em fases e medir após cada uma, pudemos 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.
Resumo do Cronograma
| Semana | Fase | Atividades Chave |
|---|---|---|
| Semana 1 | Auditoria + Servidor | Auditoria técnica completa, migração de servidor, configuração Redis |
| Semana 2 | Base de dados + Imagens | Limpeza de transients, otimização de consultas, conversão AVIF |
| Semana 3 | JavaScript + Checkout | Remoção de plugins, adiamento de scripts, redesenho do checkout |
| Semana 4 | CDN + QA | Configuração Cloudflare, edge caching, testes abrangentes |
A Sua Loja WooCommerce Está a Perder Dinheiro?
Se a sua loja pontua abaixo de 70 no PageSpeed Insights, está a perder clientes todos os dias. O nosso serviço de otimização WooCommerce segue a mesma metodologia comprovada descrita neste estudo de caso, adaptada sua loja e infraestrutura específicas.
Oferecemos 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 nossos serviços de otimização de velocidade WordPress.
