此页面由 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，即可单个（或几个）“公共”中不同入口点之间共享的输出模块数据块（或数据块）。共享代码可以单独下载，并尽早存储在浏览器缓存中，从而提升加载性能

许多单页应用框架采用入口点和 bundle 配置，如下所示：

通用入口点和软件包配置

将所有共享模块代码捆绑到单个块的概念虽然可行，但限制。对于没有在每个入口点共享的模块，可以为不使用它的路由下载这会导致不必要的代码下载。例如，当 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 清单文件，以映射每个入口点的所有依赖项。

// 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%

查看公共关系，了解他们是如何已在他们的 webpack 配置中实现此逻辑，v2.20.7 中默认提供该配置。

总结

分发颗粒块的概念并非特定于 Next.js、Gatsby 甚至 webpack。所有人如果应用遵循大量“公共”政策，则应考虑改进其应用的分块策略 bundle 方法，无论使用的是框架还是模块打包器。

如果您想看到原版 React 应用同样采用相同的分块优化，请参阅这个示例 React app。它使用简化版精细分块策略，并且可以帮助您开始应用相同的逻辑等
对于 Rollup，系统会默认精细地创建分块。请查看 manualChunks（如果您要手动配置行为

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

简介

改进的分块

更多 HTTP 请求

使用精细数据块缩减大小

盖茨比

总结