All questions

Keeping ISR on Vercel while personalizing only a few Sanity routes

Asked by Justus Meyer on

JMJustus Meyer

Our Sanity + Next.js site on Vercel leans heavily on ISR. Route table after build, roughly:

Route (app)              Revalidate/                        1h/pricing                 1h/blog/[slug]             1h   (450 paths)/docs/[...slug]          1h   (1200 paths)

We previously tried a middleware-rewrite pattern from another tool and it multiplied pages per experiment, never again. Now I want personalization on / and /pricing only. If I call fetchContent there, does the rest of teh site keep its ISR behavior, or does anything leak? And what latency should I budget for the two routes that go dynamic?

Was this helpful?

2 answers

LFLucas FerraroAccepted answer

Nothing leaks, the effect is strictly per route. fetchContent reads the incoming request, which is what opts a route into dynamic rendering. Routes that never call it are unaffected, so your blog and docs keep their ISR behavior exactly as before. Personalizing only the high-value routes and leaving the rest static is the intended pattern; the docs do not cover ISR strategies beyond that, so keep fetchContent off any route you want to stay in the static output.

One thing to watch: make the call in the page (or a component only those pages render), not in a shared layout, otherwise every route under that layout inherits the dynamic rendering.

For the latency budget, Croct publishes end-to-end response times under 90 milliseconds at P95, and that is the extra cost on the two dynamic routes. Since you are on Sanity, pass your existing GROQ result as the fallback so the pages degrade to defaults if the fetch ever times out. The wiring itself is covered in Sanity + Next.js Croct wiring if you have not set it up yet.

Was this helpful?
JMJustus Meyer

Confirmed. Rebuilt with fetchContent on the two pages and the route table is unchanged except / and /pricing now show as dynamic. Blog and docs still prerendered. Thanks.

Ppriyam_dev

Small addition from someone who hit the layout trap Lucas mentions: we had a personalized announcement bar in the root layout and it silently dragged the whole site dynamic. Moving that one component to client-side fetching kept the static routes static, at the cost of the bar swapping in after load on those pages. Fine for a banner, not something you would want for a hero.

Was this helpful?
Still have questions?