网页性能优化：按需动态加载JS脚本的实践指南

一、问题从何而来：首屏脚本为什么越来越重

很多网页在初次打开时，会把整站需要用到的脚本一次性下发到浏览器。这样做在功能简单、代码量较小的场景中并无明显问题，但随着业务复杂度上升，脚本体积很容易从几十 KB 膨胀到几百 KB，甚至几 MB。

脚本体积增大并不只是“下载慢一点”这么简单。浏览器在解析 HTML 的过程中，遇到同步的 <script> 标签时，会暂停文档解析，优先完成脚本下载与执行。如果页面中同时包含多个大型脚本，用户从输入地址到真正可以操作页面之间的时间会被显著拉长。

更重要的是，这些脚本里往往包含大量“用户当前根本用不到”的能力。例如页面里的富文本编辑器、图表渲染模块、复杂表单校验逻辑等，一旦全部放进首屏加载路径，就会造成不必要的资源消耗。

因此，一个更合理的策略是：先加载页面核心功能必需的最小脚本，再在用户触发特定操作时，按需补充加载其他脚本。

---

二、动态脚本的核心思想：什么时候要用，什么时候再加载

“按需加载”在模块开发和构建阶段已经比较常见，但这里要讨论的是浏览器运行时层面的能力——即页面已经打开之后，如何根据用户行为动态引入新的脚本。

它的基本逻辑可以概括为：

1. 用户访问页面时，只加载首屏必需的脚本。
2. 用户进行了某个操作，例如点击“开始编辑”“展开图表”“打开高级设置”。
3. 页面捕获到这个操作后，才开始请求对应的脚本。
4. 脚本加载完成后，再初始化该功能。

这种能力在复杂中后台系统、内容平台、可视化编辑工具等场景中非常实用。它可以避免所有用户都为“少数人才会使用的功能”付出额外成本，也能让低端设备或弱网环境下的首屏体验明显改善。

---

三、最基础的实现方式：动态创建 script 元素

在浏览器环境中，HTML 中的 <script> 本质上也是 DOM 节点。只要页面还没有完全卸载，JavaScript 就拥有操作 DOM 的能力，自然也可以动态创建、修改和插入 <script> 元素。

一个最简实现通常包含三步：

// 1. 创建一个 script 元素
const script = document.createElement("script");
// 2. 设置脚本地址
script.src = "editor.js";
// 3. 将 script 元素插入页面
document.body.appendChild(script);

这三行代码看似简单，但执行时会发生几个关键动作：

• document.createElement("script") 只是在内存中创建了一个脚本元素，并不会立即发起网络请求。
• 给 script.src 赋值以后，浏览器仍然不会立刻下载，因为该元素还没有进入文档中。
• 只有执行 appendChild 将脚本节点真正挂载到页面后，浏览器才会开始请求并执行该脚本。

所以，我们可以把“插入页面”这一步放到任何业务时机中。例如：

document.querySelector("#startEdit").addEventListener("click", () => {
  const script = document.createElement("script");
  script.src = "editor.js";
  document.body.appendChild(script);
});

这样，编辑器脚本只有在用户点击“开始编辑”按钮后才会被下载和执行。

---

四、进一步优化：如何知道脚本加载完成了

动态插入脚本可以解决“何时加载”的问题，但在实际业务中，我们通常还需要知道脚本“何时加载完成”，以便执行后续初始化逻辑。

常见的做法包括监听 load 事件和 error 事件：

function loadScript(url) {
  return new Promise((resolve, reject) => {
    const script = document.createElement("script");
    script.src = url;
    script.onload = () => resolve();
    script.onerror = () => reject(new Error(`Failed to load script: ${url}`));
    document.body.appendChild(script);
  });
}
// 使用
document.querySelector("#startEdit").addEventListener("click", async () => {
  try {
    await loadScript("editor.js");
    initEditor();
  } catch (error) {
    console.error(error);
  }
});

这种封装有两个明显好处：

1. 可复用性：页面中任何地方需要按需加载脚本时，都可以调用同一个函数。
2. 错误可感知：脚本地址错误、网络异常、跨域限制等问题可以通过 error 事件被捕获，而不是无声失败。

---

五、工程化视角下的补充说明

动态创建 <script> 是一种非常直接、兼容性良好的运行时加载手段。它不依赖任何特定框架，也不要求项目必须具备模块构建能力，因此在一些存量项目或轻量级页面中仍然非常实用。

不过，动态脚本加载也需要注意几个工程问题。

5.1 重复加载

同一个脚本可能因为用户多次点击按钮而被重复插入。例如用户连续点击“开始编辑”三次，就会创建三个 script 元素请求同一份脚本。

一个常见的防御策略是，在创建脚本前先检查页面中是否已经存在相同地址的脚本：

function hasScript(url) {
  return Array.from(document.scripts).some((script) => script.src === url);
}

或者在模块内部维护一个状态标记：

let editorLoaded = false;
document.querySelector("#startEdit").addEventListener("click", async () => {
  if (editorLoaded) {
    initEditor();
    return;
  }
  await loadScript("editor.js");
  editorLoaded = true;
  initEditor();
});

5.2 脚本加载期间的交互反馈

较慢的网络环境下，脚本下载可能需要数百毫秒甚至更长时间。此时应在 UI 上提供状态反馈，例如按钮置灰、显示加载指示器、展示“功能准备中”等提示。

这样既能避免用户多次点击，也能让等待过程更可预期。

5.3 执行顺序与依赖关系

如果一个功能需要加载多个脚本，而这些脚本之间存在依赖关系，就需要按顺序加载。例如：

• 先加载核心库；
• 再加载图表组件；
• 最后加载业务初始化脚本。

此时可以使用 async/await 或链式 Promise 保证执行顺序。

5.4 与构建产物的关系

在现代前端工程中，代码通常会被拆分成多个构建产物。动态脚本加载既可以指向独立的静态资源地址，也可以配合构建工具的代码分割能力，将某些功能抽成独立文件。

无论采用哪种方式，核心原则是一致的：不让非首屏功能占用首屏网络与执行资源。

---

六、什么时候适合使用动态脚本

并不是所有页面都需要动态加载脚本。如果脚本总量本身很小，或大部分功能在首屏就必须可用，那么引入运行时加载逻辑反而会增加复杂度。

以下场景更适合采用按需加载：

• 脚本体积明显较大，但触达率较低。例如只有少数用户会打开富文本编辑器、数据导出面板、高级筛选等。
• 页面核心路径对加载速度要求较高。例如面向移动端用户、弱网环境或需要快速展示首屏的内容页面。
• 某些功能存在明确触发入口。例如“点击查看详情”“点击生成报告”“点击开启高级模式”等。

如果某个功能在 90% 以上的访问中都会用到，那么将它放入首屏同步加载反而是更简单、更可靠的选择。

---

七、动态脚本不是银弹，但它是非常实用的优化手段

页面性能优化通常没有单一方案可以解决所有问题。动态脚本只是其中的一个环节，通常还需要配合资源压缩、缓存策略、服务端响应优化、渲染优化等手段共同使用。

但它的价值在于，让开发者可以根据真实用户行为来分配加载时机，而不是让所有用户都承担最重的那部分初始化成本。尤其当页面中的某个功能代码体积达到几百 KB 乃至更大时，把它从首屏加载路径中移出，往往能带来直接可感知的速度提升。

动态创建 <script> 的实现并不复杂，关键是理解它背后的思路：把不需要立即使用的资源，移到真正需要的时刻再加载。 这种思想不仅适用于脚本，也可以延伸到样式、图片、组件、数据请求等更广泛的资源类型中。