Web 前端性能分析（一）

参考链接

1. 初探 performance – 监控网页与程序性能
2. 使用简洁的 Navigation Timing API 测试网页加载速度
3. 前端性能统计
4. 前端性能——监控起步
5. 使用性能API快速分析web前端性能
6. Page Visibility

通过以上几篇文章，可以对前端性能相关的概念和 API 有一个整体的认识。

简要说明

前段时间和同事一起对网页性能监控方面的知识做了些探讨和实践，期望可以对用户的网络情况、程序的性能状况等做个统计分析，从而对程序进行有针对性的优化。为此我们做了个简单的试验项目，主要对 页面加载 和 ajax请求 两个方面进行了分析。（本文的方案主要是出于技术探讨的目的，只是一个 Demo，而非完整的性能监控方案）

这个图是最初的方案图，我们初级版本的程序设计基本上就是按照图上这个思路来的。

我们的实现思路是，在页面初始化完成后，将本次页面加载的信息和用户上次页面操作过程中发出的ajax请求信息上报给服务器，由服务端进行进一步统计分析。

页面加载信息，主要指css样式表、js脚本和图片等外部资源加载用时和初始化完成的时间（全部完成用时）。
用户上次页面操作过程中发出的ajax请求，主要是指用户上一次在这个页面上进行的查询、自定义设置等操作过程中，触发的ajax请求相关的信息，比如方法名称、服务器处理时间、客户端下载时间等。

为什么是用户上次操作的ajax相关信息？
主要是出于减少请求的目的，以避免监控程序本身对程序主体性能的影响，因此不会将每个请求的信息都实时的上报服务器，而是先存储在客户端。我们会将用户在这个页面进行的各种操作触发的异步请求信息，以一定格式存储在客户端 localstorage，当用户再次打开这个页面的时候，我们会从 localstorage 中取出存储的ajax信息，将其上报服务器，然后清空 localstorage 中这些旧的数据，以便重新进行记录。

因此，用户在打开这个页面时，我们上报的是用户上次的使用信息。（如果有用户只打开过一次这个页面，后面就再没使用过，那么这是一个低频使用客户，不在我们统计范围内。）

而用户的页面加载信息，每次用户打开页面时，我们都会将其上传至服务器，不需要在客户端进行存储。

服务端收到前端上报的数据后，会进行相应的分析处理，这里不对这部分进行说明。

相关知识

一、影响网页性能的因素

1. HTML 的解析和渲染（参见文档 《浏览器解析渲染HTML页面的过程》）
2. 服务端处理的速度（负载均衡，缓存策略）
3. 客户端带宽（网络状况）

我们要对网页的性能进行统计分析，首先应当确定哪些因素会对网页的性能带来影响。一般来说，前端HTML文档的结构是否合理，外部资源是否进行了压缩合并，静态内容是否使用了CDN加速，服务端是否配置了负载均衡，是否采取了缓存策略，以及客户端带宽状况等，都会对网页的性能造成影响。

二、浏览器解析渲染HTML页面的过程

参考资料： 浏览器的工作原理

上面这篇文章会帮助我们了解浏览器解析和渲染HTML文档的过程。具体的可以参见另一篇文档： 《浏览器解析渲染HTML页面的过程》

这里对以下几点进行着重说明：

1. HTML 文档的解析和渲染是一个渐进的过程。为达到更好的用户体验，呈现引擎会力求尽快将内容显示在屏幕上。它不必等到整个 HTML 文档解析完毕，就会开始构建呈现树和设置布局。在不断接收和处理来自网络的其余内容的同时，呈现引擎会将部分内容解析并显示出来。
2. 浏览器的预解析机制。
3. HTML 文档的解析和渲染过程中，外部样式表和脚本顺序执行、并发加载。

JS 脚本会阻塞 HTML 文档的解析，包括 DOM 树的构建和渲染树的构建；CSS 样式表会阻塞渲染树的构建，但 DOM 树依然继续构建（除非遇到 script 标签且 css 文件此时仍未加载完成），但不会渲染绘制到页面上。
在 HTML 文档的解析过程中，解析器遇到 <script> 标记时会立即解析并执行脚本，HTML 文档的解析将被阻塞，直到脚本执行完毕。如果脚本是外部的，那么解析过程会停止，直到从网络抓取资源并解析和执行完成后，再继续解析后续内容。
但无论是哪种情况导致的阻塞，该加载的外部资源还是会加载，例如外部脚本、样式表和图片。HTML 文档的解析可能会被阻塞，但外部资源的加载不会被阻塞。

