发布一个快速加载的网页游戏（实用清单）

如果玩家无法在几秒钟内开始游玩，他们就会离开。这篇教程是一份实用清单，几乎可以套用到任何网页游戏技术栈（Canvas/WebGL/WebGPU、Pixi/Three/PlayCanvas、自研引擎等）。

1）先定预算（否则你没法做优化）

根据目标设备选定预算。一个面向"即开即玩"体验的稳健默认值是：

打包的 JS+CSS：gzip 后小于 300–500 KB（越小越好）
首次输入前的关键资源：压缩后小于 2–5 MB
首次可输入时间：中端手机上少于 3–5 秒

把它们写下来，当成 API 契约一样对待。

2）测量正确的东西

在 Chrome DevTools 里：

用 Performance 面板录制一次会话，查看长任务。
用 Network 面板检查：
- 传输大小 vs. 解码大小
- 缓存响应头
- 资源是流式渐进到达，还是作为一个巨大 blob 一次性到达

在游戏的角度，关注：

"玩家何时能动"的时间
"首个有意义的画面"的时间
"首次输入延迟"（输入 → 画面）

3）能压的都压上

确保你的托管能提供：

对文本资源（JS/CSS/HTML/WASM）尽量使用 Brotli（br）
gzip 作为兜底

对于 WebAssembly 构建，压缩往往就是"即开即玩"和"永远加载不完"的差别。

4）别一开始就下载整个世界

把游戏拆成：

启动：最小化加载器 + 输入 + 首个场景
核心：主玩法系统
可选：额外关卡、外观、高分辨率贴图、额外音频等

只在以下情况之后再加载"可选"内容：

玩家已经能玩，并且/或者
你确定玩家想要这些内容（例如他们到了某个菜单/关卡）

5）选对资源格式

对大多数网页游戏：

图片：UI/背景优先用 WebP（如果能接受较慢的编码，可以用 AVIF）。
音频：通用场景优先用 Ogg Vorbis；为苹果生态测试 AAC。
视频：兼容性优先用 MP4/H.264，体积更小且支持时用 WebM。

注意解码成本："下载更小"未必"解码更快"。

6）首个场景保持小而确定

避免在首个可交互场景里出现：

shader 编译风暴
巨大的纹理上传
阻塞主线程的程序化生成
对几兆 blob 的同步 JSON 解析

如果必须做重活，请：

分多帧增量完成，或者
放到 Worker 里（在条件允许时）

7）积极缓存（但要正确）

对内容寻址的资源使用长时缓存：

Cache-Control: public, max-age=31536000, immutable

对 HTML 入口，缓存时间要短，这样才能安全发布更新。

8）让"失败"快速且可读

出错时要展示：

清晰的错误信息
重试按钮
一个反馈问题的链接

静默失败会摧毁信任。

9）如果使用 Wasm 线程，理解 COOP/COEP

如果你的构建依赖 SharedArrayBuffer（一些 Wasm 线程方案常见），你大概率需要跨域隔离响应头：

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

尽早在真实的托管环境上测试，因为响应头和第三方嵌入很容易出问题。

10）让它无需 SDK 就能玩

如果你面向 Cinevva 的创作者工作流，目标是：

一个可靠启动的 URL
启动 demo 不强制登录
可预测的输入控制

这样你不需要再集成额外的 SDK，就可以分发了。

发布一个快速加载的网页游戏（实用清单） ​

1）先定预算（否则你没法做优化） ​

2）测量正确的东西 ​

3）能压的都压上 ​

4）别一开始就下载整个世界 ​

5）选对资源格式 ​

6）首个场景保持小而确定 ​

7）积极缓存（但要正确） ​

8）让"失败"快速且可读 ​

9）如果使用 Wasm 线程，理解 COOP/COEP ​

10）让它无需 SDK 就能玩 ​