Cada segundo conta no e-commerce. A investigacao mostra consistentemente qué um atraso dé um segundo no tempo de carregamento da página pode reduzir as conversões em 7 por cento. 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 nossa equipa na WPPoland transformou uma loja europeia de moveis e-commerce em dificuldades, dé uma pontuacao PageSpeed de 40 para 98 - é o que isso significou para os seus resultados financeiros.
O Cliente: Uma Loja Europeia de Moveis E-Commerce
O nosso clienté opera uma loja de moveis online de medio porte que serve clientes na Europa Central e Ocidental. Com um catalogo de mais de 3500 produtos, 12 000 imagens de produtos e valores medios de encomenda superiores a 420 EUR, muito estava em jogo. A sua loja WooCommerce tinha crescido organicamenté ao longo de cinco anos, acumulando divida técnica com cada instalação de plugin, personalização de tema e integração de terceiros.
No inicio de 2026, a loja estava a perder receita. Concorrentes com sites mais rápidos estavam a ultrapassa-los nos resultados de pesquisa, é os útilizadores moveis - 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 degradacao 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 milhoes 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 dé um único servidor dé origem na Alémanha
- JavaScript bloqueador de renderizacao de 14 plugins carregados em todas as páginas
- Processo de checkout de 5 passos com 22 campos de formulario
O resultado era um site que parecia partido em dispositivos moveis. As páginas demoravam 8 segundos a carregar, o layout saltava a medida qué os elementos eram renderizados, é o processo de checkout era tao pesado que 68 por cento dos visitantes abandonavam o sité antes de completar uma compra.
Metricas Antes
| Metrica | Valor | Avaliação |
|---|---|---|
| Pontuacao 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 | 2,3% | Abaixo da media |
| Taxa de rejeicao | 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 sistematica é orientada por dados para a otimização de velocidade WordPress. Cada fase constroi-se sobré a anterior, e medimos o impacto de cada alteracao isoladamenté antes dé avancar para a seguinte.
Fase 1: Auditoria Técnica (Dias 1–3)
Antes de tocar numa única linha de código, passamos tres 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 atribuivel a tres 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 fundacao de qualquer site rápido é o servidor. Migramos o cliente dé 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 dé objetos WordPress
- MariaDB 11.4 com configuração
my.cnfotimizada - PHP 8.3 com preloading OPcaché ativado
A configuração LiteSpeed incluiu afinacao 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 sessoes 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 apos Fase 2: TTFB desceu de 2,4 segundos para 180 milissegundos.
Fase 3: Limpeza da Base de Dados (Dias 8–11)
Cinco anos dé operação tinham deixado a base de dados em estado crítico. Realizamos uma limpeza metodica:
- Remocao de 2,3 milhoes de transients expirados - a tabela
wp_optionstinha crescido para 847 MB - Otimização de 47 consultas lentas identificadas duranté a fase dé auditoria
- Adicao de indices 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 indices personalizados melhoraram significativamenté 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 apos Fase 3: O tempo de consulta a base de dados desceu 84 por cento, é 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, está fase tevé 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 - Adicao de lazy loading com
loading="lazy"nativo para todas as imagens abaixo da dobra - Definicao de dimensoes explicitas 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 apos Fase 4: O peso medio da página desceu de 6,8 MB para 1,2 MB. O LCP melhorou de 5,1 segundos (apos 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 | Acao |
|---|---|---|
| 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 dé análise, implementamos um padrão de carregamento atrasado:
// Adiar scripts não criticos ate interacao do útilizador
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 renderizacao ao incorporar estilos criticos é 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 apos Fase 5: INP desceu de 680ms para 62ms. O payload total de JavaScript foi reduzido em 78 por cento.
Fase 6: Otimização do Checkout (Dias 20–23)
Um site rápido não significa nada sé o checkout mata conversões. Redesenhamos todo o fluxo de checkout:
- Reducao de 5 passos para 2 (envio + pagamento numa página, confirmacao na seguinte)
- Remocao de 14 campos de formulario desnecessários (nome da empresa, telefone 2, fax, etc.)
- Adicao de pagamento expresso (Apple Pay, Google Pay, Klarna)
- Implementação de preenchimento automático de morada usando a Google Places API
- Adicao de válidação de formulario em tempo real para prevenir erros na submissao
// 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 apos Fase 6: A taxa dé abandono de carrinho desceu 34 por cento. O tempo medio de conclusao 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 dé otimização garantiu qué 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 estaticas com TTL de 4 horas
- Cabecalhos de cache do navegador com cache-busting via hashing de conteúdo
- Compressao Brotli ativada no edge para todos os recursos baseados em texto
- Early Hints (103) para recursos criticos
# 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 apos 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: Metricas Depois
Apos quatro semanas dé otimização sistematica, a transformação foi dramatica:
| Metrica | Antes | Depois | Melhoria |
|---|---|---|---|
| Pontuacao 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 | 2,3% | 4,8% | +108% |
| Taxa de rejeicao | 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 Negocio: Os Números que Importam
Metricas técnicas são satisfatorias, mas metricas de negocio justificam o investimento:
- +108% aumento na taxa de conversão - de 2,3% para 4,8%
- +156% receita movel - útilizadores moveis finalmente podiam comprar sem frustracao
- -52% reducao na taxa de rejeicao - visitantes ficavam e navegavam em vez de sair
- ROI alcancado em 6 semanas - o projeto dé otimização pagou-se em menos de dois meses
- +23% valor medio de encomenda - navegação de produtos mais rápida levou a mais itens no carrinho
- +41% tráfego organico - Core Web Vitals melhorados contribuiram para melhores rankings de pesquisa em 8 semanas
O cliente estimou qué o aumento anual de receita atribuivel a otimização excedeu 380 000 EUR, contra um custo de projeto que representou uma fracao desse valor.
Licoes Aprendidas
Cada projeto dé otimização ensina-nos algo novo. Aqui estão as principais conclusoes deste projeto:
1. Infraestrutura de Servidor é a Fundacao
Nenhuma quantidade dé otimização de frontend pode compensar um servidor lento. A migração dé alojamento partilhado para um VPS LiteSpeed otimizado representou 35 por cento da melhoria total de desempenho.
2. Higiene da Base de Dados Não e Negociavel
Lojas WooCommerce geram enormes quantidades de dados transientes. Sem limpeza regular, a tabela wp_options torna-sé um estrangulamento qué 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 substituiveis 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 Fruto 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 alteracao, que pode ser amplamenté automatizada, proporciona a melhoria mais visivel para os útilizadores finais.
5. UX do Checkout é uma Alavanca de Receita
O redesenho do checkout, embora não seja uma otimização de “desempenho” tradicional, tevé o impacto mais direto na receita. Reduzir a friccao no processo de compra e tao valioso quanto reduzir tempos de carregamento.
6. Medir Tudo Isoladamente
Ao implementar alterações em fases e medir apos cada uma, pudemos quantificar o impacto exato de cada otimização. Está abordagem orientada por dados previne esforco desperdicado e constroi uma narrativa clara para os stakeholders.
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 | Remocao 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?
Sé a sua loja pontua abaixo de 70 no PageSpeed Insights, está a perder clientes todos os dias. O nosso serviço dé otimização WooCommerce segué a mesma métodologia comprovada descrita neste estudo de caso, adaptada a sua loja e infraestrutura específicas.
Oferecemos uma auditoria de desempenho inicial gratuita - um relatorio detalhado que mostra exatamenté ondé a sua loja está a perder velocidade e quanto de receita isso lhe custa. Sem obrigacoes, 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.