三、浏览器并发连接数

Chrome: Browser only allows six TCP connections per origin on HTTP 1.

Chrome 浏览器的并发连接数为 6 个，超过限制数目的请求会被阻塞。

参见《浏览器解析渲染HTML页面的过程》的 “CSS 和 JS 的处理顺序和阻塞分析”一节。

四、Performance API

能够实现对网页性能的监控，主要是依靠 Performance API。

1. 《JavaScript 标准参考教程（alpha）》
2. MDN文档

重点查看以下方法：

1. Performance.timing
2. Performance.getEntries()
3. Performance.getEntriesByType()
4. Performance.now()

尤其是第一项，可以在控制台输出查看一下。

五、localStorage

1. Web Storage API
2. calculating-usage-of-localstorage-space

localStorage 的基本概念和使用方法可以参见上面的链接，包括测试本地存储是否已被填充、从存储中获取值、在存储中设置值、删除数据记录、浏览器兼容性、通过 StorageEvent 响应存储的变化等。

localStorage 的大小限制
浏览器对于 localStorage 存储数据的大小有限制，一般为 5M/域，因此开发时应该注意控制存数数据的大小，并定期清除过期和无用的数据。

当 localStorage 存储超限的时候，会报 Uncaught QuotaExceededError 错误。

// 当存储数据大小超过限制时，会报以下错误：
// `YourStorageKey` 指报错时存放数据的键值
Uncaught QuotaExceededError: Failed to set the 'YourStorageKey' property on 'Storage': Setting the value of 'YourStorageKey' exceeded the quota.

我们可以使用 try-catch 对数据存储操作进行包裹，当捕获数据超限的错误时，我们可以先清除旧数据再进行存储。

// 存储 xhr 信息到客户端 localStorage 中
wp.setItemToLocalStorage = function (xhr) {
    var arrayObjectLocal = this.getItemFromLocalStorage();
    if (arrayObjectLocal && Array.isArray(arrayObjectLocal)) {
        arrayObjectLocal.push(xhr);
        try {
            localStorage.setItem('webperformance', JSON.stringify(arrayObjectLocal));
        } catch (e) {
            if (e.name == 'QuotaExceededError') {
            // 如果 localStorage 超限, 移除我们设置的数据, 不再存储
            localStorage.removeItem('webperformance');
            }
        }
    }
};

数据格式
localStorage 只能存储字符串类型的数据，不能够直接存储数组或对象。但我们可以通过 JSON.stringify() 和 JSON.parse() 实现对数组和对象数据类型的存取.

localStorage.setItem('webperformance', JSON.stringify(arrayObjectLocal));
var arrayObjectLocal = JSON.parse(localStorage.getItem('webperformance')) || [];

网页性能指标

一、页面性能指标

1. 白屏时间
   读取页面首字节时间（ttfb - Time To First Byte），可以理解为用户拿到页面资源占用的时间。
   浏览器对html文档的解析和渲染是一个渐进的过程，一般在拿到首字节之后便会有内容绘制在页面上，正常网络状态下基本上白屏时间很短。
2. 资源加载
   浏览器在接收到服务器返回的 html 文档数据之后，会起一系列的线程去请求文档解析中遇到的各种资源，js脚本、CSS样式表、图片，以及发起异步请求。我们这里的资源认为是 js/css/图片，后面统计资源加载情况时，会统计这些资源的文件大小、文件数量、总的加载用时。ajax异步请求我们会另外进行统计。
3. 用户可操作时间
   在查阅相关资料时，会看到用户等待页面时间、用户可操作时间等概念，不同资料和文章的定义也不同，这里我们认为用户可操作时间就是用户可以进行页面操作的时间，此时 html 文档解析完成（domContentLoadedEventEnd）。另一种用户等待页面的时间，一般是按照页面加载完成的时间来统计（loadEventEnd）。但在我们这次的前端性能监控方案中，并不将其作为主要的监控指标。
4. 首屏渲染时间
   首屏时间的统计比较复杂，因为涉及图片资源的下载及异步请求等因素。有些资料统计中不计算图片的下载时间，但我们认为既然是首屏的展示，应当包括图片加载的完成。判断首屏图片加载完成的方法，这里不再详述，可以查阅相关文章。我们这次的前端性能分析方案中，并没有涉及到图片，而是关注页面初始化过程中的异步请求。

