【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

Web Performance Metrics 与 Core Web Vitals 简介

  • 2020-10-30
  • 本文字数:5067 字

    阅读完需:约 17 分钟

Web Performance Metrics 与 Core Web Vitals 简介

前言

我们都知道网站性能的重要性。重要是重要,但是具体如何衡量和识别永远是个非常发散、不容易说清的事情。本文就将以业内重要会议上的分享为中心,分类详细介绍主流语境下所有重要的数据指标定义。


历史上,yslow 曾经作为互联网开发的核心指标唯一评价工具,它的指标代表了核心指标。之后逐步出现了 lighthouse 等种种新工具平台和新检测模式。经过几十年发展已经有众多各式各样的性能工具,对应的指标也趋于通用。具体如何评价指标本身的代表性也逐渐成为问题,需要关注。


到了 2018 年,Google 在 I/O 大会上提到, 75% 的用户认为 页面的加载速度 ,是决定他们交互体验的首要因素[1]。Ire Aderinokun (Google Web Expert) 在 2020 年 #PerfMatter 的分享上说,“一旦页面加载时间超过 5s,用户就有 90% 的可能放弃它。”[2]


所以,到底如何准确衡量网站的性能?

根据 Google 在 web.dev 上公布的数据,他们认为以用户为中心的性能指标,应该能回答以下四个问题[3]:


web.dev 是 Google Developer 提供的开发者社区,里面主要提到了一下列出的诸多类型的数据指标。


  1. 是否发生? 导航是否成功启动?服务器是否有响应?

  2. 是否有用? 是否已渲染可以与用户互动的足够内容?

  3. 是否可用? 用户可以与页面交互,还是页面仍在忙于加载?

  4. 是否令人愉快? 交互是否顺畅而自然,没有滞后和卡顿?


后文将介绍各性能指标如何回答上述问题,从而反应网站性能的,以及 Google 在提升网站性能上的努力 —— 推广 Core Web Vitals。

第一部分,Performance Metrics

为了回答上述四个问题,Google 提出了一系列的性能指标。根据上述的思考原则,我们把这些指标分为了四类,分别代表一次访问被用户感知的四个阶段的具体表现。



① 是否发生?

当用户访问一个网站的时候,关心的第一个问题永远是“是否发生”——浏览器是否成功地把我的请求发送出去,而服务器是否已经知道并开始处理我的请求?


TTFBFPFCP 就是回答这些问题的指标。


1. TTFB (Time to First Byte)

首字节到达的时间点。

2. FP (First Paint)

首次绘制,标记浏览器渲染任何在视觉上不同于导航前屏幕内容的时间点。

3. FCP (First Contentful Paint)

首次内容绘制,标记浏览器渲染来自 DOM 第一位内容的时间点,内容可能是文本、图像等元素。


TTFB、FP 和 FCP 这些指标标记出浏览器开始绘制内容的时间点,这些时刻等同于告诉用户: “浏览器已经开始处理服务器的返回了,你的请求已经发生了!”

② 是否有用?

当用户确定自己的请求发生了后,就会开始关心第二个问题:“是否有用?”


例如,用户在使用天气应用,在确定页面有反应了后,就开始关心,什么时候能展现有用的内容,从而得知今天的天气。


FMPLCPSI 就是回答这些问题的指标。


1. FMP (First Meaningful Paint)

首次有效绘制,是指首次绘制对用户有用内容的时间点。有用的内容,是指 Youtube 上的视频;Twitter 上的推文;天气应用中的天气预测…这些内容或元素,也被称为主角元素 (Hero Elements) ,能够向用户提供有用的内容。但是这些元素难以界定,所以后来用 LCP 来取代 FMP。

2. LCP (Largest Contentful Paint)

最大内容绘制时间,计算从页面开始加载到用户与页面发生交互(点击,滚动)这段时间内,最大元素绘制的时间,该时间会随着页面渲染变化而变化,因为页面中的最大元素在渲染过程中可能会发生改变。


3. SI (Speed Index)

速度指标,填充页面内容的速度,取开始加载到最后完成渲染,每一时刻页面未完成度的积分。页面的视觉完成度(visually complete)是基于 SSIM(Structural similarity Index) 计算的。

计算方式

例如下面的例子中,假设页面渲染在 6 帧中完成,每帧 500 ms,其中每帧的页面完成度分别为 0%,10%,30%,60%,90%,100%,计算得到 SI = 500 + 450 + 350 + 200 + 50,SI 的数值越低证明页面被填充的越快,用户的体验越好。





