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

  • 时间:
  • 浏览:0
  • 来源:uu快3苹果版_uu快3单双_套路

白屏时间

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

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

当浏览器支持sendBeacon法律土妙招,优先使用该法律土妙招,使用img法律土妙招降级上报。

具备一定意义上的指标前要使用,domContentLoadedEventEnd - fetchStart,甚至使用loadEventStart - fetchStart,此时页面DOM树意味解析完成否则显示内容。

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

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

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

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

用户看一遍页面展示经常出现有一个 元素的时间。你你这个人认为白屏时间是页面返回的首字节时间,但原本有两种暂且精确,意味头部资源还没加载完毕,页面也是白屏。

相对来说具备「白屏时间」统计意义的指标,前要取 domLoading - fetchStart,此时页面结速解析DOM树,页面渲染的第有一个 元素也会越来太快了 了 经常出现。

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

有两种页面性能很糙要,否则在实际使用中,页面性能差的具体情况暂且少见。首先,在产品的迭代演进过程中,页面性能意味会被忽略,性能随着版本迭代而有所衰减;其次,性能优化是一项错综复杂而挑战的事情,前要明确的优化方向和具体的优化手段不可不后能 快速落地取效。

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

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

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

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

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

大部分现代浏览器都支持 navigator.sendBeacon法律土妙招。你你这个法律土妙招前要用来发送你你这个统计和诊断的多量数据,很糙适合上报统计的场景。

首屏时间

前端页面性能是有一个 非常核心的用户体验指标。本文给我门都都分享UC出品的 岳鹰全景监控平台 要怎样设计有一个 通用、低侵入性、自动上报的页面性能监控方案。主要采用的是Navigation Timing API以及sendBeacon等法律土妙招。

Navigation Timing API前要监控大部分前端页面的性能。但随着SPA模式的盛行,你这个vue,reactjs等框架的普及,页面内容渲染的时机被改变了,W3C标准无法全部满足原本的监控意义。

你你这个我门都都前要有一个 性能监控系统,持续监控和预警页面性能的具体情况,否则在发现瓶颈的然后指导优化工作。

页面性能统计的起始点时间,应该是用户输入网址回车后结速等待时间的时间。有一个 是通过navigationStart获取,为宜在URL输入栏回车意味页面按F5刷新的时间点;另外有一个 是通过 fetchStart,为宜浏览器准备好使用 HTTP 请求获取文档的时间。

上图是 Level 1 的规范,2012 年底进入候选建议阶段,至今仍在日常使用中;否则在W3C的议程上,它意味功成身退,让位给了精度更高,功能更强大,层次更分明的 Level 2(处理模型如下图)。比如独立划分出来的 Resource Timing,使得我门都都前要获取具体资源的全部耗时信息。

有一个 页面性能差说说会大大影响用户体验。用户打开页面等待时间的那末 来那末多,意味会直接关掉页面,甚至就不再使用了,你你这个具体情况在移动端更加明显,移动端用户对页面响应延迟容忍度很低。

使用上方的指标,我门都都前要计算你你这个重要的指标,如首字节的时间,页面加载时间,dns查找以及连接与非 安全。我门都都把 Navigation Timing API 提供的指标做下归类,按照从上到下的时间流,右边的时刻标记了每个指标从哪里结速计算到哪里截止,比如,跳转时间 redirect 由 redirectEnd - redirectStart 计算得到,你你这个的类推。

以下给出统计页面性能指标的法律土妙招。

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

首字节

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