二、ajax 请求性能指标

1. 服务器处理时间
2. 客户端下载时间
3. 接口名称
4. 下载速度
5. 页面路径及id
6. 传输大小

代码说明

一、模块构成

web-performance.js

1. 兼容 CommonJS AMD CMD 及 原生JS
2. 无第三方依赖（比如jquery）

3. 主要提供以下方法：

   var wp = {
       generateGUID, // 生成当前页面唯一 id
       showInfoOnPage, // 在当前页面显示相关信息
       recordAjaxInfo, // 记录页面初始化完成前的 ajax 信息, 或者打印初始化完成后的 ajax 信息到页面
       sendPerformanceInfoToServer, // 上报服务器
       setItemToLocalStorage, // 存储 xhr 信息到客户端 localStorage 中
       getItemFromLocalStorage, // 获取客户端存储的 xhr 信息, 返回数组形式
       getDesignatedXHRByRequestId, // 通过 requestId 获取特定 xhr 信息
       getPageInitCompletedInfo, // 获取页面初始化完成的耗时信息
       // ......
   };

二、与业务代码的结合

我们实现了性能监控模块 web-performance.js，那么怎么在应用中使用？
如果只是实现对页面加载信息的分析，那么在业务代码中只需要引入这个模块，然后在业务代码中页面初始化完成时调用模块的方法即可。但是，如果要实现对每一个ajax请求的统计分析，就需要配合封装 ajax 文件。

1. 封装的 ajax 文件中引入性能监控模块

   var WebPerformance = require('./web-performance'); // 网页性能监控模块
   var requestIdentifier = {};

2. 每个请求生成唯一标识

   triggerService: function (serviceName, input, success, error, ajaxParams) {
       var request = ajaxRequest.ajax.buildServiceRequest(serviceName, input, success, error, ajaxParams);
   
       // 生成此次 ajax 请求唯一标识
       var requestId = requestIdentifier[serviceName] = WebPerformance.generateGUID();
       request.url = URL + requestId;
       return ajaxRequest.ajax(request, serviceName, requestId);
     }
   
   ajaxRequest.ajax = function (userOptions, serviceName, requestId) {
       userOptions = userOptions || {};
       var options = $.extend({}, ajaxRequest.ajax.defaultOpts, userOptions);
       options.success = undefined;
       options.error = undefined;
   
       return $.Deferred(function ($dfd) {
         $.ajax(options)
           .done(function (result, textStatus, jqXHR) {
             // 每次请求都会有唯一id，请求返回时比对id是否变化 
             if (requestId === requestIdentifier[serviceName]) {
               ajaxRequest.ajax.handleResponse(result, $dfd, jqXHR, userOptions, serviceName, requestId);
             }
           })
           .fail(function (jqXHR, textStatus, errorThrown) {
             if (requestId === requestIdentifier[serviceName]) {
               //jqXHR.status
               $dfd.reject.apply(this, arguments);
               userOptions.error.apply(this, arguments);
             }
           });
       });
     };

3. 在成功的回调中对xhr信息进行客户端存储等操作

   try {
       // 将此次请求的信息存储到客户端的 localStorage
       var headers = jqXHR.getAllResponseHeaders();
       var xhr = WebPerformance.getDesignatedXHRByRequestId(requestId, serviceName, headers);
       WebPerformance.setItemToLocalStorage(xhr);
       WebPerformance.recordAjaxInfo(xhr); // 要在成功的回调之前调用
   } catch (e) {throw e}

具体实现逻辑参见源码 - Web 前端性能分析（二）。

三、接口调用

web-performance.js 模块本身简单封装了原生 ajax ，后台提供了上报服务器的接口。这里的请求不能使用业务代码中封装的 ajax 文件，因为不能将上报性能信息的请求也统计在内。

// 页面信息上报参数模型
{
  name: Page,
  data: {
    "pageLoad": 991,
    "ttfb": 46,
    "domReady": 985,
    "onload": 1,
    "tcpConnect": 0,
    "startTime": 1531209356934,
    "pageInitCompleted": 1676.6999999963446,
    "pageUrl": "/xxx/index.html",
    "pageId": "df393fc4-390b-4661-b4ea-002237958051"
  }
}

