为什么你的网页越来越慢？可能是 JS 一次加载得太多了

很多团队在排查页面性能问题时，第一反应是“网络是不是变慢了”“服务器是不是扛不住了”。但在大量真实场景中，首屏卡顿的根因其实很朴素：页面一打开，就把所有可能用到的 JavaScript 全部下载并执行了一遍。

一个典型的例子是富文本编辑器。只有当用户点击“开始编辑”时，才真正需要这套复杂的编辑器逻辑；而它的代码体积动辄几百 KB，甚至达到数 MB。如果页面初始加载阶段就把这份脚本一并拉下来，用户实际上为“可能永远不会触发的功能”付出了下载、解析和执行的完整成本。于是我们需要一种能力：什么时候需要某个功能，什么时候再把对应的脚本加载进来。这正是动态脚本加载存在的意义。

一、静态引入的隐性代价

在传统的开发方式中，脚本通常通过 HTML 中的 <script> 标签静态引入，或者被打包工具合并进一个体积庞大的入口文件。这种做法直观、简单，但代价体现在几个层面：

• 下载成本：脚本体积直接计入首屏关键资源，挤占带宽，拉长首屏时间。
• 解析与编译成本：JavaScript 需要在主线程上完成解析、编译，体积越大，占用主线程越久。
• 执行成本：即使某些代码逻辑暂时用不到，只要被执行到，就会产生副作用与内存开销。
• 缓存粒度问题：所有功能打成一个包，任何一处改动都会导致整包缓存失效。

换句话说，静态引入相当于“一次性预付费”，而用户可能只消费了其中很小一部分。按需加载则是“用多少付多少”，把成本推迟到真正需要的那一刻。

二、最经典的方法：动态创建 script 元素

DOM 的核心能力之一，就是 JavaScript 可以像操作普通对象一样操作页面中的节点。既然 <script> 本质上也是一个 DOM 元素，那么我们当然可以自己创建它：

const script = document.createElement("script");
script.src = "editor.js";
document.body.appendChild(script);

这三行代码看起来非常简单，但背后发生了一件很重要的事情：

1. document.createElement("script")：创建一个 <script> 元素，此时它还没有被插入文档，也不会触发任何网络请求。
2. script.src = "editor.js"：告诉浏览器这个脚本的地址在哪里，为后续加载做好准备。
3. document.body.appendChild(script)：把这个节点插入页面。只有在节点进入文档树之后，浏览器才会真正开始请求并执行该脚本。

这就是动态脚本加载的最小闭环：创建节点、指定地址、插入文档。相比静态标签，它把“何时加载”的控制权交还给了开发者。

三、动态加载的关键细节

上面的三行代码只是起点。要在生产环境可靠使用，还需要处理一系列细节。

1. 加载完成的时机

脚本插入文档后是异步加载的，后续逻辑必须等待其就绪。可以通过监听 load 事件确认成功，通过 error 事件捕获失败：

function loadScript(src) {
  return new Promise((resolve, reject) => {
    const script = document.createElement("script");
    script.src = src;
    script.onload = () => resolve();
    script.onerror = () => reject(new Error(`加载失败: ${src}`));
    document.body.appendChild(script);
  });
}

注意，onload 触发意味着脚本已经下载并执行完毕，此时其中暴露的全局变量或模块才可安全使用。

2. 并发去重

同一个脚本可能被多个功能模块同时请求。如果不做去重，会重复插入多个 <script> 节点，造成重复请求与重复执行。常见做法是维护一张“地址到 Promise”的映射表：

const cache = new Map();
function loadOnce(src) {
  if (cache.has(src)) return cache.get(src);
  const p = loadScript(src).catch(err => {
    cache.delete(src); // 失败后允许重试
    throw err;
  });
  cache.set(src, p);
  return p;
}

这样既避免了重复加载，又保证失败后可以重新尝试。

3. 错误处理与降级

动态加载多了一次网络往返，失败概率客观存在。除了重试机制，还应在失败时给出可感知的降级方案，例如提示用户“功能加载失败，请重试”，而不是让界面无声卡死。对于关键路径上的脚本，可以设置超时兜底，避免 Promise 长期挂起。

4. 加载时机的选择

动态加载不等于“越晚越好”。合理的时机包括：

• 用户意图触发：如点击“开始编辑”按钮时再加载编辑器脚本，这是收益最明显的场景。
• 空闲时段预取：利用浏览器空闲时间提前加载“高概率会用”的脚本，兼顾体验与首屏。
• 可视区域接近时：对长页面中靠下的交互模块，在滚动接近时再加载。

时机的选择本质上是“预测用户行为”与“控制首屏成本”之间的权衡。

5. 与模块化方案的配合

现代工程中，动态加载往往与模块打包能力结合使用，例如通过动态 import() 表达式让构建工具自动拆分代码块。其底层行为与动态创建 script 元素异曲同工：都是在运行时按需请求一个独立的资源片段。理解原生 DOM 方式，有助于在出现加载异常、跨域配置或执行顺序问题时快速定位原因。

四、适用边界与注意事项

动态脚本加载并非银弹，使用时需注意：

• 执行顺序：动态加载的脚本默认不保证与其他脚本的顺序关系，存在依赖时需显式串联。
• 跨域与安全策略：脚本地址需符合页面的内容安全策略；跨域加载时应注意相关属性配置。
• 资源释放：对于一次性使用的重型模块，可在用完后移除节点并清理引用，配合浏览器的垃圾回收降低内存占用。
• 可观测性：为动态加载增加埋点，统计加载耗时与失败率，才能持续优化。

五、小结

页面变慢，很多时候不是“代码写得不够快”，而是“不必要的代码来得太早”。动态创建 script 元素这一朴素手段，把脚本的加载时机从“页面打开时”转移到“功能真正被需要时”，从源头上削减了首屏的下载、解析与执行开销。在此基础上，配合加载状态管理、并发去重、错误重试与合理的时机策略，就能形成一套可靠的按需加载实践。对于体积大、使用频率低的功能模块，这种改造往往是投入产出比最高的性能优化之一。