Next.js: minimal next.js bundle 185kb gzipped

[realalexhomer]

Bug report

Describe the bug

Thanks for the great library, we have been very glad to use it.

My bug report is that In the FAQ it says "a small next.js bundle is around 65kb gzipped". I've been doing some performance auditing today and I'm curious if I'm doing something wrong or not, because with React, ReactDOM and Next.js in a hello world app I'm seeing a 185kb main.js file.

Is there a minification step I need to include? Should the example be updated with this? main.js seems to be gzipped from looking at the headers and trying to compress it with compression and seeing no difference.

I'm using a custom server from the example to reproduce this, and typescript, although that shouldn't make a difference.

To Reproduce

Using the custom server typescript example:

yarn create next-app --example custom-server-typescript custom-server-typescript-app

npm run build

npm run start

navigate to localhost:3000 in Firefox, go to network tab and look at mainjs:

Expected behavior

Bundle size should be less than 65kb as this is a hello world app with an unrealistically small number of extra dependencies / code

Screenshots

System information

    "next": "^6.0.3",
    "react": "^16.4.0",
    "react-dom": "^16.4.0",

Thanks!

[realalexhomer]

Wanted to add that i just used npx create-next-app --example hello-world with the same result, so its not related to the custom server or any of the packages in the typescript example

[NathanielHill]

Sounds like it's not a production bundle, you're seeing the size of HMR, sourcemaps, etc... My main.js goes from 1.2MB -> 305kB.

[realalexhomer]

Hmm thanks glad to hear that. So i guess my question would be how can i avoid getting that stuff in my build? I would have thought next build and next start would not include sourcemaps and HMR?

FWIW I set my env variables to NODE_ENV=production and still got the 185kb bundle

[NathanielHill]

I suspect you are not doing this properly in server.js:

const next = require('next')
const dev = process.env.NODE_ENV !== 'production'
const app = next({ dir: '.', dev })

https://github.com/zeit/next.js/blob/a411b3550887e12145ea07bbcca60b170ca243fd/server/index.js#L30

[rashidul0405]

it's "65kb gzziped". You need to enable compression on express server (or proxy server like nginx).

[timneutkens]

So to clear this up. Next.js's server doesn't implement gzip, as a reverse proxy like nginx is usually better suited to handle gzip/brotli. As you can see here: https://hello-world-jfzvyxevhz.zeit.sh/ with brotli/gzip enabled by default on our now.sh hosting platform. the commons bundle is 62.3KB, the pages are 4.5KB and 1.6KB.

This is done without any modifications:

1. yarn create next-app --example hello-world hello-world-app
2. cd hello-world-app
3. now

Also to clear up confusion between the commands:

• next or next dev - dev server
• next build - build for production
• next start - start for production

When using a custom server the dev flag acts as a switch between development and production server.

[timneutkens]

Fun fact, the faq item mentioning a 65kb bundle size was added here: https://github.com/zeit/next.js/pull/444 at the beginning of the project, and hasn't been updated since.

[codinronan]

Chiming in, for me a fresh install of next with only one line in a single page comes to 185kb uncompressed main bundle, compressing down to 61kb on L6 compression (default level for the compression() module).

Said bundle will take ~200ms to unzip, parse and execute on a low-end phone (~5 years old), at a cost of ~1.2 seconds to download for a total cost of 1.4 seconds. On desktop on an average connection the entirety of download, parse, execute will be <200ms.

FYI.

[NathanielHill]

@codinronan Wow, you're even more conservative than me if you use 50kb/s dialup as your mobile speed assumption! :rofl:

[codinronan]

@NathanielHill hehe, that's for 2nd- and 3rd world connection speeds, which for one of my clients is relevant, for another it is not. Even still, for the US company, we aim for <200kb (minzipped) of JS to be delivered in the first page load. The main.js bundle blows up really, really fast.

Inside the US you can assume ~5mbps which gets you pretty good times on a mid-level, ~2 year old phone.

I'm starting a new project that WILL be aimed at people outside the US so I am cognizant that most of them are on much slower connections and am aiming at < 130kb initial JS. Still, Next is very competitive in the size of its initial bundle.

[NathanielHill]

I'm also in a "2nd" world market, so well aware of the issues. 90%+ is strictly mobile, Luckily internet and mobile infrastructure is quite advanced here for the region, and we recently got a Cloudflare PoP :+1:

I find latency to be the biggest killer for such connections and so reducing total network requests required for first paint is also critical. HTTP/2 will help, but you're also running into limitations of TCP design at this level. Interesting reading: https://tylercipriani.com/blog/2016/09/25/the-14kb-in-the-tcp-initial-window/

Zeit is pretty good for small bundle sizes :tada:

[piyushchauhan2011]

I also tried the production build with compression express middleware. These are the results I got with the latest next.js version

[NathanielHill]

@piyushchauhan2011 If you're using react and react-dom, you're looking at about ~35kb baseline. So those results aren't that surprising. If you're not using any weird edge-cases in the React API, consider preact to reduce bundle size.

https://bundlephobia.com/[email protected]