SSG or ISR: how to handle a price or offer that changes on a Next.js landing page

A statically generated (SSG, Static Site Generation) landing page is built once, at build time, then served as-is to every visitor: no server computation, no database query, just HTML that's already ready, handed back from a CDN. It's the fastest and cheapest option to run — and it's what Next.js recommends by default for any page that doesn't depend on a logged-in account. The problem shows up the moment something displayed on the page changes over time without a developer touching the code: a price that goes up, a promo code that rotates weekly, a countdown whose end date keeps getting closer. The HTML generated at the last build stays frozen until the next deployment — unless you pick the right mechanism to close that gap.

Why static is still the right starting point

The instinct "it changes, so it needs dynamic rendering" costs more than it looks. A page rendered on every request (SSR) recomputes the entire HTML server-side on every visit, even when nothing has changed since the last one — a cost in response time and serverless billing that a landing page's LCP has no reason to pay. Lee Breslau, Pei Cao, Li Fan, Graham Phillips and Scott Shenker, in "Web Caching and Zipf-like Distributions: Evidence and Implications," published in 1999 in the proceedings of IEEE INFOCOM (see on Google Scholar), use real web proxy traces to show that requests toward the same content follow a highly uneven distribution: a handful of pages account for most of the traffic, which makes caching already-computed content extremely profitable in terms of hit rate. A sales landing page fits this pattern exactly: the homepage and template pages get visited thousands of times for content that, most of the time, doesn't change from one visit to the next. Paying for a server computation on every request just to regenerate an identical HTML output only makes sense if part of the content actually changes — not as a default habit.

The real problem: an offer that changes faster than rebuilds

Pure SSG has one specific problem, not a general weakness: if the price or promo code is hardcoded into the HTML at build time, that HTML stays exactly as it was until the next deployment — which can happen days, even weeks later. A visitor can then land on a page still showing an expired offer, a countdown reading a negative time remaining, or a discounted price that no longer matches the coupon actually active at checkout. That's not just a technical detail: Daniel Kahneman, Jack L. Knetsch and Richard Thaler, in "Fairness as a Constraint on Profit Seeking: Entitlements in the Market," published in 1986 in the American Economic Review (see on Google Scholar), use survey data to show that buyers judge a transaction "unfair" the moment it departs from what they consider the displayed, implicit deal — a principle that applies directly to a visitor who clicks a buy button believing a discount applies, only to find at checkout that it no longer does. An expired offer doesn't just cost a missed conversion: it damages trust more lastingly than a slightly slow page load, precisely because it breaks a promise the page itself displayed.

Option 1: ISR (Incremental Static Regeneration)

ISR, specific to Next.js, keeps all the benefits of static HTML while regenerating it automatically in the background after a configured delay (revalidate). The principle: the first request after the delay expires still gets the old static version (no visitor ever waits on a recomputation), while Next.js regenerates the page in the background so the next request gets the up-to-date version. It's the right option when the change comes from an unpredictable external source — a price edited in a CMS, stock running out — and a delay of a few minutes to a few hours before the update is acceptable. Two limits worth knowing: the window between the actual change and the regeneration is still a period where the old content keeps showing, and an on-demand revalidation webhook (revalidatePath or revalidateTag, triggered from whatever tool changes the price) is needed to remove that delay entirely rather than just shrink it.

Option 2: pure static + client-side computation (LanderKit's approach)

When an offer follows a predictable rule rather than an arbitrary human decision — a weekly rotation on a fixed cycle, a countdown to a deadline known in advance — a third option avoids the stale-cache problem entirely: never write the offer into the static HTML at all, and compute it in the browser when the component mounts, from today's date and a deterministic function. That's the choice LanderKit makes on its own site: the HTML generated at build time carries no perishable offer at all, every visitor recomputes the current offer from their own browser clock according to a cycle of weeks defined in advance, and the countdown shown always matches the real end of the window — never a number frozen at build time. The payoff: zero risk of ever serving an expired offer, no webhook or background job to maintain, a render that stays 100% static and compatible with any CDN. The matching limit: it only works if the offer can be derived from a rule (a date, a cycle), not if a human needs to be able to change it by hand without touching code — in that case, ISR or a triggered rebuild take back the advantage.

Option 3: automatically triggered rebuild

For a rare, manually decided change — a catalog price increase, a new pricing tier — the simplest solution is often still a full rebuild, triggered automatically the moment a configuration file or a CMS entry changes (a Vercel deploy hook called from whatever tool hosts the price, or simply a Git commit). Automatic deployment on Vercel then regenerates the entire site in a few dozen seconds on every change, with no extra code complexity. This option gets expensive if the change needs to repeat very often (several times a day): every rebuild eats build minutes, and the maintenance budget climbs accordingly if the trigger fires continuously.

Comparison: pure SSG, ISR, computed static, triggered rebuild

How to choose for your landing page

1. Nothing changes once the site is live (copy, fixed pricing, positioning): pure SSG, with no extra layer at all, stays unbeatable for simplicity and speed.
2. The price or stock level is managed from a CMS or an external database, by someone who needs to change it without touching code: ISR with on-demand revalidation covers this case cleanly.
3. The offer follows a rule known in advance — a scheduled rotation, a countdown to a fixed date, a price that changes at a given hour or day: client-side computation removes any risk of stale content, with no extra infrastructure.
4. The change is rare and manually decided (an annual price increase, a new product): a rebuild automatically triggered on commit or on a configuration change is more than enough.
5. When in doubt on a production template: start with pure SSG, and only add ISR or client-side computation the day a real freshness need actually shows up — planning for that complexity before it's needed costs more than it saves.

None of these options is a shaky compromise: all four keep what makes a static landing page strong in the first place — load speed, minimal server cost, resilience under traffic. The difference is purely in how that speed coexists with information that changes over time, and in the effort needed to make sure that change never reaches a visitor as an expired offer. Every LanderKit template starts from this static base, whether it's the SaaS & Waitlist template (demo) or the single-product e-commerce template (demo), at €89 each or €229 for the full ten-template pack — it's up to you to add the freshness layer that actually matches how often your own prices change.