Store Framework vs FastStore: complete technical comparison

The VTEX ecosystem offers two frontend options for stores: Store Framework (built on VTEX IO) and FastStore (built on Next.js). Both serve the same purpose - rendering the shopping experience - but with radically different philosophies. Store Framework prioritizes configurability and ecosystem. FastStore prioritizes performance and control. Understanding the technical differences between them is essential to making the right decision for your operation.

Store Framework architecture

Store Framework works with declarative JSON blocks. Each page is composed of blocks like header, slider-layout, shelf, product-summary, search-result-layout and footer. Each block accepts properties (props) that configure its behavior and appearance. Theming happens via CSS Handles: CSS selectors exposed by each block that allow visual customization without modifying the component source code. Blocks are distributed as VTEX IO apps. This means the community and VTEX itself publish new components that can be installed via CLI (vtex install) or through the admin. Build happens on the VTEX server: the developer runs vtex link for preview and vtex deploy to publish. The result is a server-side rendered React bundle, but with full client hydration, which frequently generates heavy bundles.

FastStore architecture

FastStore is a Next.js project with a layer of VTEX-specific components and utilities. The developer works with pure React, TypeScript and Tailwind CSS (or CSS Modules). There are no declarative blocks: each page is a React component that fetches data via GraphQL or REST and renders HTML directly. Build happens locally or in CI/CD (Vercel, GitHub Actions). Deploy can be done on VTEX infrastructure (WebOps) or any Next.js-compatible provider. The result is server-rendered pages with selective hydration, minimal bundles and aggressive edge caching. The practical difference: while in Store Framework you configure, in FastStore you code. The trade-off is more control vs more work.

Performance: real numbers

In tests with real stores, Store Framework typically delivers Lighthouse scores between 40 and 70 depending on the number of installed apps and page complexity. The main bottleneck is JavaScript bundle size: each installed app adds code to the bundle, and stores with 20+ apps easily exceed 1MB of JS. FastStore consistently delivers scores between 85 and 100. The secret is the absence of third-party apps in the bundle: each feature is implemented as code within the project, allowing granular tree-shaking, code splitting and lazy loading. In terms of Core Web Vitals: LCP on FastStore typically stays below 1.5s (vs 3-5s on Store Framework). CLS is consistently zero when image dimensions are defined. INP stays below 100ms due to the absence of heavy JavaScript on the main thread.

Ecosystem and features

Store Framework has a clear ecosystem advantage. Hundreds of ready-to-install apps: reviews, wishlists, product customizer, subscription, live shopping, chatbots, A/B testing and dozens more. Installing an app is as simple as vtex install vendor.app-name. In FastStore, each feature needs to be implemented manually or via a dedicated SDK. There is no visual component marketplace. If the operation needs features like subscription, gift cards, live shopping or product customizer, Store Framework offers ready solutions. In FastStore, these features require custom development consuming APIs directly.

Developer experience (DX)

In Store Framework, the workflow is: edit JSON blocks, run vtex link, view changes in workspace, promote to production via vtex deploy. The learning curve is moderate for those who already know React, but steep for those who have never worked with the block system. Documentation is extensive but fragmented. In FastStore, the workflow is: edit React/TypeScript components, run npm run dev for local preview, push to repository and CI/CD handles deploy. The experience is identical to any modern Next.js project. Developers with React experience feel at home immediately. Documentation is newer and less comprehensive, but familiarity with Next.js compensates.

Migration paths

Migrating from Store Framework to FastStore is not a simple upgrade. It is a frontend rebuild. The VTEX backend remains the same: checkout, catalog, pricing, inventory and orders continue working normally. But the entire visual layer needs to be rewritten. The typical process involves: surveying current theme features, prioritizing what will be replicated vs discarded, developing the new FastStore frontend, configuring APIs and integrating with the existing backend, comparative QA between versions and go-live with monitoring. Average timeline is 2 to 4 months for standard complexity stores. Investment starts at $6,000. Do not migrate if the store is stable and performing well. Migrate if technical debt is unsustainable, if performance is a strategic priority or if the store is being rebuilt anyway.

When to choose each

Choose Store Framework if: the operation depends on apps that do not exist on FastStore, the team is experienced with blocks and CSS Handles, the budget does not allow rebuilding, or the store is working well without critical performance issues. Choose FastStore if: performance is priority number one, the team masters React and Next.js, the operation is starting from scratch, the store has severe performance problems that point optimization cannot solve, or the project requires full control over generated HTML/CSS/JS. In both cases, the VTEX backend is the same. The choice is exclusively about how the frontend is built and delivered to the end user.