Jamstack

Jamstack is an architecture pattern for building web applications. The name captures three ingredients. JavaScript runs in the browser to handle interactivity. APIs supply dynamic data at request time or at build time. Markup is pre-rendered rather than assembled by a server on every request. Together, the three let a site serve fast HTML from a CDN while still doing real work through API calls when needed. ## Where Jamstack came from The term was coined by Netlify around 2016 to describe a wave of static-site generators being used for real production sites. The original pitch was that a site could be built once, deployed as static files to a CDN, and served without an origin server on the critical path. That model was fast, cheap, and easy to reason about. It worked well for marketing sites, blogs, and documentation. Over time, the pattern extended. Frameworks like Next.js, Nuxt, and Astro added incremental static regeneration, server-side rendering, and edge functions. The definition of Jamstack loosened to cover any architecture where the frontend is decoupled from the data sources it consumes and where pre-rendering plays a meaningful role in performance. ## Jamstack in ecommerce Ecommerce complicates the original static model. Product catalogs change. Prices update. Inventory moves. Personalization needs real-time data. Pure static generation cannot handle any of that alone. But the Jamstack pattern still applies when the frontend is a separate application that renders pre-built shells and calls commerce APIs for the parts that need to be current. In practice, a Jamstack ecommerce frontend typically uses server-side rendering for pages that need fresh data (product detail, cart, checkout) and static or incremental rendering for pages that change less often (marketing pages, category shells, blog content). The frontend fetches products from a headless commerce API, content from a headless CMS, and personalization data from wherever it lives. ## What Jamstack changes about frontend delivery The biggest gain is performance. Pre-rendered markup served from a CDN loads faster than markup assembled by a backend on every request. The second gain is decoupling. The frontend is its own application with its own deployment cycle. The commerce backend can be swapped or upgraded without rewriting the storefront. The tradeoffs are complexity and freshness. A Jamstack frontend has more moving parts than a monolithic theme, and it takes real engineering to keep pre-rendered content in sync with backend changes. Frameworks handle most of that today, but the model is not free. ## How Frntkey relates Frntkey is a Jamstack-style ecommerce frontend built on Nuxt.js. Pages that change often (product listings, cart, checkout, account) are server-rendered on Vercel. Pages that change less often are cached and revalidated. Commerce data flows through Norce or Shopware APIs. Content flows through Storyblok. The pattern lets the storefront hit green Core Web Vitals without giving up on real-time commerce data. ## Related terms Headless architecture · Headless commerce · Headless CMS · Ecommerce frontend