Headless commerce virou palavra da moda no e-commerce. Toda agência vende headless como a solução para todos os problemas. A realidade é mais nuançada: headless resolve problemas específicos muito bem, cria outros problemas que precisam ser gerenciados, e não é a escolha certa para a maioria das lojas de médio porte.
Trabalho com VTEX há 10 anos. Já implementei headless com FastStore, e também já convenci clientes a não migrar para headless quando não fazia sentido. O que importa é a decisão certa para o negócio — não a tecnologia mais nova.
O que é headless commerce
No modelo tradicional (acoplado), o sistema gera o HTML da loja no servidor junto com a lógica de negócio. O frontend e o backend vivem no mesmo sistema.
No headless commerce, o frontend (a loja que o cliente vê) é completamente separado do backend (catálogo, carrinho, checkout, pedidos, pagamentos). A comunicação entre as duas camadas acontece exclusivamente via APIs — geralmente REST ou GraphQL.
O resultado é uma separação de responsabilidades clara: o backend da VTEX cuida de toda a lógica de negócio, e o frontend é um projeto independente construído com qualquer tecnologia.
Como o headless funciona na VTEX
A solução headless oficial da VTEX é o FastStore: um framework baseado em Next.js que se conecta ao backend VTEX via GraphQL Federation.
O GraphQL Federation é uma camada de API unificada que agrega dados de diferentes serviços VTEX (catálogo, preços, estoque, search) em uma única interface GraphQL. O FastStore faz queries nessa camada para construir as páginas da loja.
As páginas são geradas com Static Site Generation (SSG) — o HTML é pré-renderizado em build time e servido como arquivo estático. Isso é fundamentalmente diferente do VTEX IO, onde o HTML é gerado no servidor a cada request (SSR).
O que headless realmente entrega
Performance mensurável
Com SSG, o navegador recebe o HTML completo imediatamente — sem aguardar processamento server-side. O resultado típico:
- LCP: 1,2s – 2,5s (vs 2,5s – 5s no VTEX IO típico)
- Lighthouse: 85 – 98 (vs 60 – 75 no VTEX IO típico)
- TTFB (Time to First Byte): < 100ms com CDN global
Esses números impactam diretamente conversão e SEO. O Google usa LCP e INP como fatores de ranqueamento desde 2021.
Flexibilidade de desenvolvimento
O frontend headless não está preso ao Store Framework ou ao ecossistema de temas do VTEX IO. Qualquer layout, animação ou interação que seja possível em Next.js é possível — sem depender de um componente VTEX que talvez não exista.
Multi-canal com o mesmo backend
O mesmo backend VTEX pode alimentar um site, um app mobile (via APIs), um PWA e um ponto de venda físico — cada um com seu frontend independente. Um catálogo, múltiplos pontos de venda.
Os desafios honestos
Complexidade técnica real
Headless exige proficiência em Next.js, GraphQL, APIs REST e arquitetura de sistemas distribuídos. A curva de aprendizado é significativamente maior que o Store Framework. Uma equipe sem essa experiência vai demorar mais e entregar menos qualidade.
Custo de desenvolvimento
Uma implementação headless bem feita custa 2–4x mais em horas de desenvolvimento que um VTEX IO equivalente. Isso precisa ser justificado pelo ROI de performance e flexibilidade para aquele negócio específico.
CMS para conteúdo editorial
O Site Editor do VTEX IO não funciona no headless. Para que o time de marketing edite banners, promoções e conteúdo sem depender de desenvolvimento, é necessário um CMS separado: Contentful, Storyblok, Sanity ou o CMS nativo do FastStore.
Apps VTEX IO incompatíveis
Muitos apps do ecossistema VTEX IO (wishlist customizada, reviews, plugins de terceiros) são construídos para o Store Framework. No FastStore, precisam ser substituídos por extensões FastStore ou soluções de API — o que representa trabalho de desenvolvimento adicional.
Quando headless faz sentido
- LCP consistentemente acima de 4s em mobile e impacto mensurável na receita
- Volume de sessões alto o suficiente para que cada décimo de segundo de performance tenha impacto real
- Necessidade de design completamente custom, fora do que o Store Framework permite
- Estratégia multi-canal: web + app + outros touchpoints no mesmo backend
- Time técnico com experiência em Next.js e GraphQL, ou disposição para contratar quem tenha
Quando vale mais otimizar o VTEX IO existente
Para a maioria das lojas:
- As causas do LCP ruim são corrigíveis sem mudar arquitetura (imagens sem otimização, scripts bloqueadores, ausência de preload)
- A loja tem customizações no Store Framework que seriam reescritas do zero
- O time não tem experiência com Next.js e GraphQL
- O orçamento não comporta uma migração de qualidade
Uma otimização bem executada no VTEX IO — imagens WebP com preload, lazy loading, eliminação de scripts desnecessários — pode reduzir o LCP de 5s para 2,8s sem mudar a arquitetura. Para muitas lojas, isso é suficiente para resolver o problema de performance e SEO.
Se você quer avaliar se headless é a resposta certa para sua situação específica, posso ajudar com uma análise técnica honesta. Conheça meu trabalho com VTEX ou fala comigo diretamente.