Moving a slow Strapi request out of the first visit
What pre-rendering and ISR changed in Arvand Termo Tec’s Next.js blog, how revalidate = 60 behaves, and what our local production test actually measured.
English translation of my original Persian LinkedIn post. Read the original LinkedIn post ↗(opens in a new tab)
A small request, a long wait
A roughly 20 KB request to Strapi took almost 29 seconds to return its first byte. That was the situation while we were working on the blog performance of Arvand Termo Tec, a project with a Next.js frontend and blog content coming from Strapi.
Browser-side caching was already preventing repeated requests when moving between pages. But when the server cache was empty, the first visit still depended on that slow CMS response. This was where the practical value of pre-rendering and ISR became much clearer to me.
Moving the expensive work
The change I implemented was straightforward:
- During the Vercel build, published content is fetched from Strapi and the blog listing and article pages are generated ahead of time.
- A new visitor receives the prepared HTML and page data. Displaying content that has already been generated does not need a simultaneous request to Strapi.
- With revalidate = 60, a page becomes eligible for regeneration after 60 seconds.
export const revalidate = 60;What happens after 60 seconds?
This last detail was the interesting part for me: reaching the 60-second mark does not create a request by itself. The first request after that interval usually receives the cached version while Next.js regenerates the page in the background. Once regeneration succeeds, subsequent requests receive the new version.
If the CMS fails during regeneration, the last successful version is retained.
This process does not automatically update a page that is already open in a visitor’s browser. The server cache and the browser’s current state are separate layers.
Testing without the CMS
To check the result, we built the project, started a fresh local production server and made the CMS unavailable. The complete listing pages took at most 23 milliseconds to receive, and the article pages took at most 11 milliseconds.
What this change does—and what it leaves to investigate
This architecture did not make Strapi itself faster. The backend delay still needs investigation. Also, an article published after the build may still wait for the CMS on its first request if it has not been warmed yet.
For me, the main value was moving expensive work away from the visitor’s request and into the build and background regeneration. These architectural details can make a real difference to the first visit.