Front-end performance optimization - performance indicators and tools

background

Performance is the backbone of websites and applications. With high website performance, the user experience will be better. At the same time, website speed is also a factor in search engine rankings. Therefore, good website performance directly affects our revenue indicators, so it is necessary to improve the performance of the website to obtain business benefits from a technical point of view.

Performance Optimization Metrics

The RAIL model is a set of user-centric performance models given by Google, which provides a structure that considers performance. The model breaks down the user experience into key actions (eg, click, scroll, load) and helps you define performance goals for each action. RAIL stands for:

  • Response: Response
  • Animation: animation
  • Idle: idle
  • Load: load

As shown below:image.png

response

Transitions initiated by user input are completed within 100 milliseconds, making the interaction feel instantaneous to the user.

  • To ensure a visible response within 100ms, user input events need to be processed within 50ms. This works for most inputs, such as clicking a button, toggling a form control, or starting an animation. However, this doesn't work with touch dragging or scrolling.
  • As paradoxical as it may sound, responding to user input instantly is not always the right thing to do. You can use this 100-millisecond window to perform other resource-intensive work, but be careful not to hinder the user. Should work in the background if possible.
  • Feel free to provide feedback on operations that take more than 50ms to complete.

50 ms or 100 ms?

The goal is to respond to input within 100ms, so why do we only have a 50ms budget? This is because there is often work that needs to be performed in addition to input processing, and that work takes up part of the time available for an acceptable input response. If an application executes work in the recommended 50ms chunks during idle time, this means that if an input occurs in one of these work chunks, it may queue up to 50ms. With this in mind, it is safe to assume that only the remaining 50 milliseconds are available for actual input processing. This effect is illustrated in the following diagram, which shows how input received during idle tasks is queued, reducing the available processing time:

image.png

animation

Generate a frame in 10ms

  • 在 10 毫秒或更短的时间内生成动画的每一帧。从技术上来讲,每帧的最大预算为 16 毫秒(1000 毫秒/每秒 60 帧≈16 毫秒),但是,浏览器需要大约 6 毫秒来渲染一帧,因此,准则为每帧 10 毫秒。
  • 目标为流畅的视觉效果。用户会注意到帧速率的变化。

空闲

最大限度增加空闲时间以提高页面在 50 毫秒内响应用户输入的几率。

加载

  • 根据用户的设备和网络能力优化相关的快速加载性能。目前,对于首次加载,在使用速度较慢 3G 连接的中端移动设备上,理想的目标是在 5 秒或更短的时间实现可交互
  • 对于后续加载,理想的目标是在 2 秒内加载页面。

通过APIs动态获取指标

如何通过api来获取网页的一些实时的指标数据,对我们做优化非常重要。一般情况,我们通过performance对象来获取常规的性能指标数据。 image.png 下面我们只介绍我们最常用的值

  • navigationStart: 浏览器处理当前网页的启动时间
  • fetchStart:浏览器发起HTTP读取文档的毫秒时间戳
  • domainLookupStart: 域名查询开始的时间戳
  • domainLookupEnd: 域名查询结束的时间戳
  • connectStart: HTTP请求开始向服务器发送的时间戳
  • connectEnd: 浏览器与服务器链接建立
  • requestStart: 浏览器向服务器发出HTTP请求的时间戳
  • responseStart: 浏览器从服务器收到第一个字节的时间戳
  • responseEnd: 浏览器从服务器收到最后一个字节的时间戳
  • domLoading: 浏览器开始解析网页DOM结构的时间
  • domInteractive: 网页DOM树创建完成,开始加载内嵌资源时间
  • domContentLoadEventStart: 网页domContentLoadd时间发生时的时间错
  • domContentLoadedEventEnd: 网页所有需要执行的脚本执行完成的时间, domReady的时间
  • loadEventStart: 当前网页load事件回调函数开始执行的时间戳
  • loadEventEnd: 当前网页load事件回调函数执行结束的时间戳
性能数据名称 描述 计算方法
DNS查询时间耗时 DNS解析耗时 domainLookupEnd - domainLookupStart
请求响应耗时 网络请求耗时 responseStart - requestStart
DOM解析耗时 DOM解析耗时 domInteractive - responseEnd
资源加载耗时 资源加载耗时 loadEventStart - domContentLoadedEventEend
DOM_READY耗时 DOM阶段渲染耗时 domContentLoadedEventEend - fetchStart
首次渲染耗时 首次渲染时间/白屏时间 responseEnd - fetchStart
首次可交互耗时 首次可交互耗时 domInteractive - fetchStart
首包时间耗时 首包时间 responseStart - domainLookupStart
页面完全加载耗时 页面完全加载时间 loadEventStart - fetchStart
TCP链接时间 TCP链接耗时 connectEnd - connectStart

自定义指标采集 我们可以通过自定义一些指标来采集我们想要的数据

const observer = new PerformanceObserver((list) => {
    for(const entry of list.getEntries) {
        console.log(entry)
    }
})
observer.observe({ entryTypes: ['longtask'] })
复制代码

可以通过PerformanceObserver.supportedEntryTypes属性来查看支持哪些属性

性能优化的工具

有一些工具可以帮助您自动执行 RAIL 测量。具体使用哪一种取决于您需要什么类型的信息,以及您喜欢什么类型的工作流程。

Chrome DevTools #

Chrome DevTools 对加载或运行页面时发生的一切活动进行深入分析。请参阅分析运行时性能入门,熟悉性能面板 UI。

以下 DevTools 功能密切相关:

Lighthouse #

web.dev/measure 下的 Chrome DevTools 中以 Chrome 扩展和 Node.js 模块的形式提供了 Lighthouse,WebPageTest 中也提供了此工具。只要您提供一个 URL,它就会模拟使用速度较慢的 3G 连接的中端设备在页面上运行一系列审核,然后提供关于加载性能的报告以及如何改进的建议。

以下审核密切相关:

响应

加载

WebPageTest web page performance testing tool  #

WebPageTest is a web page performance testing tool that uses actual browsers to visit web pages and collect timing metrics. Enter a URL at  webpagetest.org/easy  and you can get a report on the loading performance of that page on a real Moto G4 device using a slower 3G connection. You can also configure it to include Lighthouse auditing.

References

Measure performance using the RAIL model ( web.dev/rail/ )

Guess you like

Origin juejin.im/post/7084983567780069407