A coaching institute in Kota has course pages, a few hundred blog posts and a results page that changes twice a year. On a typical setup, every visitor still triggers a database query and a template render to produce a page that is identical for everyone. JAMstack does that work once, ahead of time, and serves the result as plain files. It suits some sites very well and others badly, so the useful question is which kind of site you have.
What the three letters stand for
JAMstack stands for JavaScript, APIs and Markup. Markup is the HTML, built before anyone asks for it. JavaScript runs in the browser for whatever needs to be interactive. APIs, your own or a third party's, supply the things nobody can know at build time, such as a payment status, a logged-in user or a search result.
The front end is built separately from the back end. A build step pulls content, renders every page to HTML and publishes the files to a CDN. A parent in Jaipur opening the fee page gets a file from a nearby location, and no application server does any work for that request.
- 01Edit contentCMS or Markdown
- 02Buildrender pages to HTML
- 03Publish to CDN
- 04Visitorreceives a ready file
The rendering work happens once per change instead of once per visitor.
What the browser gets from a pre-built page
Open the network tab on a server-rendered page and look at the first request, the HTML document. Before a single byte comes back, the server has run your application code, queried the database and filled a template. On a busy evening that wait grows, and everything else on the page sits behind it.
On a pre-built page the CDN hands back a file it already has. The HTML arrives early, the browser starts fetching CSS and images sooner, and the main content paints sooner. Run Lighthouse or WebPageTest on both versions of the same page and compare the time to first byte. Measure on the real page, not the homepage.
The other gains follow from having fewer moving parts. No database or server code sits behind a public page, so there is less to attack, although your APIs and functions still need securing. When results go live and a few thousand parents open the same page in the same five minutes, the CDN takes the load instead of your server. Static hosting is cheap, and serverless functions are billed only when they run.
The pieces you put together
A framework or static site generator, such as Next.js, Astro or Hugo, builds pages from templates and data. A headless CMS holds the content and exposes it over an API, so the marketing team edits in a form and never touches the front end. Our post on choosing between a headless and a traditional CMS covers that side in detail.
Serverless functions handle the few things that need code at request time. For the coaching institute that is the enquiry form and the payment gateway callback, and very little else.
Frameworks also let a pre-built page refresh itself on a timer, so a small change does not need a full rebuild. In the Next.js App Router it is one line in the page file.
// app/courses/[slug]/page.jsx
export const revalidate = 3600; // rebuild this page at most once an hour
We start with the content model before choosing any tooling. If the CMS fields are wrong, every template inherits the mistake, and fixing it after fifty pages exist is a bad week.
Where pre-built sites go wrong
Build time grows with page count. A few hundred pages build quickly. A property portal with a page for every locality in NCR can make a one-line correction take long enough that the editor goes for chai and comes back to check. Editors expect to see a change when they press publish. With a build in between, they wait, and then they file a ticket.
Dynamic features creep in one at a time. Comments, stock levels, personalisation and search each add an API or a function, and the simple static site turns into a distributed system without anyone deciding it should.
Preview is the one teams forget. Showing an editor an unpublished draft on a static site needs a deliberate preview mode, and without it they publish to check, which is how typos go live.
Two more. Anything rendered only in the browser can still be missed by search crawlers, so keep the content that matters in the pre-built HTML. And moving off a traditional CMS means redoing templates, redirects and the editorial workflow, which is usually the part left out of the estimate.
BéloVélo, a content-led site
BéloVélo runs guided luxury cycling tours on French routes. Its site is a content-led marketing site with itinerary pages built from consistent templates (route overview, highlights, what's included, availability, FAQs), booking and inquiry paths, and email capture. Pages for stage-themed trips had to be published quickly, and the team updates routes, dates and prices without engineers. The full BéloVélo project story has the detail.
That is the profile where pre-built pages make sense. Many pages share a template, content changes on an editorial schedule, and the main live interaction is a form. The project record describes the site as SEO-friendly with fast pages but does not state a rendering approach, so read this as an example of the kind of site, not as a JAMstack case study.
Search shows where a static site still needs a service. There is no server to query, so search runs either in the browser against an index generated at build time, or through an external search API. Both work. Each is one more thing to maintain.
Mixing pre-built and live pages
- Marketing and course pages
- Blogs and documentation
- Catalogues updated on a schedule
- Pages that differ per user
- Data that changes by the minute
- Dashboards behind a login
Most real sites have pages in both columns.
You rarely have to pick one model for the whole site. Pre-build the stable pages and render the rest on request. Next.js supports both in one project, so the course pages can sit on a CDN while the student login and fee ledger stay server-rendered. That mixed setup is what we recommend most often in our web development work.
How to test the fit before committing
List your ten most visited pages and mark each one as the same for everyone or different per user. If most are the same for everyone, pre-build three of them in a branch and time two things: how long a full build takes, and how long an editor waits between pressing publish and seeing the change live. Then run Lighthouse on a mid-range Android phone against the old and new versions of the same page. Those three checks will tell you more than any comparison of frameworks.
