How much of my Next.js article pages' JavaScript is my own code?
After the Next.js team's 28 October post on shipping less JavaScript, I tried the bundle analyser myself, without the AI agent. Here's what it showed for my article pages and home page, and where its numbers disagree.
On an article page of my Next.js site, about 81 percent of the JavaScript that loads up front is Next.js itself, and about 3 percent is code I wrote. That comes from the bundle analyser built into Next.js, a tool that lists what goes into each page's JavaScript, the code that runs in a visitor's browser. I ran it on 5 November 2026. It gives estimates, and it listed one block of code twice on my home page, so I've marked where the numbers stop.
What the Next.js team published on 28 October
On 28 October 2026 the Next.js team published "Ship less JavaScript in Next.js with your AI agent". Next.js 16.4 adds an agent skill, a packaged set of instructions an AI coding assistant can follow to investigate and reduce a site's JavaScript. Vercel, the company behind Next.js, says its agents found and cut nearly two megabytes of compressed JavaScript (shrunk for sending over the network) across v0 and vercel.com.
The post also covers the bundle analyser. It has been part of Turbopack since Next.js 16.1, and Turbopack is the bundler, the tool that packs a site's code into bundles, the files a browser downloads. The analyser now opens on a summary of the largest routes, which are a site's pages and page types. It adds a table you can sort by size, saved snapshots to compare, and a filter that keeps only the code needed for the first render.
I haven't run the agent skill, so I've nothing to report about it. The post's tables are labelled illustrative, and its savings come from Vercel's agent working on v0 and vercel.com. I ran the analyser myself, and what follows is one real, small site's split and nothing more.
What I ran, and what the tool printed
On 5 November 2026 I ran `npx next analyze --output --snapshot rfd-2026-11-05` on Next.js 16.4.5, using Turbopack. It took 7.2 seconds and covered 42 routes, 41 of them with JavaScript for the browser. The tool's log says it analyses a production build, and it made one inside a copy of my site's code. Nothing was built or deployed in my real project. I've only got one snapshot, a saved copy of the analysis, so there's no before and after in this article.
Two things about the figures. The tool sizes each module, meaning each small piece of code, as a compressed estimate, and neither the command-line documentation I read nor the tool's output names the method. And the way I ran it, it didn't print an initial-load number, because that filter lives in the interactive view, which I didn't open. So I made my own initial JavaScript figure. A chunk is one output file, and the tool sorts chunks into groups. I added up the chunks in the two groups it calls bootstrap and render-dependent, which I treated as what a page needs to start. The initial figure is my sum, not the tool's.
Where an article page's JavaScript comes from
I started with the route my Insights articles use. These figures are from the 5 November 2026 run.
One file sits outside the groups. It's a polyfill (a compatibility script for older browsers) called nomodule, 39,434 bytes, and the tool counts it in the total for each of the 41 routes with browser JavaScript. I've left it out of the figures below.
- Initial JavaScript on an article page: 219,026 bytes, my sum.
- The `next` package: 178,160 bytes, 81.3 percent. React DOM, the part of React that draws the page in the browser, is inside it at 63,936 bytes on its own. The tool lists the copies of React that ship inside Next.js under `next`. The rest is Next.js's own client code, including its router, which moves between pages.
- Code I wrote, in the site's `src` folder: 6,996 bytes, 3.2 percent. The navigation bar is the largest piece at 2,470 bytes, then the main call-to-action button at 972 and the share button at 886.
- Packages listed in my site's package.json: 16,195 bytes, 7.4 percent. The largest, in order, are tailwind-merge, a helper that combines CSS class names, at 6,514, and Radix UI's slot package at 2,616. Radix UI is a set of building blocks for dialogs and accordions. Then come lucide-react, an icon set, at 2,296 and Radix UI's dialog package at 1,782.
- Packages those pull in, which aren't in my package.json: 13,128 bytes, 6.0 percent. The largest is react-remove-scroll at 2,577.
- The bundler's own runtime: 4,547 bytes, 2.1 percent.
The home page carries a library bigger than React
The home page splits differently. Its largest single source is three.js, a library for drawing 3D graphics in a browser, at 117,433 bytes, against 63,936 for React DOM. It's in my package.json. The tool puts all of it in an async chunk, a file the page requests after it starts rather than up front. The request comes from the hero, the large opening section, which loads it with `next/dynamic`, Next.js's way of loading a component later. The files under my `src` folder come to 22,688 bytes on the home page, 19,173 of them up front and 3,515 in the hero's later-loading file.
Here the tool disagrees with itself. On the home page and 21 other routes it lists all 59 modules of one chunk twice, with identical paths and sizes, which adds 32,061 bytes to each. I can't tell from the export whether that's a display fault or real. The tool's own totals include the doubled bytes. The article pages aren't affected.
I've worked out the home page both ways, with each share taken from its own total. If it's real, the initial JavaScript is 260,628 bytes: the `next` package is 180,949 of that, 69.4 percent, and my own code 19,173, 7.4 percent. If it's a fault, the repeated chunk counts once and the total is 228,567 bytes: the `next` package is 180,887, 79.1 percent, and my own code 14,208, 6.2 percent.
The second mismatch is with my own earlier measurement. In Astro or Next.js for a business website I reported about 199 KiB (a kibibyte is 1,024 bytes) of JavaScript downloaded on mobile for this site, the median of three PageSpeed Insights runs on 5 November 2026. That's a measured download. The analyser's home page figures convert to about 223 and 255 KiB, and they're estimates, so I can't set them beside the 199. I haven't reconciled them, and I'm not saying either one confirms the other.
What I take from the split
What follows is my reading of the numbers, not something the tool says. In that earlier article I wrote that I hadn't split the Next.js site's 200 KiB into what's React and what's my own code. This is a partial answer: it splits the analyser's estimate for an article page, not the PageSpeed figure.
On an article page the framework supplies about four-fifths of the up-front JavaScript, and I supply about 3 percent. If I halved my own 6,996 bytes, the page would lose about 1.6 percent of its initial JavaScript. So on a page like this, my own code is the smallest place to look for savings.
The next place is what I've added to the project. That's the 16,195 bytes of packages in my package.json on an article page, and on the home page three.js, which outweighs React DOM. The framework is bigger still, but I chose it once, at the start, and the earlier article covers that choice.
What this doesn't show
The analyser shows what goes into the bundle, not what a visitor experiences. Here's what I haven't measured.
- Real compressed size. I haven't measured gzip or brotli (two common compression methods) as my host serves the files.
- Whether three.js loads on a real phone, or when. The tool calls it async, and I haven't opened the site in a browser to check.
- Scripts outside the bundle. Analytics and other scripts added to a page with a `<script>` tag aren't bundled modules, so the tool can't see them. That would explain why no analytics package appears in these numbers.
- How long a phone takes to run this code.
- A cross-check against the build I deploy. The tool made its own production build of the copy, and I haven't compared it with my real project's build.
Where to start
To see your own site's split, run `npx next analyze` on a copy of your code, using Next.js 16.4 or later, the version the post ties snapshots to, and write down for one article page how much of its JavaScript sits under the `next` package and how much in your own code.
Pages worth acting on
What to read next
Astro or Next.js for a business website?
My rule for choosing between Astro and Next.js, and what two of my own sites send on first load, measured with PageSpeed Insights on 25 October and 5 November 2026.
Read articleCustom-coded vs WordPress: a real-world speed comparison
The same local business, the same services, one website replaced by another, both measured with Google PageSpeed Insights on the same day. Not a laboratory test, but the closest the real world gets.
Read articleGoogle's shared AI training control is a 2027 plan, not a setting yet
Google plans to support a shared AI training control in robots.txt and aims for 2027. I explain what its post says and doesn't, using my own robots.txt as the worked example.
Read articleQuestions local business owners usually ask next
Want me to look at your site?
The Free Website Review looks at the site you've got now and comes back with the clearest next step. It's free, whether or not you hire me.