NextJS v9.3 performance of getServerSideProps vs getInitialProps

[willemliu]

Hi,

So I've created a little demo to show-case all the different ways NextJS can do page-rendering: [csr, ssr, ssg].
You can find that demo here: https://static-next.willemliu.now.sh/
Code here: https://github.com/willemliu/static-next

In the NextJS documentation the following recommendation can be found:

However I've found a significant performance penalty in using getServerSideProps vs getInitialProps

You can check for yourself by navigating between SSR and Hybrid-SSR in the demo mentioned above. SSR implements getServerSideProps and Hybrid-SSR implements getInitialProps.
Both do exactly the same.

export async function getServerSideProps(context: any) {
    const res = await fetch(
        "https://static-next.willemliu.now.sh/api/test"
    ).then((res) => res.json());
    console.log("getServerProps", res, context.params, context.query);
    return {
        props: { ...res, name: context.query.slug }
    };
}

Index.getInitialProps = async (context: any) => {
    const res = await fetch(
        "https://static-next.willemliu.now.sh/api/test"
    ).then((res) => res.json());
    console.log("getInitialProps", res, context.params, context.query);
    return { ...res, name: context.query.slug };
};

It seems to me that the penalty comes from the extra roundtrip to the lambda getServerSideProps of that page upon navigation. Where with getInitialProps the client-side code runs getInitialProps and does the data fetching directly.

Knowing this, my question is what are the benefits of implementing getServerSideProps vs getInitialProps?

[timneutkens]

Covered quite a bit in #10920 (comment)

• Caching data becomes significantly simpler
• Doesn't affect bundle size, one example is that we currently see people shipping a markdown parser + compiler to the browser instead of pre-processing the markdown. Another is that we see gigantic data fetching libraries being used.
• Can directly run server-side code, for example right now you're fetching an API route in getServerSideProps, but you could import the function behind it and execute it in getServerSideProps if you're using API routes.
• Significantly easier to authorize requests based on cookies

In many of the cases where we see Next.js used there has to be some kind of caching layer as the data is not "live", eg it comes from a CMS that changes less than once per 1 second.

At ZEIT the full dashboard is static. If a page does require live data we client-side render it using: https://swr.now.sh/.

[timneutkens]

Right, that's just one of the benefits though. Generally the caching bit makes the most sense.

[Timer]

Adding my 2c: Even if you're directly calling another API, the effect should be much less pronounced if your deployed app is colocated with your API/data storage (i.e. same region—same data center).

I'd love to reevaluate this with more real-world use case.

[willemliu]

Adding my 2c: Even if you're directly calling another API, the effect should be much less pronounced if your deployed app is colocated with your API/data storage (i.e. same region—same data center).

I'd love to reevaluate this with more real-world use case.

In case of the example everything runs under the same application. The API route returns static data. So performance should be near optimal. For real projects I can only see a growing latency as real data-sources need to be called upon and maybe some application logic need to be applied.

[Timer]

In situations where everything is in the same application, getServerSideProps should never run a fetch request. It should directly invoke the method that returns the said static data.

[Timer]

In "real data-sources", getServerSideProps w/ a proper deployment strategy should result in less overall latency (or very similar with only one API call) because you're making one request over the WAN, and all other requests to sub-apis within the same data-center (especially for waterfall data requirements).

[willemliu]

In situations where everything is in the same application, getServerSideProps should never run a fetch request. It should directly invoke the method that returns the said static data.

I know but the example is written this way to mimic api calls. To closely match the architecture we have: REST api's.
And then we get to the discovery of the original post. That getServerSideProps is slower than getInitialProps.

[Timer]

The example is flawed in that it is showcasing a behavior which should never be implemented in a production application.

If you'd like to measure the performance impact of this, please invoke a 3rd party API instead of same-application and find the median latency.

This is the proper approach for your example:

diff --git a/pages/api/test.ts b/pages/api/test.ts
index 7ecb211..28d9e7e 100644
--- a/pages/api/test.ts
+++ b/pages/api/test.ts
@@ -1,15 +1,17 @@
 import Cors from "micro-cors";
 const cors = Cors({ allowMethods: ["GET", "HEAD"] });
 
+export function getData() {
+    return {
+        name: "Home",
+        date: new Date().toLocaleString()
+    };
+}
+
 function test(req, res) {
     res.statusCode = 200;
     res.setHeader("Content-Type", "application/json");
-    res.end(
-        JSON.stringify({
-            name: "Home",
-            date: new Date().toLocaleString()
-        })
-    );
+    res.end(JSON.stringify(getData()));
 }
 
 export default cors(test);
diff --git a/pages/ssr/[slug].tsx b/pages/ssr/[slug].tsx
index d2484e2..ece5db9 100644
--- a/pages/ssr/[slug].tsx
+++ b/pages/ssr/[slug].tsx
@@ -1,5 +1,6 @@
 import "isomorphic-unfetch";
 import { Regenerate } from "../../src/components/Regenerate";
