A maioria das lojas Shopify pontua ~70 Lighthouse mobile. A maioria das lojas WooCommerce fica nos 55. Storefronts headless em Next.js + Medusa.js atingem rotineiramente 90–98. Não é diferença de tuning — é diferença estrutural. Este artigo abre a estrutura e dá técnicas concretas para conseguir 90+ no seu próprio build.
Os números abaixo vêm de uma baseline Next.js + Payload afinada (a stack a partir da qual entrego), não de staging nem demos.
Porque é que o PageSpeed importa em dinheiro
Antes das técnicas, o caso de negócio. Três números a memorizar:
- A conversão cai ~1% por cada 100ms de tempo de carregamento adicional (resultado clássico da Amazon, replicado muitas vezes).
- Bounce rate mobile salta de 32% para 90% quando o load vai de 1s para 5s (dados do Google).
- Core Web Vitals é fator de ranking no Google — páginas rápidas ficam acima de páginas lentas para o mesmo conteúdo.
Para uma loja a fazer €100k/ano, subir a conversão de 1.8% para 2.0% (ganho típico ligado à velocidade) são €11,000/ano de receita recuperada. Por isso não é métrica vaidosa.
Caso de negócio mais amplo → comparação de plataformas →.
Porque é que Shopify e WooCommerce ficam abaixo dos 90
Ambas as plataformas batem no teto por causa da arquitectura, não da configuração:
Shopify renderiza no servidor a partir de templates Liquid com um runtime fixo que inclui o bundle JS do tema, o sandbox de apps (cada app instalada injeta scripts) e os próprios analytics da Shopify. Pode podar o tema, mas não pode remover a camada da plataforma. Teto realista 75–80.
WooCommerce renderiza em PHP via WordPress, com JS do tema, jQuery e assets de cada plugin ativo. Caching (WP Rocket, LiteSpeed) ajuda — leva-o de 40 a ~60–70. Depois disso, teria de remover funcionalidade core, o que mata a admin.
Ambas as arquiteturas lutam contra o objetivo. O headless chega lá porque a arquitectura está alinhada com o objetivo.
A vantagem headless em cinco mecanismos
Um storefront Next.js + Medusa.js entrega páginas rápido porque:
1. Páginas estáticas ou ISR. Páginas de produto pré-renderizadas no build ou cacheadas no edge após o primeiro pedido. O browser recebe um HTML pronto do CDN, não um render PHP/Liquid.
2. O motor de commerce está fora do critical path. A Medusa serve cart, checkout e admin via API. O storefront só chama esses endpoints quando o cliente interage — nunca no carregamento inicial.
3. Sem runtime de tema. Sem jQuery, sem renderer Liquid, sem admin chrome. O storefront entrega só o React necessário.
4. Bundles JS granulares. O Next.js faz code-split por rota. A homepage carrega só JS da homepage. A página de produto, só JS de produto. Compare com temas Shopify que entregam JS do site inteiro em todas as páginas.
5. Pipeline de imagens engenheirado, não aparafusado. Next/Image converte para AVIF/WebP, redimensiona responsively e faz lazy-load. Cloudflare R2 entrega do edge. Sozinho vale 10–15 pontos Lighthouse em lojas com muitas imagens.
As oito técnicas que aterram em 90+
Checklist concreto:
1. Estático ou ISR para tudo o que não seja personalizado. Listings, produtos, categorias, conteúdo — pré-renderizados ou cacheados no edge. Só cart e checkout dinâmicos.
2. Budget de JS por página rigoroso. Limite por página (abaixo de 150kb gzipped no JS do storefront). Auditoria semanal com next build analyzer.
3. Defer ou remover scripts de terceiros. Meta Pixel, GTM, widgets de chat — nada deve estar no critical render. Passar para server-side tracking o Pixel e o GA4. Guia completo →
4. AVIF/WebP via Next/Image, com width/height explícitos. Sem CLS, sem imagens sobredimensionadas. Foto de produto a 1200px entregue ~30kb em vez de 300kb do upload de CMS.
5. Font subsetting + `font-display: swap`. Auto-alojar fontes, fazer subset aos caracteres usados e nunca permitir invisible-text-during-font-load.
6. Preload só da imagem LCP e da fonte primária. Tudo o resto em preload compete com o recurso que realmente pinta.
7. Cache de edge no CDN. Cloudflare ou Vercel edge para assets estáticos e páginas ISR. TTFB cai de 0.6s para 0.05s em respostas cacheadas.
8. Cortar bloat de analytics. Muitas lojas entregam 12+ tags. Auditoria, consolidação e mover não-críticos para server-side.
O que 96/100 parece na prática
Página de produto afinada na baseline Next.js + Medusa:
É de uma baseline-build com fotos reais de produtos, metadados SEO multilingues, schema markup e analytics ativos — não staging-demo. Compare com página de produto Shopify típica ~1.4MB total e 350kb JS.
Como chegar lá a partir de onde está
Duas opções reais:
- Afinar o que tem. Caching, otimização de imagens, poda de apps, auditoria de tema. Ganho realista: +15 a +25 pontos Lighthouse. Teto ~75 em Shopify, ~70 em WooCommerce.
- Mover o storefront para headless. Mantém o back-office onde está (ou migra também) e reconstrói o front em Next.js. Ganho realista: +30 a +50 pontos, sem teto. É o que o serviço de migração → faz.
A opção 1 é mais barata. A opção 2 deixa de ser opcional quando o custo das páginas lentas excede o custo de construir bem da primeira vez.
FAQ
Porque é que 90+ especificamente? 75 não chega? 75 chega para não ser penalizado por Core Web Vitals. Mas a curva de conversão continua a subir depois dos 75 — cada 100ms convertem mais. Não há ponto onde mais rápido pare de ser melhor.
Mudar de tema dá 90 em Shopify? Um tema premium rápido pode subir 10–15 pontos. Acima dos 70s altos, está a lutar contra o runtime da plataforma. O teto estrutural existe por mais bom que o tema seja.
Quanto tempo para construir uma loja 90+ do zero? Um build baseline leva 3–4 semanas e entrega 90+ por defeito. A parte de performance é fundação, não pass de tuning à parte.
Headless ajuda em Shopify (Hydrogen)? Sim — storefronts Hydrogen também atingem 90+. O argumento de performance fica resolvido lá. O que fica é custo e lock-in, cobertos na análise de custos Shopify →.
Próximos passos
Se quer uma loja rápida, o build começa em €2,000 e entrega Lighthouse 90+ como baseline — não add-on pago. Veja /services/online-store para o que está incluído, ou /services/custom-development para builds à medida onde a velocidade é crítica (booking, B2B, storefronts ricos em conteúdo).