getServerSideProps: more server load than getInitialProps?

[fabb]

From the documentation I understand that getServerSideProps causes more requests to the next server:

When you request this page on client-side page transitions through next/link (documentation), Next.js sends an API request to server, which runs getServerSideProps. It’ll return a JSON that contains the result of running getServerSideProps, and the JSON will be used to render the page.
https://nextjs.org/docs/basic-features/data-fetching

I would need to measure, but it sounds like this could make scaling up the next servers necessary on high-traffic websites, going along with higher costs.

I understand that it provides different benefits, like smaller response payloads, and not having to have isomorphic code in that function. In the end it‘s a tradeoff.

Since getInitialProps is now discouraged, will users of the framework be able to decide which end of the tradeoff they want to use in the future?

[timneutkens]

As said in the blogpost you can use getInitialProps still if you want to, it's not deprecated.

Most use-cases will be covered by getStaticProps very soon, and when using getServerSideProps you should implement CDN caching (or server-side caching). In many cases where we talked to enterprise high-traffic site teams they couldn't figure out how to do that after using getInitialProps, so getServerSideProps gives a better incremental path towards faster sites than getInitialProps.

[fabb]

when using getServerSideProps you should implement CDN caching (or server-side caching).

Thanks, do you have more info on this? We currently only serve our _next directory from a cache server, but I guess that is not what you mean.

[timneutkens]

Caching dynamic responses, which is generally an enterprise feature on CDN providers.

On ZEIT Now it's available on all plans including free through res.setHeader('Cache-Control, 's-maxage=1, stale-while-revalidate') this makes the dynamically rendered response cached on the CDN: https://zeit.co/smart-cdn.

Most CDN providers use s-maxage in a similar way, but it's only available on enterprise plans.

[fabb]

Ah ok something like this:

We host ourselves, so we would need to build up such a cache ourselves. Probably a conceptually hard task, we have a tens of millions of pages in the Google index.

[willemliu]

From the documentation I understand that getServerSideProps causes more requests to the next server:

When you request this page on client-side page transitions through next/link (documentation), Next.js sends an API request to server, which runs getServerSideProps. It’ll return a JSON that contains the result of running getServerSideProps, and the JSON will be used to render the page.
https://nextjs.org/docs/basic-features/data-fetching

I would need to measure, but it sounds like this could make scaling up the next servers necessary on high-traffic websites, going along with higher costs.

I understand that it provides different benefits, like smaller response payloads, and not having to have isomorphic code in that function. In the end it‘s a tradeoff.

Since getInitialProps is now discouraged, will users of the framework be able to decide which end of the tradeoff they want to use in the future?

I've created a similar post with performance results of both implementations. The getServerSideProps has the penalty of an extra network roundtrip: #10930