Performance on SSR pages in my app is slow, probably due to experimental-serverless-trace target

[dphang]

Hi, first thanks for creating an awesome framework! We are using serverless-next.js to deploy our Next.js app to AWS Lambda / CloudFront since we are already heavily using AWS infrastructure.

This is a problem/question/request, so I don't think it fits completely in one category.

Problem

I was helping take a look at an issue where when using experimental-serverless-trace target, the cold start request duration seems to have increased. For my production app, it went from ~1.5-2 seconds to 4-5 seconds. We have ~15 SSG and ~2 SSR pages.

Upon investigation, we found that experimental-serverless-trace outputs doesn't optimize requires for each page JS, so when you include all dependencies as a node_modules folder, then you may include components that are not needed.

For example, using a popular UI framework like MaterialUI, if you import just one component e.g Typography from "@material/core" then the page JS will require the entire contents of @material/core, which if you just include all dependencies as-is, you will pull in ~129 components, most of which would be unused:

Here's a test repro: https://github.com/dphang/nextjs-repros, with a very simple app with 3 SSR pages (which getInitialProps doesn't call any external APIs, just returns some fixed data) which showcases the above.

If I import Typography:

import { Typography } from "@material-ui/core";

index.js will require entire @material-ui/core which has 129 components:

/***/ "KK5V":
/***/ (function(module, exports) {

module.exports = require("next/dist/next-server/server/render");

/***/ }),

/***/ "KKbo":
/***/ (function(module, exports) {

module.exports = require("@material-ui/core");

/***/ }),

Max response times on serverless-next.js went from ~700 ms to ~1.5 seconds (based on sample of ~400 requests benchmark each using k6.io and around 20 concurrent requests for 30 seconds) as a result of Lambda having to cold start and load into memory unnecessary code. When this plugin included node_modules, it includes unnecessary code due to unoptimized requires in the pages, e.g it takes up 22 MB uncompressed vs. 2.9 MB if bundled & optimized in a single page JS (which will require just @material-ui/core/Typography).

I believe the same problem might be happening on Vercel. I also see the same ~1.4-1.5 second response times at high percentiles (~400 requests in 30 seconds). Obviously I don't know the underlying infrastructure, but AFAIK Vercel uses experimental-serverless-trace for its deployments too, so it may be suffering from a similar issue. But I'm not sure if this is a problem there too?

App link: https://nextjs-repros.vercel.app/. I'll also try to test our production app's SSR perf on Vercel, but I suspect the same perf issues.

Request

Perhaps experimental-serverless-trace target needs to optimize its imports by tree-shaking/rewriting the requires for each of the page outputs? So then any kind of downstream code (serverless-next.js, Vercel, etc.) that needs to consume these outputs to produce a bundle will not include unnecessary code in dependency code e.g node_modules. They will not need to do their own optimizations apart from just including the dependency code somewhere.

Thanks in advance!

Notes

All Lambda tests are using 1024 MB memory, Node.js 12.x runtime.

Also, the related issue is here, which has more details if you need them (like performance benchmarks): serverless-nextjs/serverless-next.js#547.

[kartikag01]

I was getting RequestEntityTooLargeException so tried moving to experimental-serverless-trace, then error is fixed.
Worried about SSR Performance, @dphang were you able solve this ?

@Timer @timneutkens why experimental-serverless-trace is still in experimental it been so long since it was launched. can we move to non experimental feature ?

[dphang]

I did not solve it using the serverless trace target / Vercel, but my pages are small enough that I could use the serverless-next.js component (not Vercel) with the regular serverless target + minification and it is fast (disclosure: I am helping maintain the serverless-next.js component and authored some of these optimizations).

As mentioned, I think with regular serverless target, webpack is doing the code elimination correctly per-page (only including necessary dependent code) so it gets rid of a lot of code there. But with serverless trace target, it extracts common dependencies used in node_modules and it's shared once. But it doesn't seem to be as optimized as a per-page bundle.

My main problem was with large dependencies like @material-ui, I found when you import as deep as possible it should help optimize unused code even with using serverless trace target (though for me it's not needed, since I'm not using serverless trace). For example, instead of:

import { Typography } from "@material-ui/core";

you can do:

import Typography from "@material-ui/core/Typography";

In first case, it causes serverless trace (and I think Vercel too AFAIK?) to include the entire @material-ui/core library, whereas I really want just Typography. With serverless-trace target (on serverless-next.js component) though, I think there was negligible difference. I also added eslint rules so I don't accidentally reintroduce issues, although I don't really need it:

  rules: {
    "no-restricted-imports": [
      "error",
      "@material-ui/lab",
      "@material-ui/core",
      "@material-ui/icons",
      "@material-ui/*/*/*",
      "!@material-ui/core/test-utils/*"
    ]
  }

[timneutkens]

why experimental-serverless-trace is still in experimental it been so long since it was launched. can we move to non experimental feature ?

It's no longer being used so the only way forward would be to remove the experiment, not land it. It's only still in the codebase for backwards compatibility.

[kartikag01]

@timneutkens do you mean to remove experimental from experimental-serverless-trace or droping experimental-serverless-trace feature completely ?

[timneutkens]

Removing the code indeed, but we're keeping it for a while for backwards compat.

[gopeter]

@timneutkens so experimental-serverless-trace will be removed sometime in the future? Does Vercel no longer use this target itself (as mentioned here or here for example)? Just asking, because other hosting platforms (like Netlify, Amplify or Serverless) solve a lot issues by using this target.