getStaticProps and getServerSideProps | What’s the Difference?
This post was written before the release of NextJS 13.
I recommend you taking your time while reading this, as this concept is in the foundation of Nextjs.
getStaticProps and getServerSideProps can be defined as follows:
- getStaticProps(): A method that tells the Next component to populate props and render into a static HTML page at build time.
- getServerSideProps(): A method that tells the Next component to populate the props and render into a static HTML page at run time.
Rendering at build time with getStaticProps() means that prior to hosting the page, the developer (or automation tool) converts the React into raw HTML pages, and only then are the pages hosted and served to clients. Raw HTML pages are optimal for SEO and fast page loading.
In combination with getStaticPaths(), file generation is done so that the pages are ready to be served to users. When feeding getStaticPaths() items containing an identifier for the route (e.g. posts/[id].js), it will push the identifiers (i.e. id) to getStaticProps() so that getStaticProps() can fetch the needed props based on the required identifier. So what happens to routes requested which are not included in the predefined paths? This is where fallback comes in. Fallback has three options, either ‘false’, ‘true’ or ‘blocking’.
When ‘true’ all paths will be prerendered, paths that have not been generated at build time will not result in a 404 page. This feature is helpful when having an app with a very large number of static pages which depend on data (NextJS uses e-commerce site as example).
When ‘false’ all paths that have not been generated at build time will result in a 404 page. A perfect case for when you don’t add new pages often. When you do, you’ll need to run ‘next build’ again.
When ‘blocking’ all paths that have not been generated at build time will render server side. This will not updated genereated pages by default (Incremental Static Regeneration).
Rendering at run time with getServerSideProps() **means that the site is live and hosted with React components sitting on the server awaiting a request. However, when a request is made, the server doesn’t send the Javascript React files to the client for rendering. Instead, NextJs tells React to go ahead and render these components into HTML in real time, then send the HTML to the client.
When to use getStaticProps or getServerSideProps?
If you need a lot of dynamic data on your page, it’s more scalable to render your page at run time (SSR), and therefore getServerSideProps would be the preferred method. Pages built using getServerSideProps for SSR won’t be as fast as SSG, however, it is optimal when compared to utilizing a standard SPA framework.
If your page is more simple in nature, such as a blog post, you’ll get a performance boost rendering a static HTML page at build time (SSG), and therefore getStaticProps would be preferred. Pages built using getStaticProps for SSG will be very fast.
You might wonder what if I need to update the blog post? Either via code or a CMS. This is where on-demand revalidation comes in. It’s used to mitigate a stale static page from being shown to users if/when its data has been updated. Next v12.2.0+.
NextJS on this topic.
If you set a
revalidate time of 60, all visitors will see the same generated version of your site for one minute. The only way to invalidate the cache is from someone visiting that page after the minute has passed.Starting with
v12.2.0, Next.js supports On-Demand Incremental Static Regeneration to manually purge the Next.js cache for a specific page. This makes it easier to update your site when:- Content from your headless CMS is created or updated
- Ecommerce metadata changes (price, description, category, reviews, etc.)
Inside
getStaticProps, you do not need to specify revalidate to use on-demand revalidation. If revalidate is omitted, Next.js will use the default value of false (no revalidation) and only revalidate the page on-demand when revalidate() is called.On-demand revalidation is a feature of Incremental Site Generation (ISG).
Then what is the difference between getServerSideProps and Client-Side data fetching?
Client-side data fetching is useful when your page doesn’t require SEO indexing, when you don’t need to pre-render your data, or when the content of the page needs to update frequently.
Unlike getServerSideProps, client-side data fetching still works at the component level.
If done at the page level:
- data is fetched at runtime
- content of the page updated as data changes.
If done at the component level:
- data is fetched at time of component mount
- content of component is updates as data changes.
Cons of client-side data fetching
Client-side data fetching affects performance and load speed of page.
This is because the data fetching is done at the time of the component or pages mount, and the data is not cached.
Sources
https://www.ohmycrawl.com/getstaticprops-vs-getserversideprops/#gspvsgssp-difference