此页面由 Cloud Translation API 翻译。

通过精细分块提升 Next.js 和 Gatsby 网页加载性能

Next.js 和 Gatsby 采用了较新的 webpack 分块策略，可最大限度地减少重复代码以提高网页加载性能。

Houssein Djirdeh

Chrome 与 JavaScript 开源生态系统中的工具和框架进行了协作。最近添加了许多较新的优化，以提高 Next.js 和 Gatsby 的加载性能。本文介绍了两种框架中默认提供的改进后的精细分块策略。

简介

与许多 Web 框架一样，Next.js 和 Gatsby 使用 webpack 作为其核心捆绑器。Webpack v3 引入了 CommonsChunkPlugin，使可以在单个（或少数）“公共”区块（或多个区块）中输出在不同入口点之间共享的模块。共享代码可以单独下载并尽早存储在浏览器缓存中，从而提高加载性能。

在许多单页应用框架（采用如下所示的入口点和软件包配置）中，这种模式很受欢迎：

通用入口点和软件包配置

虽然切实可行，但将所有共享模块代码捆绑到一个分块中的概念具有其局限性。对于不在每个入口点共享的模块，可以为没有使用该模块的路线下载该模块，从而导致下载不必要的代码。例如，当 page1 加载 common 分块时，它会加载 moduleC 的代码，即使 page1 不使用 moduleC 也是如此。因此，除了一些其他插件外，webpack v4 移除了该插件，取而代之的是新插件：SplitChunksPlugin。

改进分块

SplitChunksPlugin的默认设置适用于大多数用户。系统会根据多个conditions创建多个拆分块，以防止跨多个路由提取重复代码。

但是，许多使用此插件的 Web 框架仍然采用“单一公共”方法来拆分数据块。例如，Next.js 将生成一个 commons 软件包，其中包含在超过 50% 的页面和所有框架依赖项（react、react-dom 等）中使用的任意模块。

const splitChunksConfigs = {
  …
  prod: {
    chunks: 'all',
    cacheGroups: {
      default: false,
      vendors: false,
      commons: {
        name: 'commons',
        chunks: 'all',
        minChunks: totalPages > 2 ? totalPages * 0.5 : 2,
      },
      react: {
        name: 'commons',
        chunks: 'all',
        test: /[\\/]node_modules[\\/](react|react-dom|scheduler|use-subscription)[\\/]/,
      },
    },
  },

虽然将依赖于框架的代码添加到共享区块中意味着可以针对任何入口点下载和缓存这些代码，但基于使用情况的启发式算法包含超过半数页面中使用的通用模块，这种方式不太有效。修改该比率只会产生以下两种结果之一：

如果降低该比率，则会下载更多不必要的代码。
如果您提高该比率，则多条路由中的重复代码会增多。

为了解决这个问题，Next.js 对 SplitChunksPlugin 采用了不同的配置，减少了任何路由的不必要代码。

任何足够大的第三方模块（大于 160 KB）都会拆分成单独的分块
系统会为框架依赖项（react、react-dom 等）创建一个单独的 frameworks 数据块
创建任意数量的共享区块（最多 25 个）
要生成的分块的最小大小更改为 20 KB

这种精细的分块策略具有以下优势：

缩短了网页加载时间。发出多个共享区块而不是单个区块，可以最大限度地减少任何入口点的不需要（或重复）代码量。
改进了导航期间的缓存。将大型库和框架依赖项拆分为单独的区块可降低缓存失效的可能性，因为两者在升级之前不太可能更改。

您可以查看 Next.js 在 webpack-config.ts 中采用的完整配置。

使用精细数据块缩减大小

包括 Next.js 在内的许多框架都依靠客户端路由（由 JavaScript 处理）来为每个路由转换注入新的脚本标记。但是，它们如何在构建时预先确定这些动态块呢？

Next.js 使用服务器端 build 清单文件来确定不同入口点使用哪些输出区块。为了也向客户端提供此信息，我们创建了一个删节版客户端 build 清单文件，以映射每个入口点的所有依赖项。

// Returns a promise for the dependencies for a particular route
getDependencies (route) {
  return this.promisedBuildManifest.then(
    man => (man[route] && man[route].map(url => `/_next/${url}`)) || []
  )
}

这种较新的精细分块策略在 Next.js 中首次推出，采用标志后，已在许多尝鲜者中进行了测试。许多开发者发现其整个网站所用的 JavaScript 总量大幅减少：

缩减 JavaScript 大小 - 跨所有路由（压缩后）
网站	JS 总更改量	差异百分比
https://www.barnebys.com/	-238 KB	-23%
https://sumup.com/	-220 KB	-30%
https://www.hashicorp.com/	-11 MB	-71%

最终版本默认在版本 9.2 中提供。

盖茨比

Gatsby 过去的做法与使用基于使用情况的启发法定义通用模块的方法相同：

config.optimization = {
  …
  splitChunks: {
    name: false,
    chunks: `all`,
    cacheGroups: {
      default: false,
      vendors: false,
      commons: {
        name: `commons`,
        chunks: `all`,
        // if a chunk is used more than half the components count,
        // we can assume it's pretty global
        minChunks: componentsCount > 2 ? componentsCount * 0.5 : 2,
      },
      react: {
        name: `commons`,
        chunks: `all`,
        test: /[\\/]node_modules[\\/](react|react-dom|scheduler)[\\/]/,
      },

通过优化其 webpack 配置以采用类似的精细分块策略，他们还在许多大型网站中显著减少了 JavaScript：

缩减 JavaScript 大小 - 跨所有路由（压缩后）
网站	JS 总更改量	差异百分比
https://www.gatsbyjs.org/	-680 KB	-22%
https://www.thirdandgrove.com/	-390 KB	-25%
https://ghost.org/	-1.1 MB	-35%
https://reactjs.org/	-80 KB	-8%

查看 PR，了解他们如何将此逻辑实现到 v2.20.7 中默认提供的 webpack 配置中。

总结

提供精细数据块的概念并非特定于 Next.js、Gatsby，甚至是 webpack。无论使用何种框架或模块打包器，如果应用遵循大型“通用”软件包方法，则每个人都应该考虑改进其应用的分块策略。

如果您希望查看在原版 React 应用中应用相同的分块优化，请参阅此 React 应用示例。该应用使用简化版本的精细分块策略，可帮助您开始对网站应用同种逻辑。
对于 Rollup，系统默认创建区块。如果您想手动配置行为，请查看 manualChunks。

通过精细分块提升 Next.js 和 Gatsby 网页加载性能

简介

改进分块

更多 HTTP 请求

使用精细数据块缩减大小

盖茨比

总结