+import { getData } from "../api/test";
 
 function Index(props: any) {
     return (
@@ -35,9 +36,7 @@ function Index(props: any) {
 }
 
 export async function getServerSideProps(context: any) {
-    const res = await fetch(
-        "https://static-next.willemliu.now.sh/api/test"
-    ).then((res) => res.json());
+    const res = await getData();
     console.log("getServerProps", res, context.params, context.query);
     return {
         props: { ...res, name: context.query.slug }

[Timer]

To be clear: I'm not disagreeing that in your example getServerSideProps is slower than getInitialProps. It's just improper use (as is)!

[willemliu]

The example is flawed in that it is showcasing a behavior which should never be implemented in a production application.

If you'd like to measure the performance impact of this, please invoke a 3rd party API instead of same-application.

This is the proper approach for your example:

diff --git a/pages/api/test.ts b/pages/api/test.ts
index 7ecb211..28d9e7e 100644
--- a/pages/api/test.ts
+++ b/pages/api/test.ts
@@ -1,15 +1,17 @@
 import Cors from "micro-cors";
 const cors = Cors({ allowMethods: ["GET", "HEAD"] });
 
+export function getData() {
+    return {
+        name: "Home",
+        date: new Date().toLocaleString()
+    };
+}
+
 function test(req, res) {
     res.statusCode = 200;
     res.setHeader("Content-Type", "application/json");
-    res.end(
-        JSON.stringify({
-            name: "Home",
-            date: new Date().toLocaleString()
-        })
-    );
+    res.end(JSON.stringify(getData()));
 }
 
 export default cors(test);
diff --git a/pages/ssr/[slug].tsx b/pages/ssr/[slug].tsx
index d2484e2..ece5db9 100644
--- a/pages/ssr/[slug].tsx
+++ b/pages/ssr/[slug].tsx
@@ -1,5 +1,6 @@
 import "isomorphic-unfetch";
 import { Regenerate } from "../../src/components/Regenerate";
+import { getData } from "../api/test";
 
 function Index(props: any) {
     return (
@@ -35,9 +36,7 @@ function Index(props: any) {
 }
 
 export async function getServerSideProps(context: any) {
-    const res = await fetch(
-        "https://static-next.willemliu.now.sh/api/test"
-    ).then((res) => res.json());
+    const res = await getData();
     console.log("getServerProps", res, context.params, context.query);
     return {
         props: { ...res, name: context.query.slug }

Thanks I'll try to modify the example to hook up with a real external API to check the real-world impact.

[willemliu]

Sadly don't have time this week. Will start on it beginning of next week.

[willemliu]

After deploying to bru1 I get similar numbers.

[willemliu]

Also, for the getServerSideProps version, could you please pass a server version of fetch to the ApolloClient configuration to see if it helps?

I'd love to know if @zeit/fetch improves the performance on the server:
https://github.com/zeit/fetch

I've just checked zeit/fetch and saw this message at the bottom of the README.md:

And in my example I'm using isomorphic-unfetch. Which already uses node-fetch on the server-side. So I don't think it does anything for the performance of the fetch implementation itself on de server-side.

[willemliu]

While searching for some docs about ApolloClient it became clear that it uses global fetch or another fetch implementation if passed as option. In the example I'm using isomorphic-unfetch which sets node-fetch as the global fetch when on server-side. So I don't think I can improve performance there anymore.

[asim-basraa]

May be not directly related but please allow me to add my observation about getServerSideProps.
I have just deployed new version of nextjs app using getServerSideProps and only reason was to minimize bugs caused by node-fetch mostly related to socket hangups errors due to getinitialprops limitations that we had to use rest API data layer.
Our website got 70000 links and it's updated 100s times a day with new pages and tags. Which resulted generating Google sitemap pings, which will kickoff Google parser to parse website again.
It chocked node-fetch as concurrency gets very high at times causing socket hangups. After changing infrastructure so many times we had to move to getServerSideProps approach and take out fetch calls from backend.
Once we got socket hangups only way to recover was restarting nodejs.
Big thank you for releasing getServerSideProps.

Off course other solution was to manage concurrency with caching and request throttling, using proxies etc. But this solution let us access database directly rather than exposing it to out world. And I can see boost in performance in my use case.

[vishalvijay]

Hi

In our case, NextJS website is running under www.example.com and all our APIs are served separately under, api.example.com (with appropriate CORS headers enabled). Also, api.example.com has it's own caching strategy enabled.

As new version of NextJS recommend using getServerSideProps instead of getInitialProps, we considered migrating our existing getInitialProps implementation with getServerSideProps. But soon we realized that this change will increase our TTL because getServerSideProps is adding an unnecessary proxying layer by routing the API call through www.example.com instead of directly calling the api.example.com from the browser.

Also, reading multiple issue threads in Github gave us an understanding that, getInitialProps is not deprecated, we can still use that.

So my concern is, the use case for getInitialProps and getServerSideProps is slightly different. So I don't think getServerSideProps is a replacement for getInitialProps and NextJS doc is misleading it by saying it is the recommended way.

So my understanding is =>

• Use getInitialProps if the backend API service is decoupled from NextJS.
• Use getServerSideProps if the backend data available in NextJS without any extra API roundtrip. Or avoid CORS by proxying it through NextJS backend.

Please correct me if I'm wrong.

[willemliu]

I believe there is an extra point to take into consideration and that's: Environment variables.
Before getServerSideProps we had build.env and env or serverRuntimeConfig and publicRuntimeConfig to consider. This needed to be configured very carefully and correctly otherwise one risks exposing secret keys to the client-side.
Using getServerSideProps has the benefit that you no longer need to consider this.

[avxkim]

That makes sense, still don't get, why do they recommend using getServerSideProps for everyone, they consider that everyone's using next api routes on the same domain?

[msreekm]

Another big limitation with getServerSideProps is - if you are using graphql and is using apollo client, apollo client can walk down the component hierarchy using getInitialProps and execute the graphql queries at each level , whereas with getServerSideProps you have to move all your queries to top level page component. Hopefully getInitialProps is not going away soon! if they deprecate getInitialProps ,lot of people will move to gatsby!

[francisrod01]

I've moved to Angular 11 and I'm happy about that. :)