Three.js 加载 glTF 慢需先定位瓶颈：网络下载、CPU 解析（GLTFLoader.parse）或首帧渲染；再针对性优化——压缩纹理用 KTX2+Basis Universal，几何体用 Draco（须配解码器），分块加载与懒实例化降低主线程压力。

Three.js 加载 glTF 模型慢，先看瓶颈在哪

加载慢不等于模型“大”，更可能是网络传输、解析或渲染初始化阶段卡住。用浏览器 DevTools 的 Network 和 Performance 面板确认：是 gltf 文件下载耗时长？还是 GLTFLoader.parse() 耗 CPU？抑或 scene.add() 后首帧掉帧？不同瓶颈对应完全不同的优化路径。

压缩纹理：用 KTX2 + Basis Universal 替代 PNG/JPG

纹理常占 glTF 包体积 70% 以上。直接压缩 PNG 不仅效果差，还无法 GPU 直接解码。必须转成 GPU 原生支持的格式：

• 用 toktx 工具将 PNG 转为 .ktx2，启用 --encode basis（Basis Universal 编码）
• 在 glTF 中通过 EXT_texture_webp 或 KHR_texture_basisu 扩展声明，Three.js 会自动调用 THREE.TextureLoader 的 ktx2 支持
• 实测：一个 8MB 的 4K albedo PNG → 转成 BC7 KTX2 后仅 1.2MB，且 GPU 解码零等待

toktx --encode basis --genmipmap --bcmp input.png output.ktx2

精简几何体：draco 压缩不是万能的，得配对解码器

draco 能把 .glb 几何数据压到原大小 10–15%，但代价是 JS 解码开销。若没配对加载，Three.js 会静默失败，控制台只报 DRACOLoader: Cannot decode DRACO compressed buffer。

• 导出时用 Blender glTF 插件勾选 Draco Compression，或用 gltf-pipeline -d
• 代码中必须显式注册解码器：DRACOLoader.setDecoderPath('./js/libs/draco/') ，且确保 draco_decoder.js 和 draco_wasm_wrapper.js 在该路径下
• 移动端注意：WASM 解码比 JS 快，但首次需编译；低端安卓可能 fallback 到 JS 解码，延迟更高

分块加载与懒实例化：避免一次性 add() 全部节点

哪怕模型已压缩，scene.add(...) 大量 Mesh 仍会阻塞主线程。尤其含数百子对象的建筑模型，add 过程本身就能卡帧。

立即学习“前端免费学习笔记（深入）”；

• 用 gltf.scene.traverse() 提前遍历，按语义分组（如 name 含 "wall" 或 "furniture"）
• 用 requestIdleCallback() 分批 add，每批 ≤ 10 个 Mesh，避免连续 50ms 以上占用
• 真正需要渲染时才创建材质/几何体：例如用户拖拽到某楼层再加载该层家具，而非启动就全 load()

复杂模型的加载优化，本质是把「一次性重活」拆成可中断、可调度、可降级的小任务。压缩只是起点，加载策略和运行时管理才是决定体验的关键。