版权声明：此文章转载自微信公众号
如需转载请联系听云College团队成员小尹 邮箱：yinhy#tingyun.com
全样本用户访问体验监测与优化
2016-06-01 听云
1Web性能的精确测量
传统Web性能监测有多种方式。首先，最传统的是开启本地浏览器控制台、抓包工具进行监测，以瀑布图的形式看每个元素的响应时间。但更多的是做一些本地监测。其次，会用JavaScript的方式做DOM事件的监测。最后，是使用第三方主动式监测工具。在页面里面输入URL地址进行在线即时监测。听云也有主动式的监测产品，可以对页面性能、可用性进行监测。但依然是主动式抽样的方式，不能代表全部真实用户的访问情况。
我们会时刻关注Web监测的行业信息，找到更好的方式可以帮助用户了解页面在加载过程的情况，包括首屏、白屏时间等。随着Web性能的重要性越来越高，W3C标准化组织已经关注到了这点，并提供了相应的性能接口，比如Navigation、Resource等，可以获取页面加载过程中的指标，包括页面里面每个元素的加载指标。
在页面加载过程中，比如上一个页面关闭的动作会有一些事件报出来，在浏览器本地的缓存中也能判断到，到浏览器里面输入域名之后进行解析，建立连接，返回第一个字节的数据包，包括后续的剩余数据包。接下来开始进行解析动作，到最后解析完成，以及进行页面其它元素的加载，直到整个事件结束。一系列加载过程中的事件，浏览器都会报出来，而听云做的是将算出每个事件页面解析的耗时，以及用户实际访问这个页面的解析耗时。
通过本地也可以做验证，在浏览器命令行下面输入对应命令就可以把刚才所提到的对应接口每一个事件的指标打印出来，这样的话在本地做分析时，可以帮助我们做判断分析。
Navigation的接口获取数据很全，但也有一些问题，就在于分析一个页面的耗时不光是整体页面的加载，还会牵扯到页面里面的元素，比如说CSS、JS图片，渲染和网络下载时间都会影响最终用户在页面上的体验。这时我们就可以使用Resource这个接口，它可以统计到页面下所有的元素性能，每一个元素对应的事件都会进行记录，这样的话就可以画出页面加载过程中的元素瀑布图，分析每个元素在建连、内容下载上耗时情况，找到页面加载慢的具体原因。
听云Browser就是在上面的基础上做的具体技术实现，分为手动嵌码或自动嵌码方式。当浏览器Get请求的时候，服务器端会把带有嵌码的页面直接反馈给客户端，客户端加载页面过程中会获取本地对应的性能接口数据，回传到云平台的报表系统里面，以报表、指标的方式给用户展现在全国范围内各个地区页面加载的耗时情况，包括每一个性能指标加载的情况，都会在报表平台上进行展示，这是获取性能数据的来源。有别于主动式监测，是全样本的真实用户的访问监测。
分析具体报表，可以在全国范围内看到不同的地区真实访问用户、业务数据，得知哪些地区打开页面比较慢，以颜色的方式进行标识。分析不同的维度，像真实用户使用最多的浏览器终端有哪些，可以针对页面进行适配性的调试。比如说刚才提到了通过元素的接口可以获取到每个页面里，每个元素都可以进行页面的追踪，追踪到某一个元素某一段性能指标加载时间很长，可以帮助定位这个页面为什么慢，这样的话会提高听云Browser的效率。可以进行错误分析，监测到错误出在哪一行，对问题进行彻底的追踪。
2与主动式监测的对比
听云的产品最初从主动式监测开始，现在也可以做到被动式的全样本性能监测。很多用户会问主动式与被动式监测之间的区别是什么？这两类产品之间会不会有相互冲突和矛盾的地方？这里我们做了相应的对比。
先从监测方式来看，这两类监测的区别比较大。主动式监测会预先在全球范围内部署上监测探针网络，按照监测计划访问某个页面，或者播放某个流媒体，访问过程中的性能指标进行提取。而被动式监测完全不是这个概念，是通过在服务器端进行JS的嵌码就可以获取到全样本真实用户的访问性能。主动监测是抽样的，就像随机发放的调查问卷，这个用户不见得是真实的网站用户，但是他能代表这个区域对应年龄段的情况。被动式是真实的访问网站用户，我们也会更关注他们的访问体验。
在部署上会有一些区别，主动式监测部署非常灵活，只要知道一个URL地址经过简单配置，5分钟内就可以把性能数据收集上来。被动式监测则需要在页面中进行JS嵌码，需要有一定的部署和维护工作。
主动式是非侵入式的，不会对页面有任何性能消耗。被动式会有一些轻微的性能影响，主动式在浏览器支持上也是主流类型，被动式是只要产生过访问的浏览器类型都可以统计到。
网络性能监测上这两个产品也有明显的差异，主动式监测是这方面的强项，获取详细网络指标的同时还可以执行ping、traceroute、抓包等动作。被动式在这方面偏弱，仅能发现到达服务器的请求，比如说解析、建连失败。
通过以上分析可以看到这两种监测方式并不冲突，是可以相互结合的。主动式对可用性的监测是其一个重要特点，其它的产品没有办法完全做到可用性的监测，被动式的监测更多趋向于真实用户全样本监测。我们也可以通过应用场景上的对比进一步看下它们如何相互结合使用。
3全栈溯源
下面来介绍一下B/S架构下的溯源分析。通过在浏览器端进行数据的采集，服务器端部署监测探针，可以了解到页面总体加载时间中服务器响应时间的占比情况。这样的话，如果发现有个页面打开非常慢，可以直接追踪到Server端的问题，定位到这次访问缓慢是哪台服务器造成的，哪行代码问题造成的，帮助我们快速定位问题原因，这就是全栈溯源的核心价值。
在图上的四款产品已经实现了数据关联，全景应用性能可视化是听云的目标。客户端采集上来的数据可以与服务器端进行数据打通，这一点现在听云已经实现。终端有很多用户的入口，到服务器端可以具体定位是什么样的性能问题。
在具体演示上，发现某一个过程访问比较慢时，可以直接跳转到对应的Web应用过程，获取到相应的Server数据加载耗时时间，这样的话，就不会像以前去猜测到底是网络慢还是服务器慢。如上图通过对页面加载瀑布图的分析，发现首元素加载时间很长，可以直接在这里做一个慢应用追踪，追踪到Server端详细数据，最终可能是一段查询语句的问题都可以定位到，而这个过程只需要简单点几步，没有这个功能之前，排查时间可能会非常长。
4HTML5流媒体监测
目前HTML5页面已支持流媒体的播放，并且在移动端上使用也是越来越广泛。这部分的性能指标是通过调用相应接口获取视频在播放过程中的性能指标，比如缓冲耗时等，加载流媒体前期会获取流媒体的元数据耗时，如视频总时长等数据。还有首次缓冲耗时，指播放器第一次缓冲的加载耗时。获取性能指标的同时还可以统计到一些用户主动行为，比如拖动次数，指用户在观看这个视频过程中累计拖动视频的次数。
分享到微信
分享到微博
