前端性能监控与优化

1.   为什么要做性能监控？

提高客户体验。客户体验（UserExperience，通称UE/UX）是客户在应用商品全过程中创建起來的一种纯主观性体会。可是针对一个定义确立的客户人群而言，其客户体验的关联性是可以经过优良设计方案试验来了解到。对于用户来说，产品或者网站好不好用，加载速度是否能满足日益削减的耐心，都关系着用户量与用户粘性。

国外曾经做过一个很经典的统计，前端性能与公司收入正相关。究其原因，前端性能会直接影响用户体验，而用户量与用户粘性与公司利益有着直接关系。再者，现有很多产品都做过大大小小的优化，用户的容忍度愈发降低，设想一个网站或者系统在3秒之内还达不到用户可操作状态，大多数用户都会选择kill掉网页或者应用。

数据来源：http://www.slideshare.net/bitcurrent/impact-of-web-latency-on-conversion-rateshttp://stevesouders.com/docs/jsdayit-20110511.pptx

随着产品不断迭代，业务日趋复杂，前端优化，并不是简单的几条雅虎军规就可以搞定的。需要对产品的前端各种性能数据进行分析，从而得到更加详细的性能分析数据与更细粒度的优化方案。

2.   前端监控指标

了解了前端性能监控的必要性之后，需要分析下前端统计指标。统计属于海量数据的范畴，产品分析做的越细，所产生的数据量越大，比如我要做一个用户点击热点的话，就需要收集用户所有的点击数据，这个可能是pv的数十倍；另一方面，海量统计应该是脱离业务本身的，用户可定制化打点需求，以满足不同业务的变化。

下面说说前端监控的基本知识。了解了基本概念，我们便可以确定我们到底需要什么数据，总体上分为四部分。

（1）访问指标。

PV/UV：最基础的 PV（页面访问数量）、UV（独立访问用户数量）

页面来源：页面的 refer，可以定位页面的入口

操作系统：了解用户的 OS 状况，帮助分析用户群体的特征，特别是移动端，iOS 和 Android 的分布就更有意义了

浏览器：可以统计到各种浏览器的占比

分辨率：对页面设计提供参考，特别是响应式设计

地域分布：访问用户在地理位置上的分布，可以针对不同地域做运营、活动等

网络类型：wifi/3G/2G，为产品是否需要适配不同网络环境做决策

访问时段：掌握用户访问时间的分布，引导消峰填谷、节省带宽

停留时长：判断页面内容是否具有吸引力，对于需要长时间阅读的页面比较有意义

到达深度：和停留时长类似，例如百度百科，用户浏览时的页面到达深度直接反映词条的质量

（2）点击指标。

页面总点击量

按钮或者导航点击量

点击时间：用户的所有点击行为，在时间上的分布，反映了用户点击操作的习惯

首次点击时间：同上，但是只统计用户的第一次点击，如果该时间偏大，是否就表明页面很卡导致用户长时间不能点击呢？

点击热力图：根据用户点击的位置，我们可以画出整个页面的点击热力图，可以很直观的了解到页面的热点区域

（3）性能指标

白屏时间：用户从打开页面开始到页面开始有东西呈现为止，这过程中占用的时间就是白屏时间

首屏时间：用户浏览器首屏内所有内容都呈现出来所花费的时间

用户可操作时间：用户可以进行正常的点击、输入等操作

页面总下载时间：页面所有资源都加载完成并呈现出来所花的时间，即页面 onload 的时间

自定义的时间点：对于开发人员来说，完全可以自定义一些时间点，例如：某个组件 init 完成的时间、某个重要模块加载的时间等等

（4）异常指标。

异常的提示信息：这是识别一个异常的最重要依据，如：’e.src’为空或不是对象

JS 文件名

异常所在行

发生异常的浏览器

堆栈信息：必要的时候需要函数调用的堆栈信息，但是注意堆栈信息可能会比较大，需要截取。

3.   商业运营平台前端监控现状

业界已有工具和方案：

由于收集数据的方式和目标不一样，前端性能监控主要分为非侵入式式和侵入式两种。

类型	优点	缺点	示例
非侵入式	指标齐全、客户端主动监测、竞品监控	无法知道性能影响用户数、采样少容易失真、无法检测复杂应用与细分功能	Yslow、Pagespeed、Dynatrace、Fiddler、webpagetest（线上）、gtmetrix（线上）
侵入式	真实海量用户数据、能监控复杂应用与业务功能、用户点击与区域渲染	需插入脚本统计、网络指标不全、无法监控竞品	Navigation Timing API、Resource Timing API

非侵入式

（1）pagespeed

PageSpeedInsights 的Chrome扩展是由谷歌官方开发的一款可以分析页面载入的各个方面，包括资源、网络、DOM以及时间线等等信息的插件，安装以后会附加到Developer Tools(开发者工具)中。所以安装之后，大家只需要在页面上点击右键——审查元素，就可以在最后一个标签中看到 PageSpeed 了。

