Prerendering methods and data fetching strategies in JSS Next.js apps

Current version: 19.x

In Next.js apps, there is a strong correlation between prerendering methods and data fetching.

JSS applications created based on the JSS Next.js sample application support all the prerendering forms supported by Next.js applications and, like regular Next.js apps, use different data fetching strategies for each prerendering form.

Static (site) generation (SSG/SG) or server-side rendering

When creating a JSS Next.js app, the application is initialized with some default options. The default prerendering method is static site generation (SSG), but you can choose server-side rendering (SSR) by providing the --prerender parameter with the value SSR.

The prerendering form you choose determines the data fetching strategy. When scaffolding a JSS Next.js app, the data fetching functionality in the optional catch-all route /src/pages/[[...path]].tsx is tailored for the prerendering method you chose when creating the app or for the default method - SSG.

The JSS Next.js sample application includes examples of both data fetching strategies.

When creating a JSS Next.js app using default options or specifying --prerender SSG , the app creation script copies the file src/pages/[[..path]].tsx, which implements the functions GetStaticPaths and GetStaticProps. The GetStaticPaths implementation generates a list of paths that must be statically generated using the GraphQL Sitemap Service.

When creating a JSS Next.js app specifying --prerender SSR , the app creation script copies the file src/pages/[[..path]].SSR.tsx and renames it to src/pages/[[..path]].tsx. This file implements the function GetServerSideProps.

The implementations of GetStaticProps and GetServerSideProps leverage the SitecorePagePropsFactory definition in the file src/lib/page-props-factory.ts.


You can switch to another method after app creation.

Preparing page data

The class SitecorePagePropsFactory exposes the method create(context: GetServerSidePropsContext | GetStaticPropsContext) that is responsible for fetching all data needed to render the page (the page props), depending on the context.

The method returns an object of the type SitecorePageProps with the following structure:

export type SitecorePageProps = {
  locale: string;
  layoutData: LayoutServiceData | null;
  dictionary: DictionaryPhrases;
  componentProps: ComponentPropsCollection;
  notFound: boolean;

To prepare the page data, SitecorePagePropsFactory uses the JSS Layout API and the JSS Dictionary API for fetching the data making it available to the page in the page props.

The following table describes the page props data:




The factory retrieves the context locale as configured in the i18n entry in the file next.config.js. Otherwise, it uses the config.language defined in the package.json file.


The layoutData property stores LayoutServiceData from the Sitecore Layout Service REST API using the JSS RestLayoutService or the Sitecore GraphQL Edge schema using the JSS GraphQLLayoutService.

In SSR context, it sends the context request and context response to provide the ability to use Sitecore tracking and analytics.


The dictionary property contains DictionaryPhrases from either the Sitecore Dictionary Service REST API (RestDictionaryService) or the Sitecore GraphQL Edge schema (GraphQLDictionaryService).


The componentProps property contains data fetched by the ComponentPropsService. The ComponentPropsService executes the functions getStaticProps/getServerSideProp in those components that implement these functions. The structure of componentProps is a key-value map of the format { [renderingUID]: data }.


If the Layout Service returns a 404 status for our page route, it sets the value of notFound to true, triggering the custom NotFound page with the correct 404 status.

Next.js Preview context while requesting a page in editing mode

While working in a Sitecore editor, the JSS Next.js application enters preview mode , and the SitecorePagePropsFactory uses the editingDataService to retrieve layoutData, dictionary, and language data sent with the editing request.

Incremental static regeneration (ISR)

When statically generating JSS Next.js pages, you can update static pages after you have already built the application for production by using incremental static regeneration. To use ISR, you define the revalidate property in the GetStaticProps implementation for that page.

Hybrid rendering

You can create new pages in a JSS Next.js application and even use dynamic routes. For example, you can add a page to show an index of articles in the file src/pages/articles/index.tsx and a page to display a single article in the file src/pages/articles/[id].tsx.

In an otherwise statically generated app, pages with dynamic content benefit from being server-side rendered because you most likely want such pages to be publicly accessible, indexed by search engines, and editable with a Sitecore editor. Additionally, you might have a considerable number of articles, leading to a long build process if you use static generation.

Pre-rendering and data fetching in JSS Next.js applications have a bi-directional relationship. To server-side render the new pages, all you need to do is implement the GetServerSideProps function to get the initial data for the pages and make sure the code defined or used in the pages is compatible with SSR. All other pages can still use SSG data fetching strategies, including incremental static regeneration.

In a hybrid application, where some pages are server-side rendered and others are statically generated, Next.js automatically renders routes/pages that use getStaticProps as static HTML files if they are compatible with static HTML generation.

Do you have some feedback for us?

If you have suggestions for improving this article,