A performance de lojas VTEX IO é um dos temas mais frequentes nos projetos em que trabalho — e um dos mais mal compreendidos. A maioria das equipes sabe que a loja é lenta e que o Lighthouse está abaixo de 60, mas não sabe exatamente o que está causando o problema nem quais otimizações têm impacto real.
Trabalho com performance VTEX IO há 10 anos. Este artigo documenta o diagnóstico correto, as causas mais comuns e o que realmente move o ponteiro — com e sem mudança de arquitetura.
Por que a performance no VTEX IO é desafiadora
O VTEX IO com Store Framework usa Server-Side Rendering (SSR) — o servidor gera o HTML completo a cada request. Isso tem implicações de performance:
- O TTFB (Time to First Byte) depende do servidor VTEX — e lojas com muitas consultas GraphQL paralelas na página têm TTFB alto
- O bundle de JavaScript é compartilhado entre o Store Framework, apps instalados e customizações — e cresce com cada app adicionado
- Imagens são um gargalo recorrente — a VTEX serve imagens via CDN própria, mas sem otimização automática de formato ou dimensão
- Apps de terceiros (chat, loyalty, reviews de marketplaces) carregam scripts síncronos que bloqueiam a renderização
O resultado típico: lojas VTEX IO sem otimização ativa ficam com LCP entre 3s e 6s em mobile e Lighthouse entre 50 e 70.
Diagnóstico: como identificar o problema certo
Antes de otimizar qualquer coisa, identifique a causa raiz. Ferramentas por camada:
Lighthouse / PageSpeed Insights Mostra o score geral e indica os maiores "opportunities". Use para uma visão inicial, mas os dados de lab (Lighthouse) diferem dos dados de campo (CrUX). Foque primeiro no CrUX.
Google Search Console → Core Web Vitals Dados reais de campo, agregados por URL. Mostra quais páginas têm LCP/INP/CLS ruins para usuários reais — não em ambiente de teste. Esta é a fonte mais importante para priorizar o trabalho.
Chrome DevTools → Performance Para análise granular de LCP: qual elemento específico está sendo o LCP? O atraso vem de download de imagem, renderização de componente React ou TTFB?
WebPageTest Testes com conexão 4G, filmstrip de carregamento e análise de waterfall. Essencial para entender a sequência de carregamento de recursos e identificar o que está bloqueando o LCP.
As 7 causas mais comuns de performance ruim em VTEX IO
1. Banner hero sem preload (maior impacto individual)
O banner principal da homepage é frequentemente o elemento LCP. Se a imagem não tiver preload configurado, o browser só descobre que precisa baixar ela após processar o HTML — atrasando o LCP em 1–2 segundos.
Correção: adicionar <link rel="preload" as="image" href="..."> via script no head do Store Theme, apontando para a URL da imagem hero.
2. Apps pesados que bloqueiam o thread principal
Cada app instalado no VTEX IO carrega JavaScript. Alguns apps de terceiros (chat em tempo real, popups de intent, plataformas de fidelidade) carregam scripts síncronos pesados que bloqueiam o thread principal e aumentam o INP.
Correção: auditar os apps instalados com o Chrome DevTools Coverage. Identificar quais scripts têm maior tamanho e carregamento síncrono. Avaliar se o app é essencial e se tem alternativa mais leve.
3. Imagens em PNG/JPEG em vez de WebP
A VTEX serve imagens via CDN própria, mas não converte automaticamente para WebP. Imagens de produto em PNG de alta resolução podem ter 400–800kb cada, somando vários MB na PDP.
Correção: usar o parâmetro de URL da CDN VTEX para servir WebP: adicionar ?width=800&height=800&aspect=true e configurar o componente de imagem para usar as dimensões corretas. O VTEX IO tem suporte a vtex.store-components/ProductImages com configuração de maxHeight e aspectRatio.
4. Componentes desnecessários carregados no above-the-fold
O Store Framework carrega componentes React de forma síncrona por padrão. Se a página tem muitos componentes visíveis acima da dobra com alto custo de renderização (contadores de oferta, carrosséis com animação), o LCP é atrasado.
Correção: avaliar o custo de cada componente acima da dobra com o Chrome DevTools → Rendering → Paint Flashing. Simplificar o layout above-the-fold sempre que possível.
5. Fontes customizadas sem font-display: swap
Fontes carregadas via @font-face sem font-display: swap ou optional causam FOIT (Flash of Invisible Text) — o texto fica invisível enquanto a fonte carrega, gerando CLS quando aparece e aumentando o LCP percebido.
Correção: adicionar font-display: swap no CSS de fontes customizadas e fazer preload das fontes críticas.
6. CLS por banners sem altura definida
Banners carregados pelo CMS da VTEX sem altura reservada causam layout shift — o conteúdo abaixo do banner "pula" quando a imagem é carregada. Em mobile, isso resulta em CLS alto.
Correção: definir aspectRatio ou height explícita no componente de banner do Store Framework para o browser reservar o espaço antes de a imagem carregar.
7. Queries GraphQL lentas ou redundantes
Algumas customizações de VTEX IO fazem múltiplas queries GraphQL redundantes que aumentam o TTFB. Uma página com 10 queries paralelas para dados que poderiam ser consolidados em 3 tem TTFB maior.
Correção: auditar as queries GraphQL com o Apollo DevTools. Consolidar queries onde possível e usar @defer para queries não críticas.
Resultados típicos de otimização
Com as correções acima aplicadas corretamente em lojas VTEX IO, os resultados típicos são:
| Métrica | Antes | Depois | |---|---|---| | LCP mobile | 4,5s – 6s | 2,2s – 3s | | CLS | 0,2 – 0,35 | 0,05 – 0,1 | | Lighthouse mobile | 50 – 65 | 70 – 85 | | INP | 400ms – 600ms | 180ms – 280ms |
Esses resultados são sem mudança de arquitetura — mantendo VTEX IO com Store Framework.
Quando considerar a migração para VTEX FastStore
Se após as otimizações acima o LCP ainda ficar acima de 3s em mobile, pode ser sinal de que os limites do Store Framework foram atingidos. O VTEX FastStore com Next.js SSG resolve estruturalmente o problema de LCP — as páginas são pré-geradas, não renderizadas no request.
A migração para FastStore faz sentido quando:
- O volume de tráfego é alto suficiente para que o ganho de performance tenha impacto mensurável na receita
- A loja tem poucos apps IO customizados que precisariam ser reescritos
- O time ou parceiro tem experiência com Next.js e GraphQL
Para a maioria das lojas de médio porte, a otimização do VTEX IO existente tem melhor ROI que uma migração completa.
Trabalho com performance VTEX IO há 10+ anos, com histórico em lojas que foram de Lighthouse 55 para 85+ sem mudança de arquitetura. Conheça o serviço de SEO e performance ou entre em contato para uma análise gratuita dos Core Web Vitals da sua loja.