Difference b/w fallback:true on getStaticProps and getServerSideProps

[kvedantmahajan]

Reading the documentation on Data Fetching, I am not clear for what is the difference apart from CDN caching if I choose fallback:true in static rendering for my dynamic routes.

Here is my understanding -:

Let's say I have [someDynamicPageSlug].js and I will need to have getStaticPaths to render top 10 slug pages and getStaticProps with fallback:true will serve rest of the pages generating them on demand for first time and then next time it will serve it right out of CDN.

Now, it is mentioned under getServerSideProps when to use section that in increases the Time to first Byte (TTFB ). My first question is will not fallback:true do the same for first time render of a page which doesn't exists in getStaticPaths and have same TTBF?

I'm asking because, I'm evaluating if I can simply use getServerSideProps with manual caching option instead of defining getStaticPaths and getStaticProps with fallback:true.

Second question is that is there any SEO impact in picking one strategy over the other. The way docs are put up there doesn't seems to be but if someone has worked on the scale of million metrics and have seen any difference please let me know.

I will appreciate to sufficiently deep these about it. How they work internally (if possible) as reading the docs, gives a black box to people like me for inner workings of it.

Thanks in advance!

[lfades]

Let's say I have [someDynamicPageSlug].js and I will need to have getStaticPaths to render top 10 slug pages and getStaticProps with fallback:true will serve rest of the pages generating them on demand for first time and then next time it will serve it right out of CDN.

It's always served through a CDN, the fallback page is also a static page.

Now, it is mentioned under getServerSideProps when to use section that in increases the Time to first Byte (TTFB ). My first question is will not fallback:true do the same for first time render of a page which doesn't exists in getStaticPaths and have same TTBF?

No, the fallback will be way faster because it's a static page. Once it loads it will start fetching the data in the browser and populate it after that. The fallback page is like a loading state.

With getServerSideProps you're making your user wait on a blank page until the server sends the html of the page.

Second question is that is there any SEO impact in picking one strategy over the other. The way docs are put up there doesn't seems to be but if someone has worked on the scale of million metrics and have seen any difference please let me know.

If you need SEO but also want to have static pages, consider using fallback: 'blocking' (currently an experimental feature).

[kotsh23]

Thank you for fallback:'blocking' you saved my life
because with fallback true there is no source of posts so SEO is bad
and with fallback : false , with an arabic slug its cause a problem
Thank you

[kvedantmahajan]

No, the fallback will be way faster because it's a static page. Once it loads it will start fetching the data in the browser and
and populate it after that. The fallback page is like a loading state.

So, here is my understanding. Time to first byte is faster because we are showing something because of fallback property. And then when a page is finished compiling in the background on server, it caches it on CDN and then ships it down to browser and for that reason I am always getting it via CDN. Right? Basically, it is like client side rendering for fallback component and the hydration happens for the actual page later. Now, let us understand the impact of SEO since you mentioned fallback: 'blocking'. Does this mean that fallback: true approach has zero SEO benefits despite the page is pre-rendered?

[lfades]

Does this mean that fallback: true approach has zero SEO benefits despite the page is pre-rendered?

It depends. fallback: true is a good option for pages behind authentication (where SEO doesn't matter) or that aren't public. Alongside getStaticPaths you can use it to pre-generate all the known pages at build time (SEO will be okay here as those won't have a fallback) and have a fallback for new pages. fallback: 'blocking' does the same thing but it won't use a fallback but insteadl it will make visitors wait if there's a new page being requested.

[kvedantmahajan]

Understood!

So what is the difference then b/w fallback:blocking and getServerRenderProps? Since both will make user wait for requested page.

[lfades]

@kushalmahajan With fallback: 'blocking' the result will be cached, so the next time someone hits the same path, that request will get static HTML instead of waiting for a serverless function. With getServerSideProps you always wait.

[taylorklodowski]

@lfades Hi - wondering if fallback: 'blocking' is stable enough to be used in a production app? I don't see this in the Next docs, however, it is the exact use case we need to cover in order to avoid soft 404s on our pages.

[lfades]

@taylorklodowski Yes, fallback: 'blocking' was released in Next.js 10, it should have no issues and you're welcome to use it 👍 . It will be included in docs with the next minor release (the docs are already on canary but our site uses the docs from the latest stable release)