Benchmarking the Next.js server vs nginx at serving a static site

Adam Jones

Personally

This is my personal blog, where I write solely in my personal capacity. It does not represent the positions of any organisations I'm associated with.

Also, everything here is provded "as is", without warranties of any kind, express or implied.

29 April 202429 April 2024

Update: I did a follow-up with a more realistic setup, showing what the performance looks like when this is running on a remote server.

Next.js is a React framework that allows you to build web applications. It offers a bunch of neat features to make web development easier.

1. Export the files and serve them with nginx or similar
2. Use the default Next.js production server (next build && next start)
3. (not recommended²

   I think the HMR functionality opens up additional attack surface area, and I expect this to be a lot slower. I’m testing this anyway as I could imagine people doing this by mistake.

   ) Use the Next.js development server (next dev)

My suspicion is that 1 is likely the fastest. However, 2 might often be simpler - both because you don’t need to configure a second web server, and it means your deployment configuration can be the same across static and dynamic Next.js apps.

Knowing how much slower this is allows us to properly evaluate this penalty, and make evidence-based decisions about what trade-offs we might be making.

So, how fast is it? I took this blog (yes, the very one you’re reading) and tested out how long it takes to load.

events {}

http {
    server {
        listen 8080;
        root ./dist;

        index index.html;
        error_page 404 /404.html;

        location / {
            try_files $uri $uri/ $uri.html =404;
        }
    }
}

Median HTTP load times, high reqs/second (i.e. for the HTML response, using k6):

Median page load times, no additional reqs/second (i.e. for the browser to consider the page fully loaded, using Puppeteer):

Takeaways

Wow, nginx is fast - 4874x faster than Next.js under heavy load for median response time. I had some sense of this before, but just quite how much it dominates on request duration. I think this is largely because Next.js slows down quite a bit under heavy request load, given Next.js’s median time when only processing a single request was much lower.

That said, the Next.js server is plenty fast for real-world use cases. It was just 20ms slower (a fifth of a blink) to actually load the page under low load, and even under heavy load (3733 requests/second) it still had a median request duration of 253ms.

The real-world penalty will also likely be lower than this: network latency will likely start to dominate. And if you’ve got dynamic requests to APIs, that will almost certainly be the bottleneck rather than the static file serving.

Overall, with this small of a penalty in most cases I’d pick running Next.js given it’s significantly easier to set up (provided you’re building a Next.js app already), and means your deployment can be standardised across static and dynamic applications. Only when you’re getting hundreds or thousands of requests per second, or if you've already got a really smooth nginx pipeline, does it probably become worth looking at this.

Update: I did a follow-up with a more realistic setup, showing what the performance looks like when this is running on a remote server.