Performance VTEX: como atingir Lighthouse 90+ na pratica

Atingir Lighthouse 90+ em uma loja VTEX e possivel, mas exige trabalho tecnico intencional. A plataforma, especialmente no Store Framework, tende a gerar bundles pesados pela natureza do sistema de apps. Cada app instalada adiciona JavaScript ao bundle, e lojas com muitas apps facilmente ultrapassam 1MB de JS comprimido. Este guia apresenta tecnicas praticas e testadas em lojas reais para elevar os scores de Lighthouse sem sacrificar funcionalidades.

Auditoria de apps instaladas

O primeiro passo e auditar todas as apps instaladas na loja. Rode vtex list no workspace de producao para ver a lista completa. Para cada app, pergunte: esta app ainda e usada? Existe alternativa mais leve? O beneficio justifica o impacto no bundle? Apps de terceiros sao os maiores viloes. Reviews que carregam frameworks inteiros, popups com jQuery, ferramentas de personalizacao que adicionam 300KB+ de JS. Remova apps nao essenciais e substitua por alternativas mais leves quando possivel. Em um caso real, remover 5 apps nao utilizadas reduziu o bundle em 400KB e elevou o LCP de 4.2s para 2.1s.

Otimizacao de imagens

Imagens sao responsaveis pela maior parte do peso de uma pagina de e-commerce. Na VTEX, use o servico de redimensionamento nativo: adicione parametros de largura e altura na URL da imagem (?width=800&height=600). Configure lazy loading em todas as imagens abaixo da fold. A imagem hero (banner principal) deve ter preload via tag link rel=preload no head. Defina width e height explicitos em todos os elementos img para evitar CLS. Use formatos modernos: o CDN da VTEX suporta conversao automatica para WebP via parametro na URL. Para banners, considere usar picture com srcset para servir tamanhos diferentes por breakpoint.

Fontes e CSS

Fontes customizadas sem configuracao adequada causam flash de texto invisivel (FOIT) ou flash de texto nao estilizado (FOUT), impactando LCP e CLS. Configure font-display: swap em todas as @font-face. Faca preload das fontes criticas com link rel=preload as=font crossorigin. Limite o numero de pesos e estilos carregados: cada variacao adiciona 20-50KB. Para CSS, evite estilos inline em blocos customizados. Use CSS Handles de forma eficiente, sem seletores profundamente aninhados. Remova CSS de apps desinstaladas que pode permanecer no bundle por cache. Use a aba Coverage do Chrome DevTools para identificar CSS nao utilizado.

JavaScript e hydration

O maior desafio de performance no Store Framework e o JavaScript. O React hydration completo no client significa que todo o HTML renderizado no servidor precisa ser re-processado no browser. Para mitigar: use React.lazy com Suspense para componentes pesados abaixo da fold. Evite useEffect com fetch na montagem do componente. Prefira dados vindos do servidor via GraphQL com cache. Configure defer em scripts de terceiros (analytics, chat, pixels). Adie a carga de componentes interativos ate a interacao do usuario (pattern de lazy hydration). Para scripts de GTM, use a estrategia de carregamento apos window load para nao bloquear o main thread durante a renderizacao inicial.

Cache e CDN

A VTEX tem uma camada de cache no edge que precisa ser configurada corretamente. Para paginas de categoria e busca, configure cache de pagina com tempo adequado (5-15 minutos e um bom padrao). Para APIs GraphQL, use a diretiva @cacheControl com maxAge e scope PUBLIC para dados que nao dependem do usuario. Headers de cache nos assets estaticos devem ter max-age longo (1 ano) com fingerprinting no nome do arquivo para invalidacao. Monitore cache hits vs misses no painel VTEX. Um cache hit ratio abaixo de 80% indica problemas de configuracao. Para lojas com personalizacao por segmento, use ESI (Edge Side Includes) ou cache por cookie quando disponivel.

Monitoramento continuo

Performance nao e um projeto com inicio e fim. E um processo continuo. Configure alertas de Core Web Vitals no Search Console. Rode Lighthouse CI em cada deploy (configure no GitHub Actions ou no pipeline de CI). Monitore Real User Metrics (RUM) com ferramentas como web-vitals library integrada ao GA4. Compare metricas de campo (CrUX) com metricas de lab (Lighthouse) mensalmente. Quando instalar uma nova app, meca o impacto antes e depois com SpeedCurve ou WebPageTest. Defina um budget de performance: tamanho maximo do bundle, LCP maximo aceitavel, CLS zero. Se uma nova feature estourar o budget, otimize antes de ir para producao.

O caminho headless: quando otimizar nao e suficiente

Se a loja tem dezenas de apps, o bundle ultrapassa 1.5MB, e cada otimizacao pontual gera retorno marginal, e hora de considerar o caminho headless. Duas opcoes: migrar para FastStore (frontend Next.js mantendo backend VTEX) ou adotar deco.cx como camada de frontend independente. Em ambos os casos, o resultado e Lighthouse 90+ consistente sem a necessidade de otimizar app por app. O backend VTEX continua intacto: checkout, catalogo, precos e pedidos funcionam normalmente. Apenas a camada de apresentacao muda. O investimento e maior que otimizacao pontual (R$ 30-80 mil para reconstruir o frontend), mas o resultado e sustentavel a longo prazo. Para novos projetos VTEX em 2025, comecar com FastStore desde o inicio evita acumular divida tecnica de performance.