Route Segment Config
The Route Segment options allows you to configure the behavior of a Page, Layout, or Route Handler by directly exporting the following variables:
Option | Type | Default |
---|---|---|
experimental_ppr | 'true' | 'false' | |
dynamic | 'auto' | 'force-dynamic' | 'error' | 'force-static' | 'auto' |
dynamicParams | boolean | true |
revalidate | false | 0 | number | false |
fetchCache | 'auto' | 'default-cache' | 'only-cache' | 'force-cache' | 'force-no-store' | 'default-no-store' | 'only-no-store' | 'auto' |
runtime | 'nodejs' | 'edge' | 'nodejs' |
preferredRegion | 'auto' | 'global' | 'home' | string | string[] | 'auto' |
maxDuration | number | Set by deployment platform |
Optionsβ
experimental_ppr
β
Enable Partial Prerendering (PPR) for a layout or page.
export const experimental_ppr = true
// true | false
export const experimental_ppr = true
// true | false
dynamic
β
Change the dynamic behavior of a layout or page to fully static or fully dynamic.
export const dynamic = 'auto'
// 'auto' | 'force-dynamic' | 'error' | 'force-static'
export const dynamic = 'auto'
// 'auto' | 'force-dynamic' | 'error' | 'force-static'
Good to know: The new model in the
app
directory favors granular caching control at thefetch
request level over the binary all-or-nothing model ofgetServerSideProps
andgetStaticProps
at the page-level in thepages
directory. Thedynamic
option is a way to opt back in to the previous model as a convenience and provides a simpler migration path.
-
'auto'
(default): The default option to cache as much as possible without preventing any components from opting into dynamic behavior. -
'force-dynamic'
: Force dynamic rendering, which will result in routes being rendered for each user at request time. This option is equivalent to:getServerSideProps()
in thepages
directory.- Setting the option of every
fetch()
request in a layout or page to{ cache: 'no-store', next: { revalidate: 0 } }
. - Setting the segment config to
export const fetchCache = 'force-no-store'
-
'error'
: Force static rendering and cache the data of a layout or page by causing an error if any components use dynamic functions or uncached data. This option is equivalent to:getStaticProps()
in thepages
directory.- Setting the option of every
fetch()
request in a layout or page to{ cache: 'force-cache' }
. - Setting the segment config to
fetchCache = 'only-cache', dynamicParams = false
. dynamic = 'error'
changes the default ofdynamicParams
fromtrue
tofalse
. You can opt back into dynamically rendering pages for dynamic params not generated bygenerateStaticParams
by manually settingdynamicParams = true
.
-
'force-static'
: Force static rendering and cache the data of a layout or page by forcingcookies()
,headers()
anduseSearchParams()
to return empty values.
Good to know:
- Instructions on how to migrate from
getServerSideProps
andgetStaticProps
todynamic: 'force-dynamic'
anddynamic: 'error'
can be found in the upgrade guide.
dynamicParams
β
Control what happens when a dynamic segment is visited that was not generated with generateStaticParams.
export const dynamicParams = true // true | false,
export const dynamicParams = true // true | false,
true
(default): Dynamic segments not included ingenerateStaticParams
are generated on demand.false
: Dynamic segments not included ingenerateStaticParams
will return a 404.
Good to know:
- This option replaces the
fallback: true | false | blocking
option ofgetStaticPaths
in thepages
directory.- To statically render all paths the first time they're visited, you'll need to return an empty array in
generateStaticParams
or utilizeexport const dynamic = 'force-static'
.- When
dynamicParams = true
, the segment uses Streaming Server Rendering.- If the
dynamic = 'error'
anddynamic = 'force-static'
are used, it'll change the default ofdynamicParams
tofalse
.
revalidate
β
Set the default revalidation time for a layout or page. This option does not override the revalidate
value set by individual fetch
requests.
export const revalidate = false
// false | 0 | number
export const revalidate = false
// false | 0 | number
false
(default): The default heuristic to cache anyfetch
requests that set theircache
option to'force-cache'
or are discovered before a dynamic function is used. Semantically equivalent torevalidate: Infinity
which effectively means the resource should be cached indefinitely. It is still possible for individualfetch
requests to usecache: 'no-store'
orrevalidate: 0
to avoid being cached and make the route dynamically rendered. Or setrevalidate
to a positive number lower than the route default to increase the revalidation frequency of a route.0
: Ensure a layout or page is always dynamically rendered even if no dynamic functions or uncached data fetches are discovered. This option changes the default offetch
requests that do not set acache
option to'no-store'
but leavesfetch
requests that opt into'force-cache'
or use a positiverevalidate
as is.number
: (in seconds) Set the default revalidation frequency of a layout or page ton
seconds.
Good to know:
- The revalidate value needs to be statically analyzable. For example
revalidate = 600
is valid, butrevalidate = 60 * 10
is not.- The revalidate value is not available when using
runtime = 'edge'
.
Revalidation Frequencyβ
- The lowest
revalidate
across each layout and page of a single route will determine the revalidation frequency of the entire route. This ensures that child pages are revalidated as frequently as their parent layouts. - Individual
fetch
requests can set a lowerrevalidate
than the route's defaultrevalidate
to increase the revalidation frequency of the entire route. This allows you to dynamically opt-in to more frequent revalidation for certain routes based on some criteria.
fetchCache
β
By default, Next.js will cache any fetch()
requests that are reachable before any dynamic functions are used and will not cache fetch
requests that are discovered after dynamic functions are used.
fetchCache
allows you to override the default cache
option of all fetch
requests in a layout or page.
export const fetchCache = 'auto'
// 'auto' | 'default-cache' | 'only-cache'
// 'force-cache' | 'force-no-store' | 'default-no-store' | 'only-no-store'
export const fetchCache = 'auto'
// 'auto' | 'default-cache' | 'only-cache'
// 'force-cache' | 'force-no-store' | 'default-no-store' | 'only-no-store'
'auto'
(default): The default option to cachefetch
requests before dynamic functions with thecache
option they provide and not cachefetch
requests after dynamic functions.'default-cache'
: Allow anycache
option to be passed tofetch
but if no option is provided then set thecache
option to'force-cache'
. This means that evenfetch
requests after dynamic functions are considered static.'only-cache'
: Ensure allfetch
requests opt into caching by changing the default tocache: 'force-cache'
if no option is provided and causing an error if anyfetch
requests usecache: 'no-store'
.'force-cache'
: Ensure allfetch
requests opt into caching by setting thecache
option of allfetch
requests to'force-cache'
.'default-no-store'
: Allow anycache
option to be passed tofetch
but if no option is provided then set thecache
option to'no-store'
. This means that evenfetch
requests before dynamic functions are considered dynamic.'only-no-store'
: Ensure allfetch
requests opt out of caching by changing the default tocache: 'no-store'
if no option is provided and causing an error if anyfetch
requests usecache: 'force-cache'
'force-no-store'
: Ensure allfetch
requests opt out of caching by setting thecache
option of allfetch
requests to'no-store'
. This forces allfetch
requests to be re-fetched every request even if they provide a'force-cache'
option.
Cross-route segment behaviorβ
- Any options set across each layout and page of a single route need to be compatible with each other.
- If both the
'only-cache'
and'force-cache'
are provided, then'force-cache'
wins. If both'only-no-store'
and'force-no-store'
are provided, then'force-no-store'
wins. The force option changes the behavior across the route so a single segment with'force-*'
would prevent any errors caused by'only-*'
. - The intention of the
'only-*'
and'force-*'
options is to guarantee the whole route is either fully static or fully dynamic. This means:- A combination of
'only-cache'
and'only-no-store'
in a single route is not allowed. - A combination of
'force-cache'
and'force-no-store'
in a single route is not allowed.
- A combination of
- A parent cannot provide
'default-no-store'
if a child provides'auto'
or'*-cache'
since that could make the same fetch have different behavior.
- If both the
- It is generally recommended to leave shared parent layouts as
'auto'
and customize the options where child segments diverge.
runtime
β
We recommend using the Node.js runtime for rendering your application, and the Edge runtime for Middleware (only supported option).
export const runtime = 'nodejs'
// 'nodejs' | 'edge'
export const runtime = 'nodejs'
// 'nodejs' | 'edge'
'nodejs'
(default)'edge'
Learn more about the different runtimes.
preferredRegion
β
export const preferredRegion = 'auto'
// 'auto' | 'global' | 'home' | ['iad1', 'sfo1']
export const preferredRegion = 'auto'
// 'auto' | 'global' | 'home' | ['iad1', 'sfo1']
Support for preferredRegion
, and regions supported, is dependent on your deployment platform.
Good to know:
- If a
preferredRegion
is not specified, it will inherit the option of the nearest parent layout.- The root layout defaults to
all
regions.
maxDuration
β
By default, Next.js does not limit the execution of server-side logic (rendering a page or handling an API).
Deployment platforms can use maxDuration
from the Next.js build output to add specific execution limits.
For example, on Vercel.
Note: This settings requires Next.js 13.4.10
or higher.
export const maxDuration = 5
export const maxDuration = 5
Good to know:
- If using Server Actions, set the
maxDuration
at the page level to change the default timeout of all Server Actions used on the page.
generateStaticParams
β
The generateStaticParams
function can be used in combination with dynamic route segments to define the list of route segment parameters that will be statically generated at build time instead of on-demand at request time.
See the API reference for more details.