Can some one help me understand what actually dynamic = "force-dynamic" do?
Unanswered
Fire ant posted this in #help-forum
Fire antOP
Does it delay bundle generation for client hydration?
Does it affect server response time or TTFB in any manner?
Does it affect server response time or TTFB in any manner?
10 Replies
There are two modes of rendering over at Next.js. Or any website rendering ever.
SSG: Static Generation: builds html at build time and serve that html to the user. id call this the static cache
SSR: Server Side Rendering: builds html per every single request. This is used if it depends on request data from the user like headers/cookies. but static generation usually does not need that on the server.
You can still make dynamic content sites with either SSG and SSR.
The mode of rendering is automatically determined by Next.js and is determined per route (not route segment). So route
The use of
SSG: Static Generation: builds html at build time and serve that html to the user. id call this the static cache
SSR: Server Side Rendering: builds html per every single request. This is used if it depends on request data from the user like headers/cookies. but static generation usually does not need that on the server.
You can still make dynamic content sites with either SSG and SSR.
The mode of rendering is automatically determined by Next.js and is determined per route (not route segment). So route
/a can be SSR while /a/b can be SSG. even if you force-dynamic on /a/page.tsxThe use of
dynamic = "force-dynamic" will force Next.js to render that specific route and their children so that it is rendered for every single request---
routes are by default statically computed unles there are dynamic features that is used in that route, or the children of that route with the exception of variadic routes (
/[id]) which are by default dynamically computed at request time.---
Does it delay bundle generation for client hydration?no it shouldnt delay it.
Does it affect server response time or TTFB in any manner?yes. static routes are definetly way faster since you dont need to process the incoming data and just serve the HTML (and necessary client components)
but there are ways to make your SSR routes as fast as SSG by employing techniques such as caching, and streaming
---
in the very near future, we might see routes that combines dynamic data rendering at request time, while sending pre-built static shell (like for UI skeleton) thereby combining SSR and SSG. This feature is called Partial Pre-rendering or known as PPR. However this feature is still on preview and is very much not ready to be used.
Fire antOP
Yeah I am exploring PPR too its really nice feature.
Thanks a lot @aardani for your quick clarifications.
@Fire ant Thanks a lot <@194128415954173952> for your quick clarifications.
you're welcome! feel free to mark most helpful message as answered and also feel free to ask more questions