// ajax请求上报参数模型
{
  name: Ajax,
  data: [{
    "contentDownload": 7.400000002235174,
    "ttfb": 60.70000000181608,
    "resourceName": "http://localhost/xxx/AjaxHandler.aspx?r=587cf1dd-b8dc-4669-84eb-543c4d57f00b",
    "entryType": "resource",
    "initiatorType": "xmlhttprequest",
    "duration": 68.7000000034459,
    "connectStart": 924.7999999934109,
    "requestId": "587cf1dd-b8dc-4669-84eb-543c4d57f00b",
    "serviceName": "GetSearchHotKeys",
    "pageId": "df393fc4-390b-4661-b4ea-002237958051",
    "pageUrl": "/xxx/index.html",
    "transferSize": "669",
    "startTime": 1531209357858,
    "downloadSpeed": 88.28652868954921
  }]
}

业务代码中调用：

// 上报服务器页面性能信息
try {
    WebPerformance.sendPerformanceInfoToServer();
} catch (e) {throw e;}

其他操作都已经封装在了 ajax文件 和 web-performance.js 文件中了，比如将 ajax 请求记录在客户端、生成前端调试页面等。

四、开发调试页面

为了便于调试和开发，我们在模块中提供了一个调试页面，可以通过在控制台中输入命令控制这个调试页面的开启和关闭。

页面初始化完成时，会将页面信息和初始化调用的请求信息展示出来：

在页面初始化完成之后，每次ajax请求的信息都会实时添加到调试页面，就像这样：

在控制台控制调试页面的开闭：

问题和思考

1. 传输大小
   performance.timing.transferSize 可以用来获取传输大小，但是公司产品WebKit版本不支持，所以前端对于css、js文件的大小暂时没办法提供。而对于ajax的传输内容大小，我们使用 Content-Length 的值。
2. 如何准确定义页面初始化完成的时机
   对于图片加载，我们可以通过 window 对象的 load 事件获取图片等外部资源加载完成的时间，也可以通过一些方法去获取首屏图片加载完成的时间，但是对于页面初始化过程中发起的多个异步请求完成时机的判断，会相对麻烦一些，主要是由于异步请求返回结果的先后顺序不定。

3. 我们设想在页面初始化完成的时候，在业务代码中调用方法上报信息到服务器，那么怎么确定页面初始化完成了？
   比如页面初始化完成应当包括 关键词查询接口返回、表格内数据查询接口返回这两个ajax请求完成，此时我们才认为页面初始化完成了（对于这个页面来讲，也可以说是首屏加载完成）。但是异步请求的返回顺序是不定的，也许查询关键字的请求先返回，也许查询表格数据的接口先返回，如果需要准确定义初始化完成的时机，就要判断是否所有初始化涉及的请求均已成功，特别是有些页面的初始加载可能会调用很多个ajax请求，这就不太好确定什么时候是初始化完成的时候。

   对于试验项目中的这个页面，因为初始化只涉及两个请求，相对来说作为主体内容的表格数据是主要的请求，而关键词的请求相对来说不太重要，因此我们可以粗略的将请求表格数据成功的时间，认为是页面初始化完成的时机，我们可以在请求表格数据的成功回调中进行信息的上报。

   但是这样显然是不够精确的，并且这个页面的初始化过程涉及的异步请求比较少，但是如果是请求数量比较多的情况呢？

   我们的解决方案是：$.when() + $.Deferred()

   我们使用变量接收初始化过程中调用的 ajax 请求所返回的 jqXHR 对象，在 jQuery1.5 版本之后，$.ajax() 方法返回的 jqXHR 对象都是 Deferred 对象，因此我们可以将这些 jqXHR 对象放在 $.when() 方法中，为它们指定回调函数（即上报服务器的操作），这样就可以保证页面初始化时机的准确性。

   代码示例如下：

   // 页面初始化
   $(function () {
     // 表格初始化
     var dtd = tableSection.showTable();
     // 设置关键字
     var dtd2 = integratedQuery.setHotKeyWords();
     $.when(dtd, dtd2)
       .done(function () {
         // 将页面性能数据上报服务器
         try {
           WebPerformance.sendPerformanceInfoToServer();
         } catch (e) {
           throw e;
         }
       })
       .fail(function () {
         console.log('fail: send performance info')
       });
       // 其他初始化操作
       // ...
    });