Service Worker预加载核心页面的关键在于提前拉取、缓存托管与智能触发：在install或activate阶段主动fetch并缓存高频HTML入口，配合导航预加载和fetch事件精准匹配，实现秒开。
移动端网页通过 Service Worker 预加载关键核心页面，核心在于“提前拉取 + 缓存托管 + 智能触发”。不是等用户点击才加载，而是在后台静默获取并存入 Cache Storage，后续访问时直接从缓存响应，实现秒开体验。
预加载哪些页面才算“关键核心”
通常指用户高频访问、业务路径起点、或首屏强依赖的页面，例如：
-
首页入口（如
index_v2.3.1.html） -
登录/注册页（
login.html、register.html） -
活动主会场（如
campaign_2026_fall.html） -
商品列表页或搜索页（
list.html、search.html）
注意：只预加载 HTML 入口文件本身，其引用的 CSS/JS/图片等静态资源可配合 <link rel="preload"> 或由 Service Worker 在 install 阶段一并缓存。
Service Worker 中实现预加载的关键步骤
预加载不是靠 HTML 标签完成的，而是由 Service Worker 主动发起请求并写入缓存。典型流程如下：
-
在 install 阶段缓存已知核心页面：适用于版本固定、上线前就确定的页面
例如：caches.open('core-pages-v1').then(cache => cache.addAll(['/index.html', '/login.html'])) -
在 activate 或后台定时任务中动态预加载新版本：通过轮询版本接口（如
/api/version），拿到新版 HTML 路径后，用fetch()请求并存入对应缓存空间（如core-pages-v2） -
区分请求方式提升成功率：HTML 文件必须用
fetch()获取并手动存入 cache；其他静态资源（CSS/JS/字体）可用<link rel="prefetch" as="script">辅助，但 Service Worker 仍需监听并接管，确保跨域资源加crossOrigin属性
让预加载真正“生效”的两个细节
光缓存了还不够，得让用户访问时真走缓存：
-
fetch 事件中优先匹配预加载缓存：
对核心页面 URL（如以/index_或/campaign_开头的 HTML），先查对应 cache 名称，命中则直接return response，不发网络请求 -
启用导航预加载（Navigation Preload）：
注册时开启：registration.navigationPreload.enable()；在 fetch 事件中用event.preloadResponse接收浏览器并行拉取的响应——这对用户首次刷新或冷启动特别有用，能大幅缩短白屏时间
如何验证预加载是否成功
打开 Chrome DevTools → Application → Cache Storage，查看对应缓存名下是否有目标 HTML 文件；再切换到 Network 面板，刷新页面，观察该 HTML 的 Size 显示 from ServiceWorker 或 from Cache，而非 from network。同时留意 Console 是否有缓存写入或匹配的日志输出。
