不迁移 Next.js，也能把 React 包体积砍掉数倍

译注：本文编译自 dev.to 文章《Cut React bundle size 3x — No Next.js migration required》，作者 nainikmehta，原文发布于 2026 年 9 月 17 日。原文链接见文末。文章观点仅代表作者，编译时对营销性表述做了克制处理。

很多团队一遇到性能问题，第一反应就是迁移到 Next.js。但作者提出一个更务实的观点：如果你的痛点只是客户端包体积过大，未必需要动辄数周的框架迁移。在 Vite/Rollup 上花一个下午做五处针对性调整，往往就能把主包缩小 2 到 5 倍。这些手段风险低、可直接上生产，已被不少团队验证过。

为什么值得关注

过大的首屏包会拖慢可交互时间（TTI），在移动端直接影响转化率。Next.js 提供了便利的自动优化，但它并不是缩小客户端负载的唯一路径。如果目标只是减小 React 包体积，正确顺序是先测量，再做针对性修复。

一、用动态导入隔离重型库

如果某个依赖体积很大，却只服务于单一功能（PDF 导出、富文本、Monaco 编辑器），就把它推到懒加载边界之后，只在需要时下载。Vite/Rollup 会为 import() 调用单独产出一个 chunk。

jsx

import { lazy, Suspense } from 'react';

const PDFViewer = lazy(() => import('@react-pdf/renderer'));

export default function Report() {
  return (
    <div>
      <h1>Report</h1>
      <Suspense fallback={<div>Loading PDF viewer…</div>}>
        <PDFViewer />
      </Suspense>
    </div>
  );
}

几条经验规则：

确认该库没有在其他地方被顶层直接 import——只要有一处急切导入，它就会被拉回主包。
在路由或用户操作边界（点击、打开、聚焦）做懒加载，以匹配真实意图。
如果首次加载后需要反复同步使用，可以缓存该模块。

二、替换高开销依赖（lodash、moment）

有些库本身就重，或者发布的是无法 tree-shaking 的构建产物。两个快速见效的替换：

用 lodash-es 的具名导入或原生方案替代 lodash（barrel/commonjs 形式）。
用 dayjs 或 date-fns 替代 moment（在可用环境下也可使用原生 Temporal API）。

每次替换通常能省下约 15–25 KB（gzip 后）甚至更多。引入任何新依赖前，先查 Bundlephobia，并用可视化工具确认 tree-shaking 后的 gzip 影响。

三、保守的 tree-shaking 与 .server.ts 分离

Vite/Rollup 的 tree-shaking 在代码以 ESM 编写、且包正确声明 sideEffects 时效果最好。两个实操步骤：

在 vite.config.ts 中设置 moduleSideEffects，或确保依赖库的 package.json 里有 "sideEffects": false，让 Rollup 能丢弃仅用于初始化的代码：

typescript

// vite.config.ts (excerpt)
export default defineConfig({
  build: {
    rollupOptions: {
      treeshake: true,
    },
    moduleSideEffects: false,
  },
});

把仅服务端的辅助函数移到以 .server.ts 结尾的文件中（或以其他方式确保它们不被客户端入口导入）。这是一个极小的结构性改动，但当某个共享文件拖入仅服务端依赖时，它能省下数 MB。

例如：把 token 计数或文件系统辅助函数从 shared.ts 移到 shared.server.ts，客户端包就不再包含 tokenizer WASM 或其他仅服务端代码。

四、Vendor 拆分与 manualChunks

通过把第三方库拆成逻辑分组，控制哪些内容留在初始负载中。Rollup/Vite 的 manualChunks 让你能精细控制缓存与首屏下载。

typescript

build: {
  rollupOptions: {
    output: {
      manualChunks(id) {
        if (id.includes('node_modules')) {
          if (id.includes('react')) return 'vendor-react';
          if (id.includes('echarts') || id.includes('chart.js')) return 'vendor-charts';
          if (id.includes('@react-pdf') || id.includes('pdfjs-dist')) return 'vendor-pdf';
          return 'vendor-others';
        }
      }
    }
  }
}

为什么有效：很少变化的 vendor chunk 会长期留在缓存里。你的业务代码每周更新，也不会让用户已经缓存的 200–400 KB React/图表/PDF vendor 文件失效。

注意事项：

不要过度拆分 React 内部——把 React 和与它紧耦合的库放进不同 chunk，可能引发微妙的运行时/水合问题。React 和 ReactDOM 应放在一起。
避免产生大量碎片化小 chunk；每个 chunk 的 gzip 体积控制在约 50–500 KB 较为理想。

五、重新评估重型状态库

Redux 和 RTK 对很多应用来说很好用，但确实有体积成本。对许多单页应用而言，Zustand、jotai 或针对性的 atom/Context 模式能减小包体积，并改善低端设备上的 TTI。

一个务实的做法：

先拿单个领域（表单状态、局部 UI 状态）原型迁移到 Zustand，测量体积与运行时开销。
同时考虑服务端同步与开发工具需求——RTK 的 devtools 与中间件很方便，有时值得这份取舍。

不少团队发现，换成更小的状态库，或采用混合方案（局部 UI 用 Zustand，共享 API 缓存用 RTK），能立刻获得负载收益。

测量、安全与部署

始终先测量。见效最快的路径是：

运行包可视化工具（rollup-plugin-visualizer、vite-bundle-visualizer）。
按 gzip 体积找出最大的三个切片。
只做一处改动（例如懒加载某个重型库）并重新构建。
核对 chunk 图与 gzip 体积变化。

在 CI 中加入体积预算（size-limit、bundlesize），让后续改动能被尽早发现。

什么时候仍该考虑 Next.js

如果你需要服务端渲染、Server Components，或内置流式渲染，并且正在构建一个大型内容站点、SSR 能带来 SEO 与首字节收益，那么 Next.js 仍是可靠选择。本文的重点是：如果你的唯一阻碍只是包体积，那么上面这五个纯 React 手段成本更低、风险更小，也能带来同样的主包收益。

结语——小改动，大收益

框架迁移是一笔大投入。到了 2026 年，借助现代打包器、谨慎的 tree-shaking、manualChunks 与运行时懒加载，你往往无需 Next.js 就能减小 React 包体积，有时效果还相当显著。从测量开始，应用这五处针对性修复，把迁移留给真正需要它的问题。

你会先在应用里尝试哪一条？

原文链接

https://dev.to/nainikmehta/cut-react-bundle-size-3x-no-nextjs-migration-required-58gk

不迁移 Next.js，也能把 React 包体积砍掉数倍 ​

为什么值得关注 ​

一、用动态导入隔离重型库 ​

二、替换高开销依赖（lodash、moment） ​

三、保守的 tree-shaking 与 .server.ts 分离 ​

四、Vendor 拆分与 manualChunks ​

五、重新评估重型状态库 ​

测量、安全与部署 ​

什么时候仍该考虑 Next.js ​

结语——小改动，大收益 ​

原文链接 ​