在本周的《前端快爆》看到 Facebook @Scale 2019 技术大会这个视频 https://www.facebook.com/atscaleevents/videos/360885331486122/ 开篇一张图就是 Web 开发者对 native app 不公平竞争的无声控诉：

    image.png

    坦白说 GZip 1.5MB 的前端体积在我这种中老年前端程序员看来已经很可观了，语雀的前端资源体积如何优化一直是萦绕心头的问题之一。但是和动辄数十 MB，甚至还有像手淘、Facebook 这样可以找苹果专门放宽 100 MB 的原生应用比起来，前端确确实实是在戴着镣铐跳舞了，5G 时代都要来了大家要解放思想。

    image.png

    除了下载时间，解析 JavaScript 的耗时也不少，在 CPU 较弱的移动端尤其如此，截图数据都来自 Addy Osmani 的《The Cost of JavaScript 2018》所以我想这个数据已经不新鲜了。这篇分享的主题借此展开，我们该如何优化解析时间？

    我略过了前文关于 Service Worker 的部分，分享者所讲述的最终方案是原始页面和加载 Service Worker 的页面分成两个，后者专门用来初始化 app cache，从而保证前者不受干扰，初始化完成后再给前者开启缓存。

    光靠 Service Worker 优化不了这部分时间，作者第一个想到的是 WebAssembly，但 Web Assembly 也有利弊，比较麻烦的地方在于：

    1. WebAssembly 编译需要静态链接，与常用的 JavaScript 动态加载模式相悖；
    2. 编译产出的文件体积更大；
    3. 额外的启动时间；
    4. 相较而言，仅适合用来优化 CPU 密集型的部分；

    然后作者分享了 Facebook、Mozilla、Bloomberg、CloudFlare 等公司一起推出的 BinAST（参考实现是 Rust 写的耶）：

    image.png

    结合上述函数标注信息，JS 引擎可以只解析 BinAST 中需要执行的函数，从而缩短完成当前工作所需的解析时间：

    image.png

    下面是效果数据，facebook.com E2E 耗时减少 5%（所以 Facebook 使用的 headless firefox 做 E2E 测试的？）

    image.png

    分享者收尾的之后说 Facebook 生产也已经开启 BinAST，不太确定降级方案如何。从目前的支持程度来看，当前方案还比较早期，适合在可控环境下优化（E2E、desktop app）。