Speed Index 速度指数并不是 Webpack 5 新增的测量接口，而是 Lighthouse 这类性能审计工具中用来判断视觉加载速度的核心指标。如果构建工具产出的资源体积过大、执行时机过早，或者渲染阻塞样式迟迟没有送达，Speed Index 就会明显恶化。Webpack 5 的改动恰好围绕这些环节展开：更有效的缓存降低重复构建成本，更强的 Tree Shaking 减少无用代码，更灵活的分包策略让首屏脚本缩小，模块联邦则帮助多应用复用依赖而避免重复加载。把这些特性组合起来，Speed Index 可以获得稳定的下降。
理解 Speed Index 与资源加载的关系
Speed Index 反映的是视口区域被实际渲染内容填充的速度，而不是某个单一时间点。它的计算会采集页面加载过程中的多个帧，对比每一帧与最终画面之间的差异，因此首屏内容出现得越早、越完整，Speed Index 就越低。影响它的关键因素通常包括渲染阻塞的 CSS、体积过大的首屏 JavaScript、未按需拆分的代码以及图片字体等静态资源的加载时机。
在 Webpack 的构建体系里，这些问题都可以通过配置策略进行干预。例如 CSS 文件是否被单独提取、首屏脚本是否被拆成多个小块、第三方依赖是否被重复打包、无用导出是否被清除，这些都会改变浏览器接收资源的先后顺序和执行成本。Webpack 5 没有新增一个叫做 Speed Index 的插件，但它强化了底层打包能力，使得从构建产物到视觉渲染之间的链路更短、更轻。
还有一个容易被忽略的环节是构建速度本身。Speed Index 是运行时指标，与构建速度没有直接关系，但持久化缓存让开发者可以更频繁、更低成本地发布优化后的产物，从而更快验证线上指标。因此评估 Webpack 5 对 Speed Index 的影响时，需要同时关注产物优化和构建工程效率两个层面。
Webpack 5 中影响 Speed Index 的核心特性
持久化缓存是 Webpack 5 最直接的工程效率提升。通过把模块构建结果写入磁盘缓存，二次构建可以跳过大量重复的编译和压缩工作。配置方法并不复杂，使用 filesystem 缓存并将配置文件纳入依赖即可。下面是一个基础示例：
module.exports = {
mode: 'production',
cache: {
type: 'filesystem',
buildDependencies: {
config: [__filename],
},
},
optimization: {
splitChunks: {
chunks: 'all',
minSize: 20000,
maxSize: 40000,
cacheGroups: {
vendor: {
test: /[\\/]node_modules[\\/]/,
name: 'vendors',
priority: 10,
},
},
},
runtimeChunk: 'single',
},
};
这个配置虽然表面上只影响构建速度，但它带来的低反馈成本让团队敢于做更细的拆分和优化实验。更关键的是 splitChunks 的 maxSize 和 runtimeChunk 配置，它们直接作用于运行时产物。把 runtime 代码单独拆出，可以避免修改业务代码后 vendor 文件的 hash 变化，提升长期缓存命中率，用户在二次访问时不需要重新下载已经缓存的脚本，视觉呈现也会更快。
Tree Shaking 的改进同样重要。Webpack 5 对 ES modules 的分析更加准确，可以移除更多未引用导出。尤其是配合 sideEffects 字段，构建器能跳过没有副作用的模块，从而压缩首屏脚本体积。当脚本体积下降后，网络传输、解析和执行时间都会缩短，Speed Index 自然随之改善。模块联邦则是另一个方向：如果多个应用共享同一个依赖，可以通过模块联邦在运行时复用，而不是每个应用都打包一份。
动态导入是降低首屏资源竞争的主要手段。将非首屏功能拆成异步 chunk，让浏览器先处理关键渲染路径，是 Speed Index 优化中最容易见效的方法。结合 Webpack 5 的 chunkIds 确定性输出，异步 chunk 的文件名稳定可缓存，对长期性能也有帮助。
从配置细节降低 Speed Index 的实践
仅仅依靠默认配置往往难以获得理想的 Speed Index，需要围绕首屏资源做进一步约束。第一步是控制 JavaScript 的执行时机。把非关键脚本通过动态导入延后到用户交互或空闲时加载，可以显著减少首屏主线程阻塞。一个常见写法如下：
document.querySelector('#chart').addEventListener('click', () => {
import('./heavy-chart').then(({ renderChart }) => renderChart());
});
这个例子中，heavy-chart 模块只有在点击时才被请求，不会参与首屏资源竞赛。为了让首屏样式更快送达，应该将关键 CSS 单独提取并尽早注入，而非用 JavaScript 动态插入样式。在 Webpack 5 中可以使用 MiniCssExtractPlugin 把 CSS 从 JS 中分离，再配合 html-webpack-plugin 将 CSS 文件以 <link> 标签形式插入文档头部。注意这个 <link> 是渲染阻塞资源，但合理的首屏样式必须尽早出现，否则页面虽然脚本很快，视觉内容却迟迟不能填充，Speed Index 反而会变差。
静态资源类型处理也被 Webpack 5 简化了。asset modules 可以替代 file-loader 和 url-loader，并对小图片自动转成 base64 内联，减少请求数量，同时避免大图内联导致脚本膨胀。图片是视觉内容的一部分，加载过快或过慢都会直接影响 Speed Index 的帧对比结果。建议对首屏关键图片使用响应式格式，对非首屏图片使用原生 lazy loading，让视口区域更快获得有效像素。
压缩工具链同样值得调整。TerserPlugin 默认会提取注释，这些注释文件如果没有被正确加载，可能产生额外请求。配置 extractComments 为 false 可以减少产物中的噪声文件。下面的配置展示了如何关闭注释提取并启用并行压缩：
const TerserPlugin = require('terser-webpack-plugin');
module.exports = {
optimization: {
minimize: true,
minimizer: [
new TerserPlugin({
parallel: true,
extractComments: false,
}),
],
},
};
压缩后的脚本体积减小，解析速度变快，主线程的空闲时间增加，浏览器就有更多资源进行布局和绘制。对 Speed Index 而言，这比单纯追求构建速度更直接。
用 Lighthouse 验证 Speed Index 改善效果
完成配置调整后，需要用可靠的工具量化变化。Lighthouse 的 performance 类别会输出 Speed Index 数值，但它受测试环境、网络波动和页面运行状态影响较大。为了保证数据可比，应该在相同条件下多次测试，例如使用固定 CPU 降速和网络节流配置。命令行方式如下：
npx lighthouse https://ipipp.com --only-categories=performance --output html --output-path ./report.html
测试时要注意页面是否包含动态内容、广告或第三方脚本，这些都可能引入不可控的渲染延迟。如果 Speed Index 仍然偏高，可以回到浏览器开发者工具的性能面板，观察主线程在首屏阶段被哪些长任务占据，再判断是继续拆分代码、减少阻塞样式还是优化图片加载。优化过程不是一次性完成，而是不断测量、调整和验证的循环。
需要澄清的是，Speed Index 虽然重要，但它不能替代其他核心指标。举例来说，如果页面首屏内容通过大量异步加载逐步填充，Speed Index 可能较低，但 Largest Contentful Paint 却可能偏晚。Webpack 5 的优化策略应当服务于完整的性能目标，而不是孤立地压低某一项数值。把持久化缓存、Tree Shaking、动态导入和资源处理组合起来，才能在真实用户环境中获得稳定的视觉速度提升。
从工程角度看，Webpack 5 的价值不在于新增了某个名为 Speed Index 的魔法配置，而在于它让开发者可以用更清晰的产物结构影响浏览器的渲染节奏。当首屏脚本足够小、样式足够早、图片足够轻时，Speed Index 会随着关键渲染路径的缩短而自然下降。
Webpack 5Speed Index构建性能修改时间：2026-09-28 16:23:49