Open JuniorTour opened 1 year ago
性能优化不等于体验优化。
以往谈到优化，我们常常关注的是前端性能优化，但性能优化只是我们改善前端项目的方式之一，目标不明确的性能优化并不能真正地优化前端项目，改善用户体验和开发体验才应该是我们优化的根本目的。
所以本书不同于以往的前端性能优化书籍，不是简单的罗列具体优化方法，而是更多的关注方法论，引导读者从宏观的视角，关注前端优化开始前、实施中、生效后的全过程，最终极致地、有效地改善用户体验和开发体验。
从而解决以往前端优化的诸多痛点：
目标不明确： 只会照本宣科，把别人的优化手段生搬硬套到自己的项目；
缺乏量化指标： 无法评估优化效果，拿不出客观、可量化的指标证明优化效果；
没有实质性的改善用户体验： 只优化了测试环境数据，没有真正的改善用户的主观体验；
没有长效化机制： 无法保证优化效果长期稳定、不出现衰退；
不关注开发体验： 没有认识到开发体验和用户体验的正相关性；
本书总结了作者6年多来优化和维护百万日访问量广告管理后台项目、千万日活信息流前端项目以及全球领先的浏览器平台音视频会议等项目的经验，以具体场景和实践经验为例，深入浅出地讲解现代前端工程体验优化的方法论和具体措施。
希望这本书能让读者有所收获，在工作中取的更大的成就。更欢迎通过评论，邮件（juniortour@qq.com），微信（xinghuamantou）等方式与我交流。
没有量化指标的优化是没有说服力的，不了解优化目标的现状更无法去优化它。
在实施体验优化时，一个常常陷入的误区是没有测量现状，没有建立可以量化优化效果的监控指标就开始优化。这样的方式往往导致自欺欺人的优化，自以为做了效果显著的改进优化，实际上并没有真正的改善用户体验。
例如笔者在刚参加工作时曾做过一次没有量化指标、为了优化而优化的技术改进。
当时计划为内部前端项目的 JS，CSS 等静态资源增加预加载Prefetch ，因为并没有提前建立量化指标、监控优化效果的理念，所以在完成优化，部署上线后，没有得到优化效果的量化数据，只能通过 JS 加载命中了缓存来解释优化的收益，对用户体验有什么影响更是一无所知。
Prefetch
这样没有反馈的技术改进显然不能称之为成功的、有意义的优化。
https://react.dev/ 的预加载 Prefetch 示例：
所以，为了能真正的改善用户体验，我们需要在开始优化前透彻的理解优化目标的现状，建立可量化的指标监控优化前后的变化。
这就需要我们能把主观的用户体验或开发体验量化为客观指标。
体验是非常主观的感受，同样的事物对不同的人，在不同的环境都会有不同的体验。
例如前端页面的加载速度，同一个页面，在不同的地理位置，不同的硬件设备上，都会有不同的表现，给用户的主观体验更是因人而异，所以直接测量用户体验很困难。
业界经过多年的实践，尝试过许多量化用户体验的指标，例如白屏时长、可交互耗时（Time to interact）、总阻塞时间 (Total Blocking Time，TBT)、首次有效绘制 (First Meaningful Paint，FMP) 等指标。
但这些指标往往逻辑复杂、不便于测量，甚至有显著的歧义，所以越来越少见。
近年来最实用的指标是基于 Chrome 官方推出的开源库web-vitals来获取用户访问前端页面时的页面渲染耗时，交互延迟等通用的量化指标。
web-vitals
web-vitals GitHub 地址: https://github.com/GoogleChrome/web-vitals
web-vitals是谷歌的 Chrome 维护团队于 2020 年开源的工具库，能基于浏览器的 Performance API 获取标准化的用户体验指标。
Performance API
主要有以下6项指标：
FCP测量从页面开始加载到页面中任意部分内容（文本、图像、<svg/>，<canvas/>等类型内容）完成渲染的时长。
<svg/>
<canvas/>
其值为浮点数，单位是秒。FCP值越小表示该指标状况越好、页面的渲染越快。
注意，FCP测量的是任意部分DOM渲染的耗时，而非全部内容，更不等于onLoad事件。
onLoad
如下图中的例子，FCP指标的值为1200毫秒。在这个时刻页面中首次出现了渲染出了文字和图像。
按照Chrome官方的推荐标准，FCP指标3个等级的评分分别为：
LCP测量从页面开始加载到可视区域内尺寸最大的文字或图像渲染完成的耗时。
其值为浮点数，单位是秒。LCP值越小表示该指标状况越好、最大元素渲染越快。
可以用Chrome浏览器自带 DevTool 中的 Performance Insights 工具来判断页面中什么元素是 最大内容，例如下图中的 img.banner-image 就是掘金首页的 最大内容元素，这个元素渲染的耗时为1.55秒，即LCP的值。
img.banner-image
FID 测量用户首次交互（点击、触摸）后到浏览器开始响应用户交互之间的间隔耗时。
其值为浮点数，单位是毫秒。FID值越小表示该指标状况越好，用户首次与页面交互时延迟越小。
这一指标只关注页面中首次交互是因为：首次交互时，页面往往处于尚未完全加载的状态，异步响应数据尚未全部返回前端、部分JS和CSS仍在执行、渲染过程中，浏览器的主线程会短暂的处于忙碌状态，不能即时响应用户交互。
同时第一次交互的延迟长短往往决定了用户对网页流畅度的第一印象， 所以这一指标也符合了我们“将用户主观体验的量化”的需求。
这一指标因为与 INP 指标测量目标有所重叠，且普适性不及INP，未来可能会被INP替代。
INP测量用户在页面浏览过程中的所有交互（点击、键盘输入、触摸等）与浏览器绘制对应响应的整体延迟情况。
其值为浮点数，单位是毫秒。INP值越小表示该指标状况越好，用户的所有交互延迟卡顿越少。
INP与FID只关注首次交互不同，INP会关注用户浏览网页全过程中的所有交互，所以通常会在页面可视化状态变化或页面卸载时完成计算。
按照Chrome官方的推荐标准，INP指标3个等级的评分分别为：
INP是一项处于实验状态的指标，其评分标准可能会有调整，目前描述的是其2023年5月的标准。
CLS测量页面中所有意外布局变化的累计分值。
其值为浮点数，无单位，值的大小大小表示意外布局变化的多少和影响大小。
所谓 意外布局变化 是指 DOM元素在前后绘制的2帧之间，非用户交互引起DOM元素尺寸、位置的变化。
例如： 这段视频中用户本想点击取消按钮，但是页面元素的布局位置产生了突然的变化，出现了非用户交互导致的意外布局变化，原本取消按钮的位置被确认按钮替代，导致了用户的误操作，严重损害了用户体验。
《意外布局变化》DEMO: https://codesandbox.io/s/cls-demo-qfu8g5?file=/src/App.js
引入 web-vitals 库后调用onCLS API也能检测到对应的意外布局变化的具体来源，如下图中sources字段的2个对象就明确的告诉了我们引起布局变化的来源元素的DOM引用，以及变化前后的尺寸位置状况（sources[i].currentRect, sources[i].previousRect）：
onCLS
sources
sources[i].currentRect, sources[i].previousRect
按照Chrome官方的推荐标准，CLS指标3个等级的评分分别为：
TTFB测量页面的HTTP请求发送后，响应第一字节数据的耗时。通常包括重定向、DNS查询、服务器响应延迟等耗时。
其值为整数，单位是毫秒。值越小表示该项指标状况越好，响应页面HTTP请求的耗时越短。
除了可以通过web-vitals的onTTFB() API获取，也可以使用 Chrome 自带的 DevTool Network 网络面板计算获取。如下图的例子知乎首页的TTFB耗时即：
onTTFB()
文档响应的整体耗时 减去 内容下载耗时（Content Download）， 391毫秒 - 57毫秒 = 335毫秒
按照Chrome官方的推荐标准，TTFB指标3个等级的评分分别为：
以上6项指标均可通过web-vitals库内置的API方便的获取，将web-vital库集成到我们提供给用户的前端页面，即可方便地获取用户的真实体验数据，例如：
获取 web-vitals 数据在线 DEMO: https://output.jsbin.com/bizanep （推荐使用Chrome浏览器）
要注意的细节是，这些指标中：
onFCP, onLCP, onTTFB
onFID
onCLS, onINP
web-vitals 的这些指标是Chrome官方在总结了海量数据后设计出来的，能科学地将主观的用户体验量化为客观的指标。
大量的收集这些指标数据，加以汇总分析便可以实现针对用户体验的“真实用户监控”（https://en.wikipedia.org/wiki/Real_user_monitoring） ，从用户的客户端收集到这些数据要比我们在自己的工作电脑环境上测量出的实验室数据更客观、更有说服力，更有助于我们做出数据驱动的优化决策。
有了获取用户体验指标数据的工具，还需要进一步大量收集、细致分析这些数据，以便了解现状、确定优化方向。
笔者在此推荐一套经过实践检验、开发体验较好的开源工具：Prometheus 和 Grafana。
.....
前言
性能优化不等于体验优化。
以往谈到优化，我们常常关注的是前端性能优化，但性能优化只是我们改善前端项目的方式之一，目标不明确的性能优化并不能真正地优化前端项目，改善用户体验和开发体验才应该是我们优化的根本目的。
所以本书不同于以往的前端性能优化书籍，不是简单的罗列具体优化方法，而是更多的关注方法论，引导读者从宏观的视角，关注前端优化开始前、实施中、生效后的全过程，最终极致地、有效地改善用户体验和开发体验。
从而解决以往前端优化的诸多痛点：
目标不明确： 只会照本宣科，把别人的优化手段生搬硬套到自己的项目；
缺乏量化指标： 无法评估优化效果，拿不出客观、可量化的指标证明优化效果；
没有实质性的改善用户体验： 只优化了测试环境数据，没有真正的改善用户的主观体验；
没有长效化机制： 无法保证优化效果长期稳定、不出现衰退；
不关注开发体验： 没有认识到开发体验和用户体验的正相关性；
本书总结了作者6年多来优化和维护百万日访问量广告管理后台项目、千万日活信息流前端项目以及全球领先的浏览器平台音视频会议等项目的经验，以具体场景和实践经验为例，深入浅出地讲解现代前端工程体验优化的方法论和具体措施。
希望这本书能让读者有所收获，在工作中取的更大的成就。更欢迎通过评论，邮件（juniortour@qq.com），微信（xinghuamantou）等方式与我交流。
目录
第一章、数据驱动，指标先行
1. 为什么要建立量化指标？
没有量化指标的优化是没有说服力的，不了解优化目标的现状更无法去优化它。
在实施体验优化时，一个常常陷入的误区是没有测量现状，没有建立可以量化优化效果的监控指标就开始优化。这样的方式往往导致自欺欺人的优化，自以为做了效果显著的改进优化，实际上并没有真正的改善用户体验。
例如笔者在刚参加工作时曾做过一次没有量化指标、为了优化而优化的技术改进。
当时计划为内部前端项目的 JS，CSS 等静态资源增加预加载
Prefetch，因为并没有提前建立量化指标、监控优化效果的理念，所以在完成优化，部署上线后，没有得到优化效果的量化数据，只能通过 JS 加载命中了缓存来解释优化的收益，对用户体验有什么影响更是一无所知。这样没有反馈的技术改进显然不能称之为成功的、有意义的优化。
所以，为了能真正的改善用户体验，我们需要在开始优化前透彻的理解优化目标的现状，建立可量化的指标监控优化前后的变化。
这就需要我们能把主观的用户体验或开发体验量化为客观指标。
2. 如何将主观的体验量化为客观指标
体验是非常主观的感受，同样的事物对不同的人，在不同的环境都会有不同的体验。
例如前端页面的加载速度，同一个页面，在不同的地理位置，不同的硬件设备上，都会有不同的表现，给用户的主观体验更是因人而异，所以直接测量用户体验很困难。
业界经过多年的实践，尝试过许多量化用户体验的指标，例如白屏时长、可交互耗时（Time to interact）、总阻塞时间 (Total Blocking Time，TBT)、首次有效绘制 (First Meaningful Paint，FMP) 等指标。
但这些指标往往逻辑复杂、不便于测量，甚至有显著的歧义，所以越来越少见。
近年来最实用的指标是基于 Chrome 官方推出的开源库
web-vitals来获取用户访问前端页面时的页面渲染耗时，交互延迟等通用的量化指标。1. web-vitals 各项指标简介
web-vitals是谷歌的 Chrome 维护团队于 2020 年开源的工具库，能基于浏览器的Performance API获取标准化的用户体验指标。主要有以下6项指标：
1. 首次内容绘制 (First Contentful Paint，FCP)
FCP测量从页面开始加载到页面中任意部分内容（文本、图像、
<svg/>，<canvas/>等类型内容）完成渲染的时长。其值为浮点数，单位是秒。FCP值越小表示该指标状况越好、页面的渲染越快。
注意，FCP测量的是任意部分DOM渲染的耗时，而非全部内容，更不等于
onLoad事件。如下图中的例子，FCP指标的值为1200毫秒。在这个时刻页面中首次出现了渲染出了文字和图像。
按照Chrome官方的推荐标准，FCP指标3个等级的评分分别为：
2. 最大内容绘制 (Largest Contentful Paint，LCP)
LCP测量从页面开始加载到可视区域内尺寸最大的文字或图像渲染完成的耗时。
其值为浮点数，单位是秒。LCP值越小表示该指标状况越好、最大元素渲染越快。
可以用Chrome浏览器自带 DevTool 中的 Performance Insights 工具来判断页面中什么元素是 最大内容，例如下图中的
img.banner-image就是掘金首页的 最大内容元素，这个元素渲染的耗时为1.55秒，即LCP的值。按照Chrome官方的推荐标准，FCP指标3个等级的评分分别为：
3. 首次输入延迟 (First Input Delay ，FID)
FID 测量用户首次交互（点击、触摸）后到浏览器开始响应用户交互之间的间隔耗时。
其值为浮点数，单位是毫秒。FID值越小表示该指标状况越好，用户首次与页面交互时延迟越小。
这一指标只关注页面中首次交互是因为：首次交互时，页面往往处于尚未完全加载的状态，异步响应数据尚未全部返回前端、部分JS和CSS仍在执行、渲染过程中，浏览器的主线程会短暂的处于忙碌状态，不能即时响应用户交互。
同时第一次交互的延迟长短往往决定了用户对网页流畅度的第一印象， 所以这一指标也符合了我们“将用户主观体验的量化”的需求。
按照Chrome官方的推荐标准，FCP指标3个等级的评分分别为：
4. 本次交互到下次绘制延迟（Interaction to Next Paint，INP）
INP测量用户在页面浏览过程中的所有交互（点击、键盘输入、触摸等）与浏览器绘制对应响应的整体延迟情况。
其值为浮点数，单位是毫秒。INP值越小表示该指标状况越好，用户的所有交互延迟卡顿越少。
INP与FID只关注首次交互不同，INP会关注用户浏览网页全过程中的所有交互，所以通常会在页面可视化状态变化或页面卸载时完成计算。
按照Chrome官方的推荐标准，INP指标3个等级的评分分别为：
INP是一项处于实验状态的指标，其评分标准可能会有调整，目前描述的是其2023年5月的标准。
5. 累积布局偏移 (Cumulative Layout Shift，CLS)
CLS测量页面中所有意外布局变化的累计分值。
其值为浮点数，无单位，值的大小大小表示意外布局变化的多少和影响大小。
所谓 意外布局变化 是指 DOM元素在前后绘制的2帧之间，非用户交互引起DOM元素尺寸、位置的变化。
例如：
这段视频中用户本想点击取消按钮，但是页面元素的布局位置产生了突然的变化，出现了非用户交互导致的意外布局变化，原本取消按钮的位置被确认按钮替代，导致了用户的误操作，严重损害了用户体验。
引入 web-vitals 库后调用
onCLSAPI也能检测到对应的意外布局变化的具体来源，如下图中sources字段的2个对象就明确的告诉了我们引起布局变化的来源元素的DOM引用，以及变化前后的尺寸位置状况（sources[i].currentRect, sources[i].previousRect）：按照Chrome官方的推荐标准，CLS指标3个等级的评分分别为：
6. 第一字节时间 (Time to First Byte，TTFB)
TTFB测量页面的HTTP请求发送后，响应第一字节数据的耗时。通常包括重定向、DNS查询、服务器响应延迟等耗时。
其值为整数，单位是毫秒。值越小表示该项指标状况越好，响应页面HTTP请求的耗时越短。
除了可以通过
web-vitals的onTTFB()API获取，也可以使用 Chrome 自带的 DevTool Network 网络面板计算获取。如下图的例子知乎首页的TTFB耗时即：文档响应的整体耗时 减去 内容下载耗时（Content Download）， 391毫秒 - 57毫秒 = 335毫秒
按照Chrome官方的推荐标准，TTFB指标3个等级的评分分别为：
2. web-vitals 使用示例
以上6项指标均可通过web-vitals库内置的API方便的获取，将web-vital库集成到我们提供给用户的前端页面，即可方便地获取用户的真实体验数据，例如：
要注意的细节是，这些指标中：
onFCP, onLCP, onTTFB均为在页面初始化时自动触发。onFID是在用户第一次与页面交互时触发。onCLS, onINP则因为要测量页面的全生命周期，往往无固定触发时间点，在实践中通常会在交互停止一段时间后，或页面可视状态变化（例如切换标签页）后触发。web-vitals 的这些指标是Chrome官方在总结了海量数据后设计出来的，能科学地将主观的用户体验量化为客观的指标。
大量的收集这些指标数据，加以汇总分析便可以实现针对用户体验的“真实用户监控”（https://en.wikipedia.org/wiki/Real_user_monitoring） ，从用户的客户端收集到这些数据要比我们在自己的工作电脑环境上测量出的实验室数据更客观、更有说服力，更有助于我们做出数据驱动的优化决策。
3. 用户体验数据收集与可视化：基于 Prometheus 及 Grafana 的实现简介
有了获取用户体验指标数据的工具，还需要进一步大量收集、细致分析这些数据，以便了解现状、确定优化方向。
笔者在此推荐一套经过实践检验、开发体验较好的开源工具：Prometheus 和 Grafana。
.....
《前端工程体验优化》全书现已发布到掘金小册，欢迎各位朋友交流学习