Todos dizem que otimizam para velocidade. Poucos conseguem prová-lo. Está semana, completámos uma revisão de performance para um cliente no espaço competitivo de e-commerce de “Decoração de Casa”.
O Ponto de Partida:
- Pontuação Mobile: 42/100
- LCP: 4.8s
- INP: 450ms (Fraco)
- CLS: 0.25 (Mudanças de layout em todo o lado)
O Resultado (Após 4 Semanas):
- Pontuação Mobile: 100/100
- LCP: 1.2s
- INP: 48ms
- CLS: 0.00
Isto não foi magia. Foi engenharia. Eis exatamente como o fizemos.
1. Corrigir LCP (Largest Contentful Paint)
O Vilão: O Hero Slider. O cliente usava um Revolution Slider pesado. Carregava 4MB de JavaScript antes de mostrar a primeira imagem.
A Correção:
- Apagar o Slider: Substituímos o slider por um layout estático CSS Grid.
- Prioridade de Fetch: Adicionámos
<img fetchpriority="high">à imagem hero principal. Isto diz ao navegador “Descarrega isto ANTES do logótipo e do menu.” - Formato AVIF: Convertemos todos os PNGs para AVIF. A imagem de cabeçalho de 800KB tornou-se 45KB.
Resultado: LCP caiu de 4.8s para 1.9s instantáneamente.
2. Resolver CLS (cumulative layout shift)
O Vilão: Fontes Personalizadas e Lazy Loading.
- Fontes: O texto aparecia, depois a fonte personalizada carregava, deslocando o layout em 10 pixéis.
- Imagens: Imagens com lazy-loading apareciam e empurravam o texto para baixo porque lhes faltavam atributos
widtheheight.
A Correção:
- Preload de Fontes: Adicionámos
<link rel="preload">para a fonte primária e usámosfont-display: optional. Se a fonte não carregar em 100ms, o navegador fica com a fonte do sistema para sempre (sem deslocamento). - Aspect Ratio: Forçámos
aspect-ratio: 16/9;em todos os contentores de imagem em CSS. O navegador reserva o espaço em branco mesmo antes da imagem descarregar.
Resultado: CLS caiu para 0.00.
3. Esmagar o INP (interaction to next paint)
O Vilão: Scripts de Terceiros. Widgets de chat, Facebook Pixel, Google Tag Manager, Hotjar. Estavam todos a lutar pela thread principal. Quando um utilizador clicava em “Menu”, o navegador estava demasiado ocupado a rastrear o utilizador para abrir o menu.
A Correção: Partytown. Movémos todos os scripts de terceiros distintos para um Web Worker usando Partytown. Isto corré o código de rastreio pesado numa thread de fundo. A thread principal (UI) permanece suave como manteiga.
Resultado: INP caiu de 450ms para 48ms.
4. A arma secreta de 2026: Speculation rules API
Não queríamos apenas que fosse rápido. Queríamos que parecesse instantâneo. Implementámos a Speculation Rules API.
Quando um utilizador passa o rato sobre um cartão de produto, o navegador:
- Faz Prefetch do HTML da próxima página.
- Faz Prerender numa aba de fundo escondida.
Quando clicam, o carregamento da página é literalmente 0ms. Já lá está.
5. Otimização do lado do servidor (a infraestrutura)
Não consegue obter uma pontuação de 100 num servidor de 5$. Migrámos o cliente para uma arquitetura tipo WordPress VIP (ou high-end consistente).
- Redis Object Cache: Consultas à base de dados para o “Menu” e “Opções” são guardadas em cache na RAM.
- Edge Caching (Cloudflare Enterprise): O HTML da homepage é servido de um servidor em Lisboa, não da origem em Nova Iorque. O TTFB caiu de 600ms para 40ms.
6. Impacto no negócio
Porque fizemos isto tudo? Não por métricas de vaidade.
- Taxa de Rejeição: Diminuiu 18%.
- Gasto em Anúncios: CPC caiu 12% (Pontuação de Qualidade Google Ads melhorou devido à velocidade).
- Receita: O tráfego orgânico cresceu 40% em 2 meses, pois a Google recompensou os sinais de “Page Experience”.
Conclusão: Velocidade não é dívida técnica. É uma alavanca de receita.
O seu site WooCommerce está a perder dinheiro devido à lentidão? A WPPoland otimiza para pontuações verdes e contas bancárias verdes.
