deco.cx: How It Works and Why It Is So Fast
deco.cx positions itself as the fastest frontend platform for e-commerce. This is not just marketing: the numbers are consistent. TTFB below 50ms, LCP below 1 second, Lighthouse 95-100 on real production pages. But how is this possible? The answer lies in the combination of fundamental technical decisions that privilege performance at every layer: runtime (Deno), framework (Fresh), UI library (Preact), rendering model (islands architecture) and infrastructure (edge computing). In this article, we dissect each of these layers to understand why deco.cx delivers the performance it does, when it makes sense to use it and what the real trade-offs are.
Fresh framework and Deno runtime
deco.cx is built on Fresh, a web framework for Deno. Deno is the JavaScript/TypeScript runtime created by Ryan Dahl (the same creator of Node.js) as an evolution that corrects Node's design decisions. In practical performance terms: Deno has much lower startup time than Node.js, native TypeScript without a compilation step, and a permissions system that avoids unnecessary dependencies. Fresh, in turn, is a framework that follows the zero JavaScript by default philosophy. Unlike Next.js which sends the entire React library to the client and performs full hydration, Fresh sends no JavaScript at all unless you explicitly mark a component as interactive (island). Pages are rendered entirely on the server as pure HTML. The result is a JavaScript bundle that can be 5-20KB instead of the typical 200-500KB of a React SPA. Less JavaScript means faster parsing, lighter hydration and lower INP. The browser spends less time processing JS and more time displaying content.
Preact and islands architecture
deco.cx uses Preact instead of React. Preact is an alternative to React with the same API but only 3KB in size (React is 40KB+). For the developer, the experience is almost identical: JSX, hooks, functional components. For the end user, the difference is a drastically smaller bundle. Islands architecture is the rendering model that makes everything possible. Instead of hydrating the entire page (as Next.js does with React), only interactive components receive JavaScript. A header with hamburger menu is an island. A product carousel is an island. But text, images, category grid and all static content is pure HTML with no associated JavaScript. In practice, a category page with 50 products might have only 2-3 islands (filters, sorting, add-to-cart) while 95% of the page is static HTML. The result is an INP of 30-50ms instead of the typical 200-400ms of a fully hydrated SPA.
Edge computing and TTFB
deco.cx deploys to the edge, meaning hundreds of CDN points of presence (PoPs) around the world. When a user accesses the site, rendering happens on the geographically closest server. A user in New York gets the page rendered in New York, not in a distant origin server. The result is a TTFB (Time to First Byte) consistently below 50ms for most accesses. Compare with a VTEX or Shopify server that can take 200-800ms TTFB depending on load. During peak dates (Black Friday, Cyber Monday), the difference is even more dramatic: while origin servers struggle with increased load, the edge scales automatically. Each PoP operates independently, so there is no single server bottleneck. deco.cx also implements intelligent edge caching. Category pages, homepage and landing pages are cached with on-demand invalidation. When a product changes price in the backend, only that page's cache is invalidated. Everything else continues being served instantly.
Visual editor and business team autonomy
Performance alone does not sell. The business team needs to operate the site daily without depending on developers for every banner change. deco.cx solves this with a visual editor that works on top of the Sections system. Sections are configurable components: a hero banner, a product showcase, a category grid, a newsletter form. Each Section has typed props that appear as editable fields in the admin. The marketing team can change images, text, colors, links and even the order of sections on the page. Loaders connect Sections to backend data. A product Loader fetches from the VTEX catalog and delivers formatted data to the showcase Section. The business team can configure which products to show, how many, in what order, all through the panel. The combination of visual editor + edge performance is deco.cx's real differentiator: business autonomy without sacrificing user experience.
Real performance: production numbers
Numbers from real production stores running deco.cx (public data from PageSpeed Insights and CrUX): average TTFB of 30-80ms (vs 200-800ms on monoliths); average LCP of 0.8-1.5 seconds (vs 3-6 seconds on VTEX Store Framework); CLS of 0.01-0.05 (vs 0.1-0.3 on themes with dynamic loading); INP of 30-80ms (vs 200-500ms on heavy React SPAs); average Lighthouse score of 92-100 (vs 30-60 on monoliths). These numbers translate to measurable impact: pages load before the user blinks, scroll and interactions are fluid without stuttering, Google favors the site with green Core Web Vitals across all metrics. For the business: lower bounce rate, more pages per session, higher conversion rate.
When to use deco.cx vs other solutions
deco.cx is the best choice when: the operation uses VTEX as backend and needs superior performance without platform migration; the business team needs real autonomy to edit pages; performance is a strategic priority and every millisecond matters; the technical team is willing to learn Fresh/Deno/Preact (2-4 week curve for React devs). It is not the best choice when: the team only knows Next.js and does not want to learn a new framework; the operation needs pure SSG (static site generation) without a server; the project requires traditional React ecosystem with libraries depending on specific DOM APIs; the budget cannot accommodate the platform license. Compared to FastStore, deco.cx has superior performance (edge vs server), better visual editor and works with any backend (not just VTEX). Compared to Hydrogen, deco.cx is more performant (Preact vs React, edge vs server) but Hydrogen has deeper integration with the Shopify ecosystem. Compared to pure Next.js, deco.cx trades absolute freedom for productivity and out-of-the-box performance.
Trade-offs and limitations
No technology is perfect. Real deco.cx trade-offs include: smaller ecosystem than React/Next.js (fewer compatible libraries, fewer Stack Overflow answers); Deno is still less adopted than Node.js in the market (hiring developers can be harder); platform dependency (if deco.cx changes pricing or discontinues features, you are locked in); learning curve for teams accustomed to React/Next.js (Fresh and Preact have subtle differences); some third-party integrations (chat, reviews, pixel) may require adaptation to work with the islands model. For operations that decide to use deco.cx, the performance return usually compensates these trade-offs. But it is important to go in with eyes open about limitations rather than treating it as a magic solution.