自动名称优化后就没法用[‘propName’]方式访问一些内部方法和变量了吧？对于js来说感觉不可接受（
obj["key"] 和 obj.key 没有什么区别，只是语法不同，都可以被静态分析。
像 obj[Math.random()] 这种无法被静态分析的就显然不行了，但是极少类会需要动态访问。
1赞
能搞一点就不错了！搞这些优化都要专门的人盯着搞不然很难做成！最好多看下竞品！！！
与水平低的比较是吧 
web启动速度一定要优化下，留住用户的关键。
从加载完成到显示游戏画面真的很慢啊，一个小游戏感觉中间有6-7秒才显示出来，3.8.3这个版本有什么可以优化的措施吗？
首包太大了吧
一个小游戏，没太多东西啊 
问题：
1.公司要求启动优化，加载速度优化（WEB）.
2.公司要求减少包体大小。
3.creator的加载是线性的，包括加载system.js,cc.js,index.js,application.js,spine等脚本
4.启动时，必须线性加载完成后才能进入游戏的加载进度条，这中操作在网络环境不理想的时候是极度致命的。会在index.html里面卡很久都无法进入到游戏里面。
5.合并所有JSON并不能合并cconb文件，当游戏中使用到的AnimationClip越多，request就会越多。
6.在web端，creator并没有对bundle进行zip格式的支持。
处理方式：
1.为了解决启动时的线性加载问题，将所有脚本，包括index.js,application.js,scr/import-map.json,src/polyfills.bundle.js,src/system.bundle.js,src/chunks/xxx.js,cocos-js/文件夹下所有非wsm,wasm的js文件打包成一个zip包。
2.将main,internal,resources(可选)打包为一个zip包。
3.将其他bundle分别打包为一个zip包。
4.新增[项目构建模板]，对index.ejs进行魔改，编写下载zip的方法。
5.修改论坛上在web上使用zip加载资源的方法，拦截所有XMLHttpRequest，使用zip中的资源进行加载。
6.修改dowload-script.ts脚本，将脚本的加载指向zip包。
7.修改download-dom-image.ts脚本，将图片的加载指向zip包。
8.魔改system.bundle.js脚本，将内部加载脚本和import-map.json的地方指向zip包。
9.打包后，删除所有cocos creator在index.html中所有的线性加载。
10.在index.ejs中编写自定义的进度条和logo展示，进入游戏时立即出现闪屏界面，并显示进度条开始下载zip包体。
11.自此，玩家打开游戏时，会立刻展示闪屏和加载，再也不会卡在那里了。
完成以上操作后，进入游戏main界面只需要下载两个zip。
所有加载资源和脚本的request都被拦截了，理论上来说，每个bundle只会有一次request的机会，那就是下载zip的时候。
经过测试，所有脚本压缩在一起后的大小是：579kb，包含引擎启动时的脚本：
所有main，internal，resources压缩在一起：
当然我的resources里面有一些资源，这个和每个人放的东西的大小有关。
wasm和wsm的还没有放到zip中，因为暂时没有时间去弄，本身项目也没有用到spine之类，暂时就没有这个需求
3赞
包体确实没区分好平台，例如发布小游戏，工具应该内部自动裁剪不需要的，一股脑往里塞，可能是模块化没隔离，有些没法去掉勾选，就默认打进去了，2.x没这个问题
我看到引擎组改了 200 多行代码，把变量名缩短了…… 按一行代码减少 10 个字符，总共减少 2048 个字符好了，那就是 2KB 的收益…… 你们确定这是认真的？
当然不管怎么说，看到你们开始重视 JS，开始重视包体，我还是挺高兴的。
4赞
那把所有类名缩短是不是也能减少不少。。。
看起来收益不大，但是大大降低了代码可阅读性
我看到这个pr的时候，就懵了~
2赞
刷kpi吗？？？？ 
当时看到这个PR，想言不敢言。。。
大佬现在可以把以前想说又不好说的都提出来了
1赞
有线上数据修改前后的对比没，我还没有那么激进，只是把一些首屏用到的资源在引擎加载的过程中进行预加载了，目前来看90分位用户是6-8秒左右进入首屏(资源体积压缩后在2.5M)，未优化前在10秒外
