Prefetch
要做到资源拉取 和 发起取数并行，就有必要把取数提前到第1优先级（HTML解析完毕后立即执行，而非等待SCRIPT标签资源加载执行过程中发起请求），我们的流程会变成如下：
需要特别注意一点：由于JS的执行是串行，发起取数的那段逻辑必须要先于主流程逻辑执行，并且不能放到nextTick（如使用setTimeout(() => doFetch())），否则主流程会一直占用CPU时间使得请求无法发出
主动任务调度
浏览器对资源也有优先级策略，但它并不知道业务层面的我们，到底想要哪些资源先加载/执行，哪些资源后加载/执行，所以我们跳出来看，若把整个业务层面的资源加载+执行/取数流程拆成一个一个小的任务，这些任务全权由我们自己来控制其：打包粒度、加载时机、执行时机，是不是意味着能最大化利用CPU时间和网络资源了？
答案是肯定的，不过一般对于简单的项目，浏览器本身的调度优先级策略已经足够满足需要，但如果针对大型复杂项目，要做的相对极致的优化，就有必要引入“自定义任务调度”方案了。
以Quick BI为例，我们的前期目标是：让首屏主要内容展现更加快速。那么从资源加载、代码执行、取数层面是应该根据我们业务优先级作CPU/网络分配的，比如：我希望“卡片的下拉菜单”，在首屏主要内容展示完毕后或CPU空闲时，才开始加载（即降低优先级，更甚至在用户鼠标移入卡片中时，又希望它提高优先级立即开始加载并展示）。如下：
这里我们封装了一个任务调度器，其目的是可以声明一段逻辑，在其某个依赖（Promise）完成后开始执行。我们的流程图变化如下：
黄色区块代表 作优先级降级处理的部分模块，其帮助减少了整个首屏时间
TreeShaking
上面讲方法大多从优先级出发，其实在前端工程化日益复杂的时代（中大型项目已超几十万行代码），诞生了一个较为智能的优化方案用于减少包大小，其思想很简单：工具化分析依赖关系，将没有被引用到的代码从最终产物中剔除掉。
听起来很酷，实际用起来也非常不错，但这里想讲一些很多其官网也不会提到的点 --- TreeShaking经常失效的情况：
副作用副作用（Side Effects）通常表达的是对全局（如window对象等）或环境会产生影响的代码。
如图示例，b代码看似未被使用，但其文件中存在console.log(b(1))这样的代码，webpack等打包工具不敢轻易移除它，所以它会被照常打入。
解决方法在package.json 或 webpack配置中明确指定哪些代码具备副作用（例如sideEffects: [“**/*.css”]），无副作用的代码将被移除
IIFE类代码IIFE即会被立即执行的函数表达式（Immediately invoked function expression）
如图，这类型的代码，会导致TreeShaking失效
解决方法三个原则：
[避免]立即执行的函数调用
[避免]立即执行的new操作