使用方法：点击“分析”，稍等一会儿就会给出分析结果。

（2）YSlow

YSlow可以对网站的页面进行分析，并告诉你为了提高网站性能，如何基于某些规则而进行优化。Yslow 支持chrome插件和firfox插件。YSlow可以分析任何网站，并为每一个规则产生一个整体报告，如果页面可以进行优化，则YSlow会列出具体的修改意见。

侵入式

（1）NavigationTiming API

监测主文档加载速度，该API提供一种简单的获取页面被导航或被加载时的时间及相关信息的方法。目前为止，在Internet Explorer 9、Google Chrome以及Firefox nightly Builds浏览器中对该API提供支持。

timing的整体结构如下图所示：

可以使用Navigation.timing统计到的时间数据来计算一些页面性能指标，比如DNS查询耗时、白屏时间、domready等等。如下：

DNS查询耗时 =domainLookupEnd - domainLookupStart

TCP链接耗时 =connectEnd - connectStart

request请求耗时 =responseEnd - responseStart

解析dom树耗时 =domComplete - domInteractive

白屏时间 = domloadng -fetchStart

domready时间 =domContentLoadedEventEnd - fetchStart

onload时间 =loadEventEnd - fetchStart

（2）ResourceTiming API

可监测静态资源加载速度。

COP前端监控现状

在COP现有的产品中，埋点监控现状如下：

从使用平台来说分为以下三类：

第一类，使用公司内部成熟的平台如百度统计，dp。产品线有糯米crm，华佗，KA各crm系统等。

第二类，后端开发接口，前端请求定制化的接口。如盘古等。

第三类，后端统计接口访问日志。

第四类，无埋点。

从代码层面来说，前端埋点都为侵入式统计。

4.   个人思考

下面说说我自己对商业运营平台前端监控的一些想法。

第一，目前CRM部门的前端统计监控现状是比较混乱的。主要问题有以下几点：

（1）没有统一的埋点监控平台，新产品埋点调研成本高。

（2）成熟平台如dp学习成本高，接口人管理混乱。

（3）CRM通用业务参数，如UCID，运营单位，岗位等无法统计，需要额外接口，如糯米B端。

（4）CRM产品间无法横向，细粒度的做分析。

（5）大多数产品只做访问统计，而无性能监控。

第二，CRM部门前端监控真正的痛点是什么？

众所周知，CRM部门产品线多，项目众多，且绝大多数为CRM系统。CRM系统表格类页面居多，页面基本无图片，后台处理数据比较复杂，项目对浏览器要求低，一般要求兼容火狐和谷歌即可，用户可操作时间重要，而非首屏时间，首屏时间统计基本无意义。

主要矛盾为众多产品线需要快速全面监控的需求，与FE资源紧缺的矛盾。

真正限制CRM系统性能的瓶颈，其实是后台数据处理接口的返回时间。而接口性能监控与统计，恰恰是目前最为紧缺和必要的。

第三，解决方案

解决方案：开发统一的埋点监控平台，前端提供便于接入的JSSDK，埋点接口服务端采用适用于高并发的node.js。加入通用业务参数统计与性能统计，完善平台文档建设，并提供细粒度指标分析。整体架构如下如所示：

可能会有质疑，已经有dp那么成熟的平台，为何还要做COP前端监控平台？我觉得主要的原因有以下几点：

（1）可以快速的满足PM简单的PV，UV统计的需求，减少调研成本。

（2）可以将cop前端埋点监控统一化，规范化。

（3）通过AOP，对axios封装做到对所有较慢接口做监控统计。

（4）提供更具有业务意义的，更细粒度的，维度更多的图表分析与报表。

目前埋点平台第一版已上线，具备基本的埋点统计功能，LACRM客户模块已接入。预计今年年底完成所有开发任务以及文档建设。

第四，性能优化方面如何发力？

根据一个心理学研究，你的网站最少在速度上比别人快20%，才能让用户感觉到你的网站比别人的更快。这个速度说的不是整个页面的加载时间，而是开始加载渲染的时间，首次有效渲染时间（例如页面需要加载主要内容的时间），或者交互时间（指的是页面或者应用中主要的页面加载完成，并主备好与用户进行交互的时间）。

一些基本的优化点如雅虎军规等，当然是必须遵循的，除此之外，CRM部门前端优化还有以下发力点：

（1）启用CDN。目前的CRM系统静态资源基本没有走CDN的。

（2）准备好使用HTTP/2。HTTP2.0有多路复用等特点，而且HTTP2取代HTTP1.1只是时间问题，需要提前准备。

（3）考虑微优化和渐进启动。

（4）尝试网站渐进式增强体验(PWA)改造。PWA已经比较成熟，可以考虑应用在COP前端。

本文来源于：前端性能监控与优化-变化吧门户
特别声明：以上文章内容仅代表作者本人观点，不代表变化吧门户观点或立场。如有关于作品内容、版权或其它问题请于作品发表后的30日内与变化吧联系。