LCP 标记出浏览器绘制最大内容的时间点,并默认认为页面中最大的元素是对用户最有用的内容。LCP 试图标记出用户是在什么时刻得到有用内容的,而越早得到有用内容,用户的体验自然就越好。SI 反应出填充页面内容的速度。例如下图,虽然都是最后时刻填充完内容,但显然,上面会有种页面加载更快的感觉。


③ 是否可用?

在用户得到了有用的信息后,用户就会基于得到的信息作出反应,这就是页面“是否可用?”例如看到了新闻后,想要评论;知道了天气后,想要转发提醒朋友等等。TTI、FID、TBT 就是回答这些问题的指标。



在解释这些指标之前,我们先要理解为什么页面有时候不能及时响应用户。

1. Long Tasks

耗时任务。浏览器是单线程,所有任务会被添加到主线程的队列中逐个执行。如果有任务耗时过长,主线程就会被阻塞,其他任务就只能等待,包括那些由用户交互产生的任务,从而无法及时响应用户。根据 Jakob Nielsen 的研究 Response Times: The 3 Important Limits [4],页面应该在 100 ms 内响应用户输入,否则就会被用户认为卡顿。要实现小于 100 ms 的响应,单个任务必须在 50 ms 内完成。这样即使用户的输入行为发生在某个任务刚开始的时候,并且耗时 50 ms,在这个任务结束后,主线程仍有 50 ms 时间来响应用户输入,总响应时间在 100 ms 内。



通过 Chrome DevTools 或 Long Task API 能方便地发现这些耗时任务。


2. TTI (Time to Interactive)

可交互时间,用于标记页面已进行视觉渲染并能可靠响应用户输入的时间点。页面可能会因为多种原因而无法响应用户输入,例如页面组件运行所需的 Javascript 尚未加载,或者耗时较长的任务阻塞主线程。TTI 指标可识别页面初始 JavaScript 已加载且主线程处于空闲状态(没有耗时较长的任务)的时间点。


3. TBT (Total Blocking Time)

总共阻塞时间,计算的是从 FCP 到 TTI 之间,主线程阻塞的总时间。阻塞时间是指单次任务占用主线程超过 50 ms 的部分。

计算方式

例如下面的例子是页面加载过程中从 FCP 到 TTI 之间主线程的运行情况,一共执行了 5 个任务,分别耗时 250 ms,90 ms,35 ms,30 ms,155 ms,其中 3 个任务耗时超过 50 ms,将它们阻塞的时间累加起来 250 - 50 + 90 - 50 + 155 - 50 = 345 ms,得到 TBT。越低的 TBT 证明页面的有用性,可交互性越好。




4. FID (First Input Delay)

首次输入延迟,指用户首次输入到页面响应的时间。我们都知道第一印象的重要性,网站亦是如此。首次输入延迟会成为用户对网站很重要的第一印象,决定用户有可能成为忠实用户或者弃之而去。值得注意的是,FID 仅关注用户离散的操作,如点击,轻击,按键等,其他交互如滚动和缩放,并不是 FID 关注的,因为通常浏览器会用一个单独的线程来处理它们。


④ 是否令人愉快?

先来举个不愉快的例子。



在这个例子中,你本想点击按钮 B,页面突然发生偏移,你不幸点到了按钮 A。“是否令人愉快?”是用户在整个应用使用过程中都会发生的问题,它不仅包含之前说的 Long Tasks,要包含一些不符合预期的布局偏移,即 CLS。

1. CLS (Cumulative Layout Shift)

累计布局偏移。测量在页面的整个生命周期中发生的每个意外的样式移动所造成的布局偏移分数的总和。

计算方式

某次布局偏移分数 = 影响分数 * 距离分数。前一帧和当前帧的所有不稳定元素的可见区域的并集(占视口总面积的一部分)是当前帧的影响分数。例如下图中,有一个元素在一帧中占据了视口的一半。然后,在下一帧中,元素下移视口高度的 25%。红色的虚线矩形表示两个帧中元素的可见区域的并集,在这种情况下,其为总视口的 75%,因此其影响分数为 0.75。



距离分数是任何不稳定元素在框架中移动的最大距离(水平或垂直)除以视口的最大尺寸(宽度或高度,以较大的为准)。例如下图中,最大的视口尺寸是高度,并且不稳定元素移动了视口高度的 25%,这使得距离分数为 0.25。所以,在此例中,影响分数为 0.75,距离分数为 0.25,因此布局偏移分数为 0.75 * 0.25 = 0.1875。



