大家好，我是Kason。说起Chrome，你的第一反应是什么？市场份额最大的浏览器？著名的V8引擎？标准的浏览器调试-DevTools？对于Chrome团队成员，第一反应很可能是这两个指标（KPI）：UX（用户体验）用户体验DX（开发者体验）开发者体验作为开发者，相信围绕这两个指标你能感受到很多提升：V8底层，webassembly引擎的迭代灯塔工具UX和DX指标量化分析Chrome对新ES标准特性的快速支持当一切都做到极致的时候，围绕这两个指标还能探索什么（KPI能写什么）？让我们一起来看看为了更好的网络体验，为了救国，Chrome团队做了哪些努力。这里的逻辑是这样的：当今世界上大多数的web项目都依赖于开源工具更好的开源工具带来更好的web体验按照这个逻辑，只要我们（Chrome团队）与开源项目合作，让它们成为甚至更好的是，这有助于提供更好的网络体验（并节省KPI）。因此，只需根据其适合的优化类型（UX、DX），选择合适的项目，进行深度合作即可。接下来，让我们看看我们一直在与Chrome团队合作的一些项目。与Next.js的合作Next.js是一个基于React的全功能生产框架，其SSR功能已经与React团队进行了深度合作。基于SSR场景，Chrome团队为Next.js定制了一系列的TimingAPI。新的TimingAPI将与SSR相关的指标合并到统计数据中（例如水合物时间）。同时LightHouse工具可以搜集更多SSR相关的数据供参考：与Babel合作，我们经常使用@babel/preset-env，根据目标浏览器版本，将高级ES语法编译成ES5语法。这种降级编译的实现思路是：每一个高级文法都可以看作是一个或多个文法变换的集合。当遇到高级语法时，它会被这些语法转换的实现所取代。例如：函数参数可以作为三种特征的集合：解构、参数默认值、剩余参数。对于以下源代码：constfoo=({a=1},b=2,...args)=>[a,b,args];@babel/preset-env编译后的输出包含解构和默认参数value和剩余参数三个特征的实现：constfoo=functionfoo(_ref,b){let{a=1}=_ref;if(b===void0){b=2;}for(var_len=arguments.length,args=newArray(_len>2?_len-2:0),_key=2;_key<_len;_key++){args[_key-2]=参数[_key];}返回[a,b,args];};可以看到编译后整体代码量急剧增加！现代浏览器可能或多或少地支持一些高级语法，但支持得不好。因此，一个更好的想法是：用支持的语法替换不支持的语法，这样就可以省去“功能实现”部分的代码。对于上面例子中的语法，只有一种现代浏览器因为自身的bug不支持。解决方法是：将{a=1}换成{a:a=1}。因此，上述代码只需编译成如下形式即可在现代浏览器中运行：constfoo=({a:a=1},b=2,...args)=>[a,b,args];比较两者这样的编译结果，后者比前者少了80%的代码！浏览器差异带来的优化空间，Babel团队很难单独完成。于是，Chrome团队与其合作开发了@babel/preset-modules，并作为bugfixes参数集成到@babel/preset-env中。配合React作为前端领域运行时最重的视图库，React一直在寻找运行时优化的空间。navigator.scheduling.isInputPendingAPI是其与Chrome团队合作的产物。此API返回一个函数。调用此函数后，如果当前正在调度输入事件，则返回true。例如下面的例子，当有鼠标键盘事件被调度时，JS线程的执行被挂起：while(workQueue.length>0){if(navigator.scheduling.isInputPending(['mousedown','mouseup','keydown','keyup'])){break;}letjob=workQueue.shift();job.execute();}输入框的输入可以更快的被浏览器渲染，显着减少浏览器框架调整（表现为输入框暂停的输入内容卡片）。总而言之，一棵树被感动死了，一个人被感动了活着。当项目发展到一定时期，内部优化空间不大时，需要主动赋能其他垂直领域，聚焦用户感知轨迹，利用复用，实现持久效益！换句话说：多去别的团队学吧，会有KPI的。你，学会了吗？
