10分钟彻底搞懂前端页面性能监控

  • 时间:
  • 浏览:1
  • 来源:大发5分排列3_大发5分排列3官方

用户看得人页面展示出现有三个 多元素的时间。全都人认为白屏时间是页面返回的首字节时间,但可是我 确实太久精确,将会头部资源还没加载完毕,页面也是白屏。

从W3C Navigation Timing Level 2 的方案设计,可不上能直接采用 domInteractive - fetchStart ,此时页面资源加载完成,即将进入渲染环节。

主文档返回第有三个 多字节的时间,是页面加载性能比较重要的指标。对用户来说一般无感知,对于开发者来说,则代表访问网络后端的整体响应耗时。

选用统计起始点 (navigationStart vs fetchStart )

首屏时间

页面性能统计的起始点时间,应该是用户输入网址回车后刚开始守候的时间。有三个 多是通过navigationStart获取,为宜在URL输入栏回车将会页面按F5刷新的时间点;另外有三个 多是通过 fetchStart,为宜浏览器准备好使用 HTTP 请求获取文档的时间。

Navigation Timing API可不上能监控大次责前端页面的性能。但随着SPA模式的盛行,类似于于vue,reactjs等框架的普及,页面内容渲染的时机被改变了,W3C标准无法完正满足可是我 的监控意义。

页面性能对业务指标的影响 https://www.thinkwithgoogle.com/marketing-resources/data-measurement/mobile-page-speed-new-industry-benchmarks/

以下给出统计页面性能指标的方式 。

首字节

白屏时间

幸运的是,目前W3C关于首屏统计将会进入了提议阶段,以Chrome为首的浏览器正在打造更能代表用户使用体验的FP、FCP、FMP指标,之后 逐步开放API。

为了帮助开发者更好地衡量和改进前端页面性能,W3C性能小组引入了 Navigation Timing API ,实现了自动、精准的页面性能打点;开发者可不上能通过 window.performance 属性获取。

本文首发于知乎《10分钟彻底背熟前端页面性能监控》,搬运转载请注明出处。

使用顶端的指标,亲戚亲戚朋友 可不上能计算一点重要的指标,如首字节的时间,页面加载时间,dns查找以及连接与非 安全。亲戚亲戚朋友 把 Navigation Timing API 提供的指标做下归类,按照从上到下的时间流,右边的时刻标记了每个指标从哪里刚开始计算到哪里截止,比如,跳转时间 redirect 由 redirectEnd - redirectStart 计算得到,一点的类推。

当浏览器支持sendBeacon方式 ,优先使用该方式 ,使用img方式 降级上报。

具备一定意义上的指标可不上能使用,domContentLoadedEventEnd - fetchStart,甚至使用loadEventStart - fetchStart,此时页面DOM树将会解析完成之后 显示内容。

首屏时间是指页面第一屏所有资源完正展示的时间。这是有三个 多对用户来说非常直接的体验指标,之后 对于前端却是有三个 多非常难以统计衡量的指标。

大次责现代浏览器都支持 navigator.sendBeacon方式 。这种方式 可不上能用来发送一点统计和诊断的一定量数据,怪怪的适合上报统计的场景。

前端页面性能是有三个 多非常核心的用户体验指标。本文给亲戚亲戚朋友 分享UC出品的 岳鹰全景监控平台 怎样才能设计有三个 多通用、低侵入性、自动上报的页面性能监控方案。主要采用的是Navigation Timing API以及sendBeacon等方式 。

上图是 Level 1 的规范,2012 年底进入候选建议阶段,至今仍在日常使用中;之后 在W3C的议程上,它将会功成身退,让位给了精度更高,功能更强大,层次更分明的 Level 2(处置模型如下图)。比如独立划分出来的 Resource Timing,使得亲戚亲戚朋友 可不上能获取具体资源的完正耗时信息。

从开发者实际分析使用的场景,浏览器重定向、卸载页面的耗时对页面加载分析并无太久作用;通常建议使用 fetchStart 作为统计起始点。

全都亲戚亲戚朋友 可不上能有三个 多性能监控系统,持续监控和预警页面性能的情況,之后 在发现瓶颈的可是我 指导优化工作。

下图是W3C第一版的 Navigation Timing 的处置模型。从当前浏览器窗口卸载旧页面刚开始,到新页面加载完成,整个过程一共被切分为 9 个小块:提示卸载旧文档、重定向/卸载、应用缓存、DNS 解析、TCP 握手、HTTP 请求处置、HTTP 响应处置、DOM 处置、文档装载完成。每个小块的首尾、顶端做事件分界,取 Unix 时间戳,两两事件之间计算时间差,从而获取顶端过程的耗时(精确到毫秒级别)。

测量好时间后,就可不上能将数据发送给服务端。页面性能统计数据对丢失率要求比较低,且性能统计应该在尽量不影响主流程的逻辑和页面性能的前提下进行。

确实页面性能怪怪的要,之后 在实际使用中,页面性能差的情況太久少见。首先,在产品的迭代演进过程中,页面性能将会会被忽略,性能随着版本迭代而有所衰减;其次,性能优化是一项复杂而挑战的事情,可不上能明确的优化方向和具体的优化手段可不上能快速落地取效。

navigation-timing-2 https://www.w3.org/TR/navigation-timing-2/

有三个 多页面性能差说说会大大影响用户体验。用户打开页面守候的太久,将会会直接关掉页面,甚至就不再使用了,这种情況在移动端更加明显,移动端用户对页面响应延迟容忍度很低。

Navigation API指南 https://s0developer0mozilla0org.icopy.site/en-US/docs/Web/Performance/Navigation_and_resource_timings

以用户为中心的性能指标 https://developers.google.com/web/fundamentals/performance/user-centric-performance-metrics?hl=zh-cn

相对来说具备「白屏时间」统计意义的指标,可不上能取 domLoading - fetchStart,此时页面刚开始解析DOM树,页面渲染的第有三个 多元素也会放慢出现。