前言

Web 开发者为了了解或则统计自己站点的性能，可以通过浏览器标准接口 Navigation Timing API 来获取一些页面性能上的相关耗时数据，如 requestStart，domComplete 等。但是仅仅这些数据还无法准确反映页面的真实性能，特别是移动Web所注重的首屏性能。于是就有了一些通过 domComplete 时间，页面加载完成时间等作为参考的性能体系，这些参考体系并不完全准确，并非用户角度真正意义上的首屏。

首屏性能定义

首先说一下什么是首屏性能：

移动 Web 页面受网速和终端手机性能影响，用户通常会比较关注页面内容完全显示出来的时间，过长的时间会极大考验用户的耐心，这个时间的长短是影响用户体验的关键因素之一，很大程度上决定着用户的去与留。

一个页面的加载性能怎么样，就是看从开始加载到首屏内容显示出来需要经需要多长时间，所以就有了首屏性能这个指标来衡量页面的加载性能。

UC的首屏性能评估体系

UC 在手机浏览器领域耕耘多年，她是怎么来衡量页面加载性能的呢，又有哪些指标体系，今天就来为大家解读一下。

用户从点击到首屏渲染完成主要路径如下图：

说明：

• start：blink 内核开始创建请求的时间；
• t0：blink 收到 http head 的时间；
• t1：首屏有内容显示的时间；
• t2：首屏全部显示出来的时间；

自然而然 UC 也是使用首屏性能来衡量各站点的性能情况，UC 对首屏性能的定义是从用户使用的角度来定义的，即：首屏加载完成时间是以页面首屏区域所要显示的资源已经全部显示出来的时间为准，该时间点也被定义为 t2 时间点。

当然用户能直接感受到的性能指标除了 t2 还有 t1，UC 内核对 t1 的定义：页面首次有内容显示的时间。t1 在UC使用了多年，在以前弱网络占比较高的时代，t1 在还是有其比较大的性能衡量价值，目前也还在继续沿用。鉴于目前国内的网速提高很快，t1 衡量的权重已没弱网络时代那么高了，衡量体系已经快速偏向 t2， UC内部的自有业务性能衡量目前都是在采用 t2 来衡量性能。

t2 即首屏是否渲染完成的判断是一个相当复杂的工作，所以到目前为止现有其他浏览器都没有真正首屏渲染完成的事件，包括 Chrome。在首屏性能相关的一些打点统计中，包括以前的 t1 和现在的 t2，UC 一直走在 Chrome 前面，当然目前 Chrome 也在这块发力，Chrome 在较新版本内核开始支持 First Meaningful Paint，据他自己的描述大概准确率 75% 左右。

UC 内核的 t2 计算是采用自己创新的一套算法，从渲染层次去计算何时页面首屏渲染完成，简单来说就是根据页面内容以及图片资源加载渲染的情况做出判断给出一个合理且较准确的时间值，所以计算出来的值非常贴近用户的实际感受，因为是在内核渲染层级代码实现的统计，所以带来的性能消耗也相对较小，在可控范围内。

该统计方法通过抽取线上 1000 个 TOP 移动站点的页面，再经过 UC 内部的 WPT 测试工具对比验证，准确率和覆盖率可达 85% 以上。

UC首屏性能统计指标 API 扩展

目前，我们已在最新发布的 Android UC 浏览器 11.5.0.939 版本扩展了性能统计指标 API，在现有的 ucweb.window 对象下增加了 performance 对象来提供 t0、t1、t2 接口，新增加一个自定义事件 BacktracePaintReady，脚本通过注册监听该事件，当收到事件通知时则可获取t0、t1、t2 的值，单位为 ms。

该自定义事件通知在切换页面（前进、后退、刷新、关闭页）的时候触发，获取到的 t0、t1、t2 必须采用 navigator.sendBeacon 方法上传。

调用方法示例代码：

window.ucweb.window.addEventListener('BacktracePaintReady', function (){
  var t = window.ucweb.window.performance;
  var data = {t0: t.t0, t1: t.t1, t2: t.t2};
  var blob = new Blob([JSON.stringify(data, null, 2)], {type: 'application/json'});
  navigator.sendBeacon('http://yourwebsite.com', blob);
}, false);

性能优化的方向

所以，前端性能问题首先是统计问题，只有采取了恰当的统计方法，收集到准确的统计数据，我们才可以更加准确量化优化的效果。

Web 页面性能优化绝不是浏览器内核或业务页端单方面的事情。通常情况下业务对内核的实现不了解，某些情况下为了实现某个功能点，需要靠猜，靠验证，费时费力，且不一定能达到效果。而内核侧通常情况下离业务比较远，对页端惯用的技术或则方法并不一定完全了解，其性能优化的思路更多的是从内核本身的角度去考虑，实际不一定贴合业务，体现不出价值，甚至都不知道还有什么优化空间。

在弱网络时代，性能优化的重要方向之一就是怎么样提高加载速度，更多的是依赖缓存，预连接，资源加载控制等手段来优化加载性能。而在快速网络的时代，随着Web技术的发展，H5技术普及，页面效果越来越炫，复杂度也越来越高，纯粹的资源加载速度已经不是最大的痛点了，资源的加载时机，用户的交互体验又成了最大的痛点了，性能优化难度也越来越大，单独任何一个技术端的优化都也很难优化出满意的整体效果，这就凸显从前端到后端再到浏览器内核各端的技术数据拉通显得越来越有必要了。