[Page Router] [SSR] [GSSP][high TTFB] Long time taken for SSR html generation

[MD-Sean]

Summary

Currently facing high SS Page generation on my NextJS Application site, with GSSP props payload < 128Kb. But still im suffering long server response. Any insights from the wide audience is appreciated. 🫡

Attached below a simplified version on how my GSSP looks like

End result logs on "finish"

tsrt: 829 ms, fsrt: 2240 ms

TTFB > 2seconds on production.

Additional information

export const getServerSideProps = async (context: Context) => {
  const { query, resolvedUrl, req, isServer, res } = context;

  let endTime;
  const startTime = process.hrtime()
  let tsrt: number;
  let fsrt: number;

  // Function to measure TTFB
  const measureTTFB = (res: any) => {
    try {
      const originalWriteHead = res.writeHead;
      res.writeHead = function (...args: any[]) {
        try {
          const writeHeadTime = performance.now();
          if (isServer && Array.isArray(startTime)) {
            const startTimeMs = startTime[0] * 1000 + startTime[1] / 1000000;
            fsrt = writeHeadTime - startTimeMs;
          } else {
            fsrt = writeHeadTime - (startTime as number);
          }
          return (originalWriteHead as ServerResponse["writeHead"]).apply(this, args);
        } catch (error) {
          console.error("Error in writeHead timing:", error);
          return (originalWriteHead as ServerResponse["writeHead"]).apply(this, args);
        }
      };
    } catch (error) {
      console.error("Error setting up TTFB measurement:", error);
    }
  };
  
  measureTTFB(res);

  res.on("finish", () => {
    console.log(
      `tsrt: ${tsrt?.toFixed(2) || "N/A"} ms, fsrt: ${fsrt?.toFixed(2) || "N/A"} ms`
    );
  });

---  
  Multiple API calls
----

    endTime = process.hrtime(startTime);
    tsrt = endTime[0] * 1000 + endTime[1] / 1000000;
  
    return {
      props: {
       ... 
      }

Example

No response

[icyJoseph]

Are you doing your API calls sequentially? Could you post some pseudocode of what's going on there?

[MD-Sean]

@icyJoseph Here i attached the diagram for your reference. All APIs call are grouped instead of firing one by one with promise.all()
Observation is fsrt >>> tsrt

[icyJoseph]

I am trying to remember here, but I think, it could often happen that the common JavaScript bundle is large, and adds latency to the module loading step (to know what JS to run to render components)

Are you using icon libraries? material-ui? what's the size of the JavaScript bundles in your application? https://www.npmjs.com/package/@next/bundle-analyzer can help to see those better, but the build command output has some good insights too

[MD-Sean]

Built Bundle

Dev Bundle

FYI for icons library, we uses:

• Internal Design system package's icon
• minor mui icon
• remote url for icons

[icyJoseph]

I think you need to, somehow try to reduce the amount of JS used in general, maybe try to lazy load some of the libraries you need, if using next/dynamic, I think you can do {ssr: false}, to try to break _app and other bundles into smaller chunks.

[AzizB283]

It looks like your getServerSideProps isn't inherently heavy in terms of payload, but the TTFB > 2s suggests the issue likely stems from either blocking I/O or inefficient API orchestration. Here are a few focused suggestions to help diagnose and improve:

1. Check API Call Latencies Individually
   If you're making multiple external/internal API calls inside getServerSideProps, log the duration of each. Even if payloads are small, network latency or cold starts (e.g., on serverless platforms like Vercel) can stack up quickly.

2. Parallelize API Calls
   If the calls are independent, run them in Promise.all to avoid sequential delay.

[icyJoseph]

In their diagrams, they show what they call, tsrt, which is the latency for API requests. That one is just above 800ms. The time span fsrt, is the one that's extending into the rendering section, and that one goes on for 2 seconds.

[AzizB283]

Thanks for pointing that out — yep, that aligns with what I suspected.

If the page contains large or deeply nested components (, , etc.), the SSR render time might spike — especially if there's no React.memo or component optimization.

Try profiling the page locally using next dev + Chrome DevTools → Performance tab → capture the server-side render frame.

[icyJoseph]

But they are already doing with their custom TTFB function. How would you go about identifying which imports, in Next.js v12, are causing this issue.

[MD-Sean]

@icyJoseph @AzizB283 Thanks for providing the valuable inputs even though i had tried some of them before as I could.
Fortunately thank god finally we found the root cause. It's due to an experimental.optimizeCss setting in the NextConfig.
Somehow blocking the page from SSR / html generation. I took up to x seconds to load

  experimental: {
    optimizeCss: true,
  },

File like below is generated based on the config. But they have no improvement for our case.
Inlined 2.73 kB (1% of original 181.42 kB) of https://cdn/static-assets/web-listing/_next/static/css/cea7638987e8d9e3.css.
Inlined 97 bytes (1% of original 5.65 kB) of https://cdn/static-assets/web-listing/_next/static/css/c99e85fb186d13c2.css.
Time 1938ms

Extra info: Significant improvement we found on the SSR even though the payload size is > 128kB