What version of Next.js are you using?

10.0.9

What version of Node.js are you using?

v15.11.0

What browser are you using?

Chrome

What operating system are you using?

macOS

How are you deploying your application?

next start

Describe the Bug

First render of each page has large TTFB. It can be seen in any example (e.g. api-routes-apollo-server-and-client-auth-app).

$ yarn create next-app --example api-routes-apollo-server-and-client-auth
$ yarn build
$ NODE_ENV=production yarn start

First request of localhost:3000/about has TTFB about 1–1.5s. All subsequent requests will have TTFB about 20ms. This is also reproducible if using a simple custom server.

This overhead is due to the fact that dependencies are imported on demand when the user requests a page (https://github.com/vercel/next.js/blob/27555c8ef9b06ff71e245e086db191103ecd2026/packages/next/next-server/server/next-server.ts#L1276-L1280).

In real complex applications this overhead can increase TTFB to tens of seconds.

The second time the page loads faster, since the modules are cached (in ssr-module-cache.js).

Module import is reading the file and interpreting the code. These are two very slow operations, especially if there is a lot of code.

Let’s imagine an application with two pages: page1 and page2. It will compiled into the next 4 modules: _app, _document, page1, page2. Using this application can be summarized as the following table.

Cache	Action	Missing dependencies	Speed
[]	Server start	[]	fast
[]	Request page1	[_app, _document, page1]	slow
[_app, _document, page1]	Request page1	[]	fast
[_app, _document, page1]	Request page2	[page2]	medium
[_app, _document, page1, page2]	Request page2	[]	fast

You can see freeze even if page is statically optimized (because _app and _document are imported even in the case of static optimization).

I think some issues and duscussions about performance (e.g. https://github.com/vercel/next.js/discussions/12447) is about this overhead.

But! I have a workaround. It looks like warming up the cache.

const path = require("path");
const serverPath = path.join(__dirname, "./.next/server");

module.exports = () => {
  try {
    const pagesManifest = require(path.join(serverPath, "pages-manifest.json"));

    Object.values(pagesManifest).forEach((dep) => {
      if (path.extname(dep) !== ".js") {
        return;
      }

      console.log("preimport ", dep);
      require(path.join(serverPath, dep));
    });
  } catch (e) {}
};

Full example:

• https://github.com/gwer/next-js-initial-freeze-workaround
• https://github.com/gwer/next-js-initial-freeze-workaround/blob/master/pages-preimport.js

If you run this function before starting the custom server, it will save you from overhead.

Cache	Action	Missing dependencies	Speed
[]	Server start	[_app, _document, page1, page2]	slow
[_app, _document, page1, page2]	Request page1	[]	fast
[_app, _document, page1, page2]	Request page1	[]	fast
[_app, _document, page1, page2]	Request page2	[]	fast
[_app, _document, page1, page2]	Request page2	[]	fast

This approach has two minor drawbacks:

1. Server starts slower.
2. Memory consumption grows faster. But the peak memory consumption is the same as without using the workaround.

How about doing the same, but inside the Next.js server?

Expected Behavior

There should be no overhead for the first page rendering.

To Reproduce

$ yarn create next-app --example api-routes-apollo-server-and-client-auth
$ yarn build
$ NODE_ENV=production yarn start

Open localhost:3000/about twice and look at TTFB.

Current state (2022-09)

_app and _document are preimporting by default since February 2022 (https://github.com/vercel/next.js/pull/23261).

For pages preimport you can use simple package next-pages-preimport.