此页面由 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 的默认设置适用于大多数用户。系统会根据多个条件创建多个拆分区块，以防止跨多个路由提取重复的代码。

不过，许多使用此插件的 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

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

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

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

使用精细数据块缩减大小

许多框架（包括 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

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，了解他们如何在其 webpack 配置中实现此逻辑，v2.20.7 中默认提供该逻辑。

总结

分发精细分块的概念并非仅适用于 Next.js、Gatsby 或 webpack。无论使用哪种框架或模块捆绑工具，如果应用采用大型“公共”软件包方法，所有开发者都应考虑改进应用的分块策略。

如果您想了解将相同的分块优化应用于纯 React 应用的情况，请查看此 React 示例应用。该应用使用了精细分块策略的简化版本，可帮助您开始将相同的逻辑应用于您的网站。
对于汇总，默认情况下，系统会精细地创建分块。如果您想手动配置此行为，请参阅 manualChunks。

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

简介

改进的分块

更多 HTTP 请求

使用精细数据块缩减大小

Gatsby

总结