摘要:记录使用遇到的问题本文中指的是。上线了以后拿到的首批数据中,后端时间计算出来竟然有负值,尤其在设备下,苦苦寻找原因,终于发现问题所在。如果事件没有触发,那么该接口就返回文档触发事件结束后的时间。
记录使用Performance API遇到的问题
本文中Performance API指的是Navigation Timing API。这并不是一篇Navigation Timing API的介绍文章,而是我在使用中遇到的问题。
我在开发中遇到Navigation Timing API中的connectStart等时间节点并不是标准时间戳,而是0或者一个很小的数值,导致指标数据计算出错,尤其是IOS设备。原因如下:
IOS设备通过浏览器的前进后退按钮进入的页面,Navigation Timing API数据中connectStart,responseEnd等数据可能为0或者是一个比较小的数值,并不是对应时间点的时间戳。究其原因,IOS设备通过缓存读取页面时,Navigation Timing的计算与安卓实现不一致。
如果你还想了解下Navigation Timing API,可以继续往下看
Navigation Timing APINavigation Timing API中包含全部的页面加载中关键节点的时间,例如navigationStart,connectEnd,responseEnd等时间。
具体的相关API可以去MDN查看,
浏览器支持程度也非常不错,移动端IOS9及以上,Android4及以上都支持,桌面端IE9也都支持。
DNS时间 = domainLookupEnd - domainLookupStart
TCP时间 = connectEnd - connectStart
后端时间 = responseEnd - connectEnd
白屏时间 = domInteractive - navigationStart
整屏时间 = loadEventEnd - navigationStart
解析dom树耗时 = domComplete - domInteractive
request请求耗时 = responseEnd - responseStart
我们团队就是按照如上指标来做的各个时间的统计,做了各种测试,线下数据都没什么问题。上线了以后拿到的首批数据中,后端时间计算出来竟然有负值,尤其在IOS设备下,苦苦寻找原因,终于发现问题所在。
IOS设备通过浏览器的前进后退按钮进入的页面,Navigation Timing API数据中connectStart,responseEnd等数据可能为0或者是一个比较小的数值,并不是对应时间点的时间戳。
关于首屏时间的定义根据Navigation Timing API的时间,是没有办法计算首屏时间的,首屏时间也并没有严格的定义,我们团队采用的首屏时间如下
首屏时间 = (dom解析完毕 && 所有首屏图片加载完毕 )- navigationStart
标准属性 | 含义 |
---|---|
navigationStart | 准备加载新页面的起始时间 |
redirectStart | 如果发生了HTTP重定向,并且从导航开始,中间的每次重定向,都和当前文档同域的话,就返回开始重定向的timing.fetchStart的值。其他情况,则返回0 |
redirectEnd | 如果发生了HTTP重定向,并且从导航开始,中间的每次重定向,都和当前文档同域的话,就返回最后一次重定向,接收到最后一个字节数据后的那个时间.其他情况则返回0 |
fetchStart | 如果一个新的资源获取被发起,则 fetchStart必须返回用户代理开始检查其相关缓存的那个时间,其他情况则返回开始获取该资源的时间 |
domainLookupStart | 返回用户代理对当前文档所属域进行DNS查询开始的时间。如果此请求没有DNS查询过程,如长连接,资源cache,甚至是本地资源等。 那么就返回 fetchStart的值 |
domainLookupEnd | 返回用户代理对结束对当前文档所属域进行DNS查询的时间。如果此请求没有DNS查询过程,如长连接,资源cache,甚至是本地资源等。那么就返回 fetchStart的值 |
connectStart | 返回用户代理向服务器服务器请求文档,开始建立连接的那个时间,如果此连接是一个长连接,又或者直接从缓存中获取资源(即没有与服务器建立连接)。则返回domainLookupEnd的值 |
(secureConnectionStart) | 可选特性。用户代理如果没有对应的东东,就要把这个设置为undefined。如果有这个东东,并且是HTTPS协议,那么就要返回开始SSL握手的那个时间。 如果不是HTTPS, 那么就返回0 |
connectEnd | 返回用户代理向服务器服务器请求文档,建立连接成功后的那个时间,如果此连接是一个长连接,又或者直接从缓存中获取资源(即没有与服务器建立连接)。则返回domainLookupEnd的值 |
requestStart | 返回从服务器、缓存、本地资源等,开始请求文档的时间 |
responseStart | 返回用户代理从服务器、缓存、本地资源中,接收到第一个字节数据的时间 |
responseEnd | 返回用户代理接收到最后一个字符的时间,和当前连接被关闭的时间中,更早的那个。同样,文档可能来自服务器、缓存、或本地资源 |
domLoading | 返回用户代理把其文档的 "current document readiness" 设置为 "loading"的时候 |
domInteractive | 返回用户代理把其文档的 "current document readiness" 设置为 "interactive"的时候. |
domContentLoadedEventStart | 返回文档发生 DOMContentLoaded事件的时间 |
domContentLoadedEventEnd | 文档的DOMContentLoaded 事件的结束时间 |
domComplete | 返回用户代理把其文档的 "current document readiness" 设置为 "complete"的时候 |
loadEventStart | 文档触发load事件的时间。如果load事件没有触发,那么该接口就返回0 |
loadEventEnd | 文档触发load事件结束后的时间。如果load事件没有触发,那么该接口就返回0 |
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/89509.html
摘要:回过头来发现,我们的项目,虽然在服务端层面做好了日志和性能统计,但在前端对异常的监控和性能的统计。对于前端的性能与异常上报的可行性探索是有必要的。这是我们页面加载性能优化需求中主要上报的相关信息。 概述 对于后台开发来说,记录日志是一种非常常见的开发习惯,通常我们会使用try...catch代码块来主动捕获错误、对于每次接口调用,也会记录下每次接口调用的时间消耗,以便我们监控服务器接口...
今天来给大家介绍下前端监控中一个特定指标的获取算法,有人会问,为啥就单单讲一个指标?这是因为,目前大部分的指标,比如白屏时间,dom加载时间等等,都能通过现代浏览器提供的各种api去进行较为精确的获取,而今天讲的这个指标,以往获取他的方式只能是通过逻辑埋点去获取它的值,因此在做一些前端监控时,需要根据业务需要去改变页面对这个值的埋点方式,会比较繁琐,恰巧最近刚刚好在做一些前端监控相关的项目,遇到这...
摘要:前端渲染过程的二三事本文不会介绍整个前端渲染过程的步骤,只是记录最近阅读的文章的些许思考和感悟。那么现在我们可以明白这个问题的关键所在了,因为在大部分页面中是拥有的,而由于其解析顺序,那么在事件之前必定已经成功构造树。 前端渲染过程的二三事 本文不会介绍整个前端渲染过程的步骤,只是记录最近阅读的文章的些许思考和感悟。(文章地址一(系列),文章地址二) 希望大家在阅读这篇文章之前能将上述...
摘要:参考链接初探监控网页与程序性能使用简洁的测试网页加载速度前端性能统计前端性能监控起步使用性能快速分析前端性能通过以上几篇文章,可以对前端性能相关的概念和有一个整体的认识。但在我们这次的前端性能监控方案中,并不将其作为主要的监控指标。 参考链接 初探 performance – 监控网页与程序性能 使用简洁的 Navigation Timing API 测试网页加载速度 前端性能统计 ...
摘要:前言最近有幸参与一个前端质量监控类项目的重构,算是个人初次接触到前端质量监控相关的知识,对于其中的性能统计部分很感兴趣,查询资料之后写了文章,作为个人学习记录,如有错误,敬请斧正页面整体性能通过浏览器提供的方法,我们能够得到网页每个处理阶段 前言 最近有幸参与一个前端质量监控类项目的重构,算是个人初次接触到前端质量监控相关的知识,对于其中的性能统计部分很感兴趣,查询资料之后写了文章,作...
阅读 3663·2021-08-10 09:42
阅读 546·2019-08-30 15:55
阅读 850·2019-08-30 15:54
阅读 3042·2019-08-30 13:45
阅读 528·2019-08-29 16:23
阅读 1958·2019-08-29 16:23
阅读 960·2019-08-29 15:18
阅读 2236·2019-08-29 12:57