不知道你有没有意识到一个问题,什么叫意外的偏移?如何区分下面两种情况,前者是意外的偏移,后者则是点击搜索按钮展开,是符合预期的。所以 CLS 在计算过程中会忽略用户交互后 0.5s 内的布局偏移;同时 CLS 也会忽略动画,忽略 transform 的变化[5]。



第二部分,Core Web Vitals

在第一部分中,我们了解了 1 个概念(Long Tasks)和 10 个指标的定义及部分计算方式,但现在的你怕是想不起来几个了 😂。都不记得有哪些性能指标的我们,有如何依据这些指标来提升网站性能呢。为此,Google 对众多的指标进行了取舍,提出了 Core Web Vitals。

什么是 Core Web Vitals?

概括来说:


  1. 是 Google 为了提升网络整体性能的努力;

  2. 是 Web Vitals 的子集,其核心基础指标 LCP,FID 和 CLS;

  3. 是未来网页排名算法中新的因子;


今年 5 月 ,Google 在 Chromium Blog (https://blog.chromium.org/2020/05/introducing-web-vitals-essential-metrics.html) 中提出的 Web Vitals,旨在提供统一的指标来量化用户在站点上的体验,囊括了之前在性能指标上的努力。同时,Google 认为不用每个人都成为网站性能方面的专家,大家只需要关注那些最核心最有价值的指标即可,于是提出了 Core Web Vitals,它是 Web Vitals 的子集,包含 LCP (Largest Contentful Paint),FID (First Input Delay) 和 CLS (Cumulative Layout Shift)。

为什么是 LCP, FID 和 CLS?

  1. 具有代表性;

  2. 简单,容易理解;

  3. 可以精确测量;


因为这三者分别从不同的角度(加载速度,交互性和视觉稳定性)反应了用户的体验。LCP 测试加载速度的体验,页面最主要的内容何时呈现;FID 测试交互上的体验,用户第一次输入后经过多久得到了响应;CLS 测试视觉稳定性上的体验,有多少内容发生了意外的偏移。因为它们可以精确测量,所以可以对它们分级,如何是好,如何是需要提升,如何又是差。




Google 用 75 分位来代表网站某一指标的整体结果 [6]。例如,网站 75% 的访问中,LCP 都小于 2s,那么网站的 LCP 指标就是好;相反,网站超过 25% 的访问中,FID 都超过 300ms,那么网站的 FID 就是差。

为什么是 ≤ 2500ms, ≤ 100ms, ≤ 0.1?

首先基于 Google 的调查研究 The Science Behind Web Vitals (https://blog.chromium.org/2020/05/the-science-behind-web-vitals.html),满足上述标准的网站,是能给用户带来良好的体验。


其次,这些指标也是可以达到的,在推出这些指标和阈值之前,已经基于 CrUX (Chrome User Experience Report) 的数据发现有 10% 的网站是能满足上述指标。

工具及周边

Google 正大力地推广 Core Web Vitals,除了在 I/O '20 上卖力的宣传,在 Webmaster (https://webmasters.googleblog.com/2020/05/evaluating-page-experience.html) 上声明会将 Core Web Vitals 纳入网页排名算法中,还提供了一系列的工具来帮助开发者基于这些指标去测量自己的网站。



  • 你可以先用 Search Console 新的 Core Web Vitals 报告去查看自己网站的性能情况。

  • 如果发现自己的网站有些问题的话,可以用 PageSpeed Insights 去定位网站的性能问题。

  • 然后你可以先在实验室本地环境,用 LighthouseChrome DevTools 去测量页面,得到具体的指引去修复性能问题。或者用 Web Vitals Chrome extension 在桌面端实时看到自己页面的 Core Web Vitals。

  • 如果你需要 Core Web Vitals 的 dashboard,可以使用更新后的 CrUX ( Chrome User Experience Report ) Dashboard 或者使用新的 Chrome UX Report API 来获得真实数据。

  • 缺少指引? web.dev/measure 可以测量你的页面,基于 PSI (PageSpeed Insights) 数据,给你相关的建议。

  • 最后,引入 Lighthouse CI 来确保每次迭代都没有使你的 Core Web Vitals 倒退。

参考文档

[1] Web performance made easy(Google I/O '18)


https://www.youtube.com/watch?v=Mv-l3-tJgGk


[2] FMP, TTI, WTF? Making Sense of Web Performance


https://www.youtube.com/watch?v=EIsk6pBNJ74


[3] User-centric performance metrics


https://web.dev/user-centric-performance-metrics/#user-centric_performance_metrics


[4] Response Times: The 3 Important Limits


https://www.nngroup.com/articles/response-times-3-important-limits/


[5] Annie Sullivan :: Understanding Cumulative Layout Shift :: #PerfMatters Conference 2020


https://www.youtube.com/watch?v=zIJuY-JCjqw&feature=youtu.be


[6] Defining the Core Web Vitals metrics thresholds


https://web.dev/defining-core-web-vitals-thresholds/


[7] Tools to measure Core Web Vitals


https://web.dev/vitals-tools/


本文转载自公众号字节前端 ByteFE(ID:ByteFE)。


原文链接


Web Performance Metrics 与 Core Web Vitals 简介


2020-10-30 10:041863

评论

发布
暂无评论
发现更多内容

苹果电脑删除磁盘分区及双系统分区的办法

互联网搬砖工作者

GitHub开源2小时Star破10万,阿里Java高并发集合手册终是被公开

做梦都在改BUG

Java 高并发 集合框架

Redis缓存穿透/击穿/雪崩以及数据一致性的解决方案

做梦都在改BUG

Java 缓存 穿透 击穿 雪崩

软件测试/测试开发丨4步,用 Docker搭建测试用例平台 TestLink

测试人

Docker 软件测试 自动化测试 测试开发 testlink

The Foundry Modo 16 Mac版(专业的三维建模软件)

Rose

mac软件下载 Foundry Modo 三维建模软件

YonTalk 大咖论道:YonBuilder 低代码开发平台能力解析

YonBuilder低代码开发平台

迪士尼的“元宇宙梦”醒了

Openlab_cosmoplat

开源社区 元宇宙

软件测试/测试开发丨Web自动化总卡在文件上传和弹框处理上?

测试人

软件测试 自动化测试 测试开发 selenium

如何通过Java代码在PowerPoint 幻灯片中插入公式

在下毛毛雨

PowerPoint 公式 java‘

喜报:旺链科技成为龙芯生态重要合作伙伴

旺链科技

区块链 生态合作

Mac OS如何显示隐藏文件和文件扩展名

互联网搬砖工作者

理性探讨AIGC未来的发展方向

加入高科技仿生人

人工智能 低代码 AIGC

格式塔理论

Data 探险实验室

可视化 大屏可视化 可视化看板 大屏布局 仪表板

亮相数字化转型大会!卡奥斯助力两化融合工业转型!

Openlab_cosmoplat

工业互联网 开源社区

一次偶然机会发现的MySQL“负优化”

做梦都在改BUG

Java MySQL 数据库 性能优化

Feast on Amazon 解决方案

亚马逊云科技 (Amazon Web Services)

人工智能

不会PS没关系,AI拼图技术已能以假乱真|斯坦福研究

Openlab_cosmoplat

开源社区 ps

深耕智能边缘研究和应用,英特尔中国研究院、南京英麒联合探索算力前沿

科技热闻

软件测试/测试开发丨做web自动化时,定位元素常用方法有哪些?

测试人

软件测试 自动化测试 测试开发 Web自动化测试

让ChatGPT手把手教我们学操作系统是一种怎样的体验?

Java全栈架构师

程序员 AI 后端 操作系统 计算机

ChatGPT已能操控机器人,工程师连代码都不用写,网友:微软在搞天网?

Openlab_cosmoplat

人工智能 机器人 开源社区 ChatGPT

三种Web通信技术之间的差异

郑州埃文科技

ChatGPT也BUG?带你走进ChatGPT背后的网络基础设施

郑州埃文科技

人工智能 ChatGPT

网心科技多项边缘计算成果亮相第十届中国网络视听大会

网心科技

阿里云加入“一云多芯”应用创新计划,首批通过金融专有云能力评估

云布道师

混合云

卡奥斯赋能发展引擎,“工赋山东”再加“数”!

Openlab_cosmoplat

工业互联网 开源社区

智慧公厕解决方案,光明源方案揭秘

光明源智慧厕所

智慧城市

Java:如何在PowerPoint幻灯片中创建散点图

在下毛毛雨

图表 PowerPoint java‘

你的收藏不能少的Spring笔记,阿里十年架构师手写Spring笔记

小小怪下士

Java spring 程序员

亚信科技AntDB数据库荣获互联网周刊金i奖“2022年度产品”

亚信AntDB数据库

数据库 AntDB 国产数据库 AntDB数据库 企业号 4 月 PK 榜

Double-check 技术:Golang 中多线程编程的必备技能

Jack

golang 设计模式

Web Performance Metrics 与 Core Web Vitals 简介_移动_字节跳动技术团队_InfoQ精选文章