ES module preload 减少首屏依赖等待的方法

如果首屏模块的网络瀑布图表现为“先下载 main.js，再发现 chart.js，最后才发现 format.js”，可以把真正属于首屏路径的模块用 提前声明。浏览器会更早获取模块，并把解析、编译结果放入当前文档的模块映射中，减少依赖发现带来的等待。

它不是把所有 JavaScript 都提前加载的开关。选错模块会抢占 CSS、字体或图片的网络资源；URL、凭据模式不一致时，还可能出现重复请求。下面按“触发信号—快速判断—处理—回滚—复查”的运行手册方式，只讨论 link rel、依赖图与缓存。

先判断：等待是依赖发现，还是缓存没有命中

先画出首屏入口模块的静态依赖图：页面加载 main.js，它再静态导入 chart.js 和 format.js。如果依赖请求总要等入口模块下载并解析后才出现，问题是发现链条偏晚；如果请求很早就开始但资源重复下载，重点则是 URL、凭据或缓存匹配。

只把用户进入页面后立刻需要的模块纳入候选。路由切换、弹窗、报表导出等异步功能不应因为“可能会用到”而挤占首屏带宽。

在入口脚本前声明首屏模块

HTML 中把首屏关键模块写在入口脚本之前。modulepreload 专门面向 JavaScript 模块，不需要像普通 preload 那样额外写 as="script"。

这里的关键不是标签数量，而是依赖图的选择：入口与首屏同步依赖可以并行开始，异步路由的模块继续由真正的导航或交互触发。浏览器也可能自动处理部分依赖，但需要稳定覆盖时，应对确实关键的依赖逐个声明。

避免“预加载成功但模块又请求一次”

重点检查同一个模块的地址是否完全一致。/assets/main.js、带不同查询串的地址、不同 CDN 域名或不同重写规则，都可能让提前取得的资源不能被后续模块请求复用。

跨源模块还要把凭据语义对齐。modulepreload 的请求使用 CORS 模式；默认的匿名跨源方式与同源凭据模式，和 crossorigin="use-credentials" 并不是一回事。只有服务端允许并且模块请求确实需要凭据时，才使用带凭据的方式。

示例中的域名只是占位写法，实际项目应替换为自己的资源地址，并让 CDN 的 CORS 响应、缓存键和脚本请求保持一致。不要为了文章示例把它当作可直接访问的站点地址。

回滚路径：预加载让首屏变慢时怎么办

如果加入提示后首屏的关键 CSS、字体或图片反而更晚，先删掉非必要的依赖声明，只保留入口模块，随后再按首屏真实路径逐个加入。不要把回滚理解成删除 script type="module"；回滚的对象是过宽的预加载集合。

也要检查响应缓存：资源内容变化时使用带内容指纹的文件名或稳定的发布缓存策略，避免 HTML 指向新入口而缓存仍保留旧依赖。模块预加载解决的是“何时开始准备”，不能替代合理的拆包、压缩和缓存更新。

速查：适合加 modulepreload 的信号

常见问题

modulepreload 和 preload 有什么区别？

preload 更像是提前获取并放入预加载缓存；modulepreload 了解目标是模块，还会准备模块映射，因此更适合模块入口和关键依赖。

是否只写入口模块就够了？

入口模块是最小起点，但它的静态依赖是否被自动提前获取属于浏览器优化行为。需要稳定缩短关键依赖等待时，把确定属于首屏的依赖也显式列出，同时控制数量。

本文的技术依据可从 MDN 的 rel="modulepreload"、JavaScript Modules 和 HTML 标准对应章节继续阅读。