通过mock某些不需要在server导入的依赖，优化 next.js dev/build 性能。

pnpm i ssr-optimize -D
# or
npm i ssr-optimize -D
# or
yarn add ssr-optimize -D
# or
bun add ssr-optimize -D

// next.config.mjs
const { withSSROptimize } = require("ssr-optimize");

/** @type {import('next').NextConfig} */
const nextConfig = {};

module.exports = withSSROptimize({
  deps: {
    // 添加想要 mock 的依赖
    // key 会设置为 webpack.resolve.alias 的 key
    // value 是 mock 实现的路径，true 则使用默认的 mock 实现，见 `src/mock.js`
    // eg:
    ethers: true,
    "@web3modal/ethers$": true,
    "@web3modal/ethers/react": true,
  },
})(nextConfig);

举个例子：

在某个页面需要调用依赖a，但是a不会在server中运行，运行a可能是在onClick中，或者某些强依赖browser的环境中。

那么此时对于server bundle来说，导入a就是多余的。

如果a的代码量非常大、模块数量非常多或者有很多a独有的依赖。势必会降低server 构建的性能以及可能的 server 运行的性能。

详见 example/next-js。

在这个例子中，我们使用了 @web3modal/ethers 和 ethers，但是这两个依赖并不会在服务端运行，他们依赖的browser。

所以我们可以尝试mock这两个依赖的导出，使得业务代码不用做任何更改，同时优化server端的性能。

通过指定webpack.resolve.alias来 mock 依赖。

例如：

在 server 构建时候，webpack 解析到如下代码：

import { createWeb3Modal } from "@web3modal/ethers/react"时。

通过 webpack.resolve.alias 指定 @web3modal/ethers/react 为 src/mock.js， 使其真正参与编译的时候被替换为 src/mock.js的实现。

详见 src/mock.js

这里给出部分对比数据，感兴趣可以运行 example/next-js 查看。

module count

• 常规
• 优化

访问同一页面next构建的module数量有所下降，即在server端没有去构建@web3modal/ethers和ethers。

memory usage

冷启动后

• 常规
• 优化

热更新多次后

• 常规
• 优化

通过运行 node --heap-prof ./node_modules/next/dist/bin/next build 生成的 heapprofile 获取的内存数据

memory usage

• 常规
• 优化

bundle-analyzer

• 常规
• 优化

总结 从以上对比数据来看，mock掉在server中用不上的依赖确实能带来有效的性能提升。