资源体积过大导致加载卡顿，需通过Network面板定位大文件，压缩图片音频、精简JSON、分组预加载、用Web Workers处理重任务，并合理配置Service Worker缓存策略。
资源体积太大导致加载卡顿，先看哪些文件在拖后腿
打开浏览器开发者工具的 Network 面板，刷新游戏页面，按 Size 列降序排列，重点关注 .png、.jpg、.mp3、.json 和打包后的 game.js。单个图片超 500KB、音频没压缩、JSON 地图数据未精简，都是典型瓶颈。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用
tinypng.com或命令行工具pngquant压 PNG，通常能减掉 40%~70% 体积，且肉眼无损 - 音频统一转成
.ogg（比 MP3 小，Web 兼容好），用ffmpeg -i input.mp3 -c:a libvorbis -q:a 4 output.ogg - JSON 资源导出时禁用缩进，上线前跑一遍
jq -c . map.min.json
Canvas 游戏里图片资源别一股脑全 preload
HTML5 小游戏常在启动时用 Image 对象批量加载所有图集，但用户首屏只看到主菜单或第一关，其余资源完全没必要立刻下载。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 把资源分组：如
["menu", "level1", "ui", "effects"]，每个组对应独立的loadAssets(groupName)函数 - 主场景只预加载
menu和level1；进入第二关前再调用loadAssets("level2")，并配合 loading 提示 - 避免在
for循环里连续 new Image()，改用 Promise.all + 动态 import（如果用打包器）或 fetch + createImageBitmap 提升并发控制力
Web Workers 不能直接操作 DOM，但能干好三件事
JS 主线程被大 JSON 解析、路径寻路计算、粒子系统初始化卡住时，页面会假死。Web Workers 不是万能解药，但它能安全分担三类任务：
- 解析大型关卡数据：
fetch("/levels.json").then(r => r.json())放 Worker 里，解析完 postMessage 回主线程 - 预生成 tilemap 碎片或碰撞网格，尤其当用
canvas.drawImage频繁绘制小块时，提前算好坐标数组比实时计算快得多 - 音频解码准备（如用
AudioContext.decodeAudioData），避免在播放瞬间阻塞渲染
注意：Worker 里不能访问 document、localStorage、XMLHttpRequest（得用 fetch），传参要用结构化克隆（不能传函数或 canvas context）。
Service Worker 缓存策略选错，反而让更新失效
很多开发者一上来就配 CacheFirst，结果改了图片却还在用旧缓存，用户清不了，自己也懵。小游戏资源更新频率高，缓存必须可感知、可控制。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 静态资源（图片、音频、字体）用
CacheFirst，但加版本号：比如请求/assets/sprite_v2.png，而非/assets/sprite.png - JS 主逻辑用
NetworkFirst，并在 install 阶段主动清理旧 cache：caches.delete("game-js-v1") - 首次加载不走 SW，等第二遍才生效——这样可避免 SW 安装失败导致白屏，也方便调试
真正难的是资源依赖关系管理：一张图被多个 JSON 引用，改图就得同步改所有引用它的哈希值。这时候不如用构建脚本自动生成带 contenthash 的文件名，比手写靠谱得多。
