Web Bundles来自WICG的Web Packaging提案，目标是把一组Web资源打包成类似压缩包的.wbn文件。与普通ZIP不同，每个资源都保留请求URL、响应状态码和响应头，因此浏览器可以像收到真实HTTP响应一样还原资源。对CDN而言，它不再需要为几十个小文件分别建立缓存条目，而可以把一个离线应用当作一个不可变对象来分发和缓存，这正好契合弱网、离线优先和内容分发场景。
为什么Web Bundles适合CDN离线分发
传统离线Web应用通常依赖Service Worker拦截请求，将页面、脚本和样式逐个存入Cache Storage。这种方案第一次访问时必须先获取HTML，再由浏览器解析出后续资源列表，然后依次发起请求。弱网或高延迟场景下，每个请求的握手与排队都会放大等待时间，一个页面可能被几十个并行请求拖慢。
Web Bundles把这个过程反过来：构建阶段就把整条资源依赖图打成一个.wbn文件，浏览器在一次响应中拿到完整包，内部URL映射可以避免额外的网络往返。CDN侧也更容易管理缓存，因为只需处理一个文件，不再为每个子资源单独配置TTL、清理和回源策略。对于需要离线阅读器、文档站、应用壳和微前端资源集合的产品，这种打包粒度能显著降低分发复杂度。
需要注意的是，Web Bundles不是要替代Service Worker，它可以与Service Worker配合。服务端提供完整包，客户端仍然可以通过Service Worker做更细粒度的更新、请求重定向和离线回退。两者组合后，应用首次打开时走包加载，后续增量资源仍可单独请求，这样兼顾了性能与灵活性。
从零生成一个.wbn离线包
生成.wbn文件可以使用Web Platform Incubator Community Group提供的命令行工具。下面以gen-bundle为例，假设站点资源已经放在site目录中，baseURL指向最终线上地址：
go install github.com/WICG/webpackage/go/bundle/cmd/gen-bundle@latest gen-bundle -baseURL https://ipipp.com -dir site -o app.wbn
执行后会生成app.wbn。这个文件内部并不是简单地把文件拼接起来，而是按照application/webbundle格式，为每个资源记录请求URL、状态码、响应头和响应体。例如首页的入口记录会包含200状态码、Content-Type为text/html，以及完整的HTML内容。浏览器解析包时能据此重建HTTP语义，就算HTML中引用的是绝对地址，也能正确映射到包里对应的响应体。
如果不想在本地安装Go工具链，也可以通过Node包或持续集成脚本生成。核心参数通常包含baseURL、输入目录和输出文件，管线可以把构建产物先写入临时目录，再调用打包命令。包生成后建议校验一下体积和解压后资源数量，避免把源码映射文件或大体积媒体误包进去。对于大文件，可以单独拆分到CDN普通缓存中，Web Bundles更适合承载页面骨架和关键脚本样式。
签名是另一个需要提前决策的点。无签名包适合个人项目或低安全要求场景，但无法向浏览器证明内容源身份；签名包通过Signed HTTP Exchange机制把资源与来源站点的证书签名绑定，更适合对外提供可信的离线内容。签名会增加构建和证书管理成本，因此在CDN分发前应先确认目标浏览器对签名包的支持情况，再做选择。
CDN配置与缓存版本管理
CDN需要能识别.wbn扩展名并返回application/webbundle这个MIME类型。以Nginx为例，可以在server或location块中添加类型映射：
types {
application/webbundle wbn;
}
location /bundles/ {
add_header Content-Type application/webbundle;
add_header X-Content-Type-Options nosniff;
}
如果CDN具备规则引擎，也可以按路径配置MIME和缓存行为。版本化URL是离线包更新的关键，建议把包名带上内容哈希或版本号，例如app-9f8e7a.wbn。这样每次发布新包都会生成新地址，配合Cache-Control: public, max-age=31536000, immutable可以安全地让边缘节点长期缓存，不会出现同名文件内容更新但旧缓存未失效的问题。
启用Brotli或Gzip压缩也能减少传输体积，但需要注意压缩后的响应不应破坏包结构。浏览器接收时看到的是压缩后的字节流，解压后必须仍然是有效的application/webbundle格式。一般通过CDN的压缩功能对.wbn做传输层压缩是安全的，但如果压缩策略只配置了text/html、application/javascript等类型，需要额外把application/webbundle加入压缩列表。
回源策略同样重要。源站可以把.wbn文件放在对象存储中，CDN开启回源校验和失败重试。由于包文件通常较大，建议使用HTTP/2或HTTP/3传输，可以减少单连接队头阻塞的影响。多区域分发的产品还应监控首包时间，必要时配置预热任务，在发布后主动让主要边缘节点拉取新包。
页面加载与回退实践
在页面中声明资源包可以使用<link rel="webbundle">元素。href指向包文件地址，resources列出希望从这个包中加载的原始资源URL：
<link rel="webbundle" href="https://cdn.ipipp.com/bundles/app-9f8e7a.wbn" resources="https://ipipp.com/ https://ipipp.com/app.js">
当浏览器解析到这条声明时，会尝试拉取整个包，后续遇到resources中匹配的资源请求可以直接从包里读取，不再单独向网络发请求。对于不支持Web Bundles的浏览器，这条<link>声明会被当作普通未知关系忽略，页面仍会按传统方式请求资源。因此它可以作为一种渐进增强手段，不破坏现有站点结构。
更稳妥的做法是配合Service Worker记录包版本和资源清单。首次加载由<link rel="webbundle">提示浏览器，后续增量资源仍可由Service Worker缓存；当检测到新版本包时，Service Worker可以在后台预加载，并在下次激活后切换到新资源集合。下面是一个简单的注册脚本：
if ('serviceWorker' in navigator) {
navigator.serviceWorker.register('/sw.js').then(function(reg) {
console.log('Service Worker 已注册', reg.scope);
}).catch(function(err) {
console.warn('Service Worker 注册失败', err);
});
} else {
console.info('当前浏览器不支持 Service Worker，继续使用普通网络请求');
}
这个脚本不含依赖，适合作为离线回退的基础。实际项目中还要在sw.js里定义缓存名称、预加载逻辑和删除旧缓存的时机。Web Bundles负责减少首屏关键资源的请求次数，Service Worker负责后续增量资源与离线兜底，二者边界清晰，也便于在浏览器兼容性变化后调整策略。
上线前建议用终端或开发者工具确认MIME类型和响应头是否正确。CDN返回的Content-Type必须是application/webbundle，若被识别成text/plain或application/octet-stream，浏览器可能不会按照Web Bundles格式解析，最终退化为普通下载。网络面板中还应观察包请求是否只发生一次，后续子资源是否命中包内映射，这能帮助判断加载链路是否符合预期。
Web Bundles离线Web应用CDN缓存策略修改时间：2026-09-23 04:10:39