前端性能优化中，JavaScript 资源经常被当成重点对象：体积大、请求多、执行还容易阻塞渲染。团队通常优先压缩文件体积，比如开启 Tree Shaking、代码分割和 Gzip。但线上监控里常出现一种情况：接口返回很快，首屏依然慢，排查后发现脚本请求发起太晚、排队时间过长，或者下载完成后没有立即执行。预加载解决的是请求时序问题，缓存则决定下载结果能否被反复复用，两者配合才能把优化收益放大。本文从加载优先级、路由级脚本策略和缓存落地三个层面展开。
一、预加载的本质：先下载，不立即执行
普通 <script> 标签在解析时默认会阻塞 HTML 解析，除非添加 async 或 defer。预加载则不同，它通过 <link> 元素告诉浏览器提前发起请求，但不会把脚本内容注入执行上下文。这里必须区分 preload 和 prefetch：前者面向当前页面确定需要的资源，后者面向下一个导航可能需要的资源。两者的触发时机和网络优先级也不一样，preload 的请求优先级高于 prefetch，浏览器通常只在网络空闲时才处理 prefetch。
一个典型的首屏优化场景是：入口 HTML 里先声明关键脚本的预加载，同时预取用户下一步最可能访问的详情页脚本。示例代码如下：
<!DOCTYPE html> <html lang="zh"> <head> <meta charset="utf-8"> <title>JavaScript资源预加载示例</title> <link rel="preload" href="/static/js/main.js" as="script"> <link rel="prefetch" href="/static/js/detail.js" as="script"> </head> <body> <div id="app"></div> </body> </html>
需要注意的是，preload 下载完成后不会自动执行。如果资源长时间没有被消费，浏览器甚至会在控制台输出提示。常见的做法是预加载后紧接真实 <script> 标签，或者动态创建脚本执行。下面这段代码展示了如何在预加载完成后创建并执行脚本：
const src = '/static/js/main.js';
const link = document.createElement('link');
link.rel = 'preload';
link.as = 'script';
link.href = src;
link.onload = function () {
const script = document.createElement('script');
script.src = src;
document.head.appendChild(script);
};
document.head.appendChild(link);
如果该脚本已经存在于 HTTP 缓存中，preload 请求会直接命中缓存，不会额外下载。但要留意 URL 是否带有动态查询参数，以及服务端是否配置了复杂的 Vary 响应头，这些都可能破坏缓存键的一致性。为了缓存稳定，带版本号的脚本通常建议使用文件名哈希，而不是在 URL 后面拼接版本参数。
二、按场景选择资源加载策略：关键脚本、路由脚本与第三方依赖
不同位置的 JavaScript 资源不应该使用同一种加载策略。首屏渲染依赖的框架、运行时和入口文件，可以用 preload 提前下载；路由级脚本适合用 prefetch，在不影响首屏的情况下降低后续页面切换的白屏时间；而第三方统计、客服组件等非关键脚本，应尽量延迟加载，避免抢占首屏数据请求和关键资源的带宽。
在单页应用中，路由级预加载可以直接通过构建工具的魔法注释完成。以 React 和 Webpack 为例，webpackPrefetch 会在浏览器空闲时发起预取请求，不会阻塞当前页面的关键渲染。
import React, { lazy, Suspense } from 'react';
const DetailPage = lazy(() => import(
/* webpackPrefetch: true */
'./pages/DetailPage'
));
export default function App() {
return (
<Suspense fallback={<div>加载中</div>}>
<DetailPage />
</Suspense>
);
}
对于第三方 CDN 域名，如果资源在多个页面都会被使用，可以提前做域名连接。浏览器提供了 preconnect 和 dns-prefetch 两种机制。preconnect 会提前完成 DNS 解析、TCP 握手和 TLS 协商，dns-prefetch 只提前解析 DNS，成本更低。它们的示例写法如下：
<link rel="preconnect" href="https://cdn.ipipp.com" crossorigin> <link rel="dns-prefetch" href="https://cdn.ipipp.com">
不过 preconnect 并不是越多越好，每个提前建立的连接都会占用浏览器连接池。一般只对确定会请求的域名使用 preconnect，对可能请求的域名使用 dns-prefetch。在 HTTP/2 多路复用场景下，连接建立成本已经下降，但 DNS 解析和 TLS 握手仍然存在，因此这类优化依然有其价值，只是收益需要结合业务实际监控来判断。
三、缓存协同：让预加载后的资源不再成为二次开销
预加载只解决首次请求的启动时机，缓存则决定资源是否会被重复下载。如果缓存策略缺失，用户每次刷新或返回页面时，预加载带来的收益会被重复请求抵消。对于带内容哈希的 JavaScript 文件，可以设置长期强缓存，例如响应头 Cache-Control: public, max-age=31536000, immutable。其中 immutable 告诉浏览器资源在有效期内不会变化，无需重新验证。入口 HTML 文件则应使用短缓存或协商缓存，以便发布新版本后用户能尽早拿到新的脚本引用。
在浏览器层面，Service Worker 可以进一步控制 JavaScript 资源的缓存行为。下面这段代码演示了如何只缓存 /static/js/ 目录下的 GET 请求，并优先返回缓存，网络请求成功后再更新缓存：
const JS_CACHE = 'js-cache-v1';
self.addEventListener('fetch', event => {
const request = event.request;
// 只处理 GET 请求，避免缓存 POST 结果
if (request.method !== 'GET') {
return;
}
const url = new URL(request.url);
// 只缓存 /static/js/ 目录下的脚本
if (url.pathname.indexOf('/static/js/') === 0) {
event.respondWith(
caches.open(JS_CACHE).then(cache =>
cache.match(request).then(cached => {
if (cached) {
return cached;
}
return fetch(request).then(response => {
if (response.ok) {
cache.put(request, response.clone());
}
return response;
});
})
)
);
}
});
CDN 缓存也是不可忽略的一环。当 preload 请求经过 CDN 节点时，如果资源已经被边缘节点缓存，响应速度会明显提升。对于需要版本更新的文件，使用文件名哈希比使用查询参数更可靠，因为部分 CDN 对带查询字符串的资源缓存策略不一致。必要时还可以配合 ETag 和 Last-Modified 做协商缓存，减少传输体积。
综合来看，预加载和缓存不是彼此替代的关系。预加载负责让关键脚本更早进入网络队列，缓存负责让已经下载过的资源不再产生重复开销。落地时可以先用浏览器开发工具观察请求发起时间和优先级，再结合构建产物命名、CDN 缓存策略和 Service Worker 做分层优化。比起盲目把所有 JavaScript 都设为 preload，按关键脚本、路由脚本、第三方依赖三个层级分配策略，通常能获得更稳定的性能收益。
JavaScript预加载资源加载策略缓存机制修改时间：2026-10-04 09:04:33