Update to Next.js 16.2 and React 19.2#8367
Conversation
|
Hi @lukesandberg! Thank you for your pull request and welcome to our community. Action RequiredIn order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you. ProcessIn order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA. Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks! |
Size changesDetails📦 Next.js Bundle Analysis for react-devThis analysis was generated by the Next.js Bundle Analysis action. 🤖
|
| Page | Size (compressed) |
|---|---|
global |
122.77 KB (🟢 7.63 KB) |
Details
The global bundle is the javascript bundle that loads alongside every page. It is in its own category because its impact is much higher - an increase to its size means that every page on your website loads slower, and a decrease means every page loads faster.
Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis
If you want further insight into what is behind the changes, give @next/bundle-analyzer a try!
Seven Pages Changed Size
The following pages changed size from the code in this PR compared to its base branch:
| Page | Size (compressed) | First Load |
|---|---|---|
/404 |
139.4 KB (🟢 12.38 KB) |
262.17 KB |
/500 |
139.41 KB (🟢 12.39 KB) |
262.18 KB |
/[[...markdownPath]] |
141.66 KB (🟢 12.2 KB) |
264.43 KB |
/_error |
12.22 KB (🟢 12.04 KB) |
134.99 KB |
/errors |
139.6 KB (🟢 12.33 KB) |
262.37 KB |
/errors/[errorCode] |
139.59 KB (🟢 12.34 KB) |
262.36 KB |
/llms.txt |
10.51 KB (🟢 10.26 KB) |
133.28 KB |
Details
Only the gzipped size is provided here based on an expert tip.
First Load is the size of the global bundle plus the bundle for the individual page. If a user were to show up to your website and land on a given page, the first load size represents the amount of javascript that user would need to download. If next/link is used, subsequent page loads would only need to download that page's bundle (the number in the "Size" column), since the global bundle has already been downloaded.
Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis
Next to the size is how much the size has increased or decreased compared with the base branch of this PR. If this percentage has increased by undefined% or more, there will be a red status indicator applied, indicating that special attention should be given to this.
|
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks! |
|
Thank you for doing this! Looking at this MR and #8338 can be a great comparison of app router vs. pages router in terms of performance for content sites that do not have manual lazy-loading content components (i.e., all the custom markdown components). Doing the same performance I did with app router. Doing some quick performance testing on the useActionState page (this pr build on my machine vs react.dev) There appears to be no performance downgrade in LCP or INP (good news). I am still seeing some extra JS being downloaded in this MR vs. prod (2.3 MB on local vs. 1.9 MB in prod). With about 980 KB being used on both sites. Looking at both migrations to turbopack MRs, there appear to be some issues with tree shaking/bundling deoptimization compared to Webpack or next.js 16 requries more JS than next.js 15. I am concerned that I am missing something. localhost JS coverage report from Chrome Production JS coverage report from Chrome |
Summary
.eslintrcto flat config (eslint.config.mjs) for ESLint 9/api/md/[...path]route by restructuring file reads to be statically analyzable, should reduce deployment sizewith { type: "text" }imports instead of the webpack raw-loadercaughtErrorsIgnorePatternto eslint configreact-hooks/set-state-in-effectandreact-hooks/refsrules to warnings (pre-existing patterns)Bundle Analysis
To check actual deltas i fetched a few pages across each version
//reference/react/useState/404/llms.txtThe bundle analysis CI action will report a ~12KB/page regression, but this is a measurement artifact: Turbopack populates
build-manifest.jsondifferently than webpack, placing shared framework chunks in per-route entries rather than in/_app. The action subtracts/_appchunks as the shared baseline, so these misattributed chunks get counted as page-specific JS. Actual browser-downloaded JS decreased ~7%.Going forward the per-PRs deltas will be accurate, but for this PR they are not.
Test plan
yarn tscpassesyarn lintpasses (0 errors)yarn buildsucceeds with no warnings🤖 Generated with Claude Code