对于目前项目团队最近正在优化的网站性能，起初我显得很迷茫，如何衡量一个移动端网页是优秀的，能达到200ms内，甚至是1s内可完全加载的速度。或又是依赖于一切TTI、FCP之类经典的指标(TTI.FCP.超链)。
经leader的指点，多在谷歌上看一些最流行的解决方案成为我最近的目标之一。下面将介绍一些关于网站性能在20年新兴指标。亦可在面试中回答相关网页性能方面的问题
Core Web Vitals
Core-web-vitals是一组领域指标，用于衡量网络上实际用户体验的重要方面。 Core Web Vitals包括指标以及每个指标的目标阈值，可帮助开发人员定性地了解其网站的体验是“良好”，“需要改进”还是“差”。 这篇文章将解释通常用于选择Core Web Vitals指标阈值的方法，以及如何选择每个特定Core Web Vitals指标的阈值。
Core Web Vitals metrics and thresholds
暂且称为网站关键性能指标与其阈值
在2020年，网站关键性能指标是三个指标：最大内容绘画（LCP），首次输入延迟（FID）和累积布局偏移（CLS）。
每个指标都从不同方面衡量用户体验：
LCP(Largest Contentful Paint)
LCP measures perceived load speed and marks the point in the page load timeline when the page's main content has likely loaded
我感觉有点像FCP
LCP衡量感知的加载速度，并在页面主要内容可能已加载时标记页面加载时间轴中的点；
FID(First Input Delay)
FID measures responsiveness and quantifies the experience users feel when trying to first interact with the page
我感觉有点像TTI
FID测量响应度并量化用户在首次尝试与页面互动时的体验；
CLS(Cumulative Layout Shift)
CLS measures visual stability and quantifies the amount of unexpected layout shift of visible page content
视觉稳定性
CLS可以测量视觉稳定性，并量化可见页面内容的非预期以内的布局偏移量。
每个Core Web Vitals指标都有关联的阈值，将性能分为"good", "needs improvement", or "poor"：
Percentile 百分位，性能监测中常用的指标项，例如上四分卫，85分位，95分位等；
此外，为了对页面或网站的整体性能进行分类，我们使用该页面或网站的所有页面浏览量的75分位值。
换句话说，如果网站的至少75％的页面浏览量达到“good”阈值，则该网站将被归类为该指标具有“good”性能。 相反，如果至少25％的页面浏览量达到“poor”的阈值，则该站点被归类为“poor”的性能。
因此，例如，LCP 75分位是2秒被归类为“good”，而LCP 75分位是5秒归类为“poor”。
Criteria for the Core Web Vitals metric thresholds （关键性能指标的标准）
在为Core Web Vitals指标建立阈值时，我们首先确定每个阈值必须满足的条件。 下面，我解释了我们在Google用来评估2020 Core Web Vitals指标阈值的标准。 随后的部分将更详细地介绍如何在2020年使用这些标准为每个指标选择阈值。
在未来的几年中，我们预计将在网上对上述标准和阈值进行改进和补充，以进一步提高我们衡量用户体验的能力。
High-quality user experience（用户体验质量定义）
我们的主要目标是针对用户及其体验质量进行优化。鉴于此，我们旨在确保满足Core Web Vitals“good”阈值的页面能够提供高质量的用户体验。
为了确定与高质量用户体验相关的阈值，我们寻求人类感知和HCI研究。尽管有时会使用单个固定阈值来总结此研究，但我们发现基础研究通常表示为一系列值。
例如，有时将有关用户在失去焦点之前通常等待的时间的研究描述为1秒，而将基础研究实际上表示为从几百毫秒到几秒的范围。
The fact that perception thresholds vary depending on user and context is further supported by aggregated and anonymized Chrome metrics data, which shows that there is not a single amount of time users wait for a web page to display content before aborting the page load. Rather, this data shows a smooth and continuous distribution. For a more in depth look at human perception thresholds and relevant HCI research, see The Science Behind Web Vitals.
事实是感知阈值通常由用户所决定，并且上下文中已很好的被各种 匿名与汇总的chrome 衡量数据所证实,用户愿意花不少的时间在中止页面加载前为了等待页面内容展示出来。
而是，该数据显示了平稳连续的分布。有关人类感知阈值和相关HCI研究的更深入了解，请参阅web vitals背后的科学。
如果有合适可用的用户体验调研的数据结果，那么一定存在合理的数据集，我们使用这样的数据集来指导我们进行阈值的选择。如果那些贴合用户经验的调研数据结果是不可获得的，类似像一些新指标：CLS（Cumulative Layout Shift），我们会评估符合该指标的不同候选阈值的真实页面，以识别可带来良好用户体验的阈值。
指标可行性
另外，为了确保网站所有者可以成功地优化其网站，以达到“good”阈值，我们要求对于网络网页的阈值是可达到的。 例如，虽然0毫秒是理想的LCP“良好”阈值，其表现为瞬间完成加载的体验，但由于网络和设备处理延迟，在大多数情况下零毫秒阈值实际上是无法实现的。 因此，对于Core Web Vitals，0毫秒不是合理的LCP“good”阈值。
在评估候选核心Web Vitals“good”阈值时，我们根据Chrome用户体验报告（CRUX）中的数据验证了这些阈值是否可以实现。 为了确认可以达到阈值，我们要求目前至少有10％的来源满足“good”阈值。 此外，为确保优化的站点不会由于现场数据的可变性而被错误分类，我们还验证了优化的内容始终符合“good”阈值。
相反，我们通过确定目前只有少数来源无法满足的性能水平来确定“poor”阈值。 除非有可用于定义“poor”阈值的研究，否则默认情况下表现最差的10-30％的来源被归类为“poor”。
关于百分位的选择
如前所述，为了对网页或网站的整体效果进行分类，我们使用对该网页或网站的所有访问的第75个百分位数。 基于两个标准选择了第75个百分位。 首先，百分位数应确保对页面或网站的大多数访问都达到目标性能水平。 其次，所选百分比的值不应受到异常值的过度影响。
这些目标彼此之间有些矛盾。 为了满足第一个目标，较高的百分比通常是更好的选择。 但是，如果百分位数较高，则结果值受到异常值影响的可能性也会增加。 如果对站点的几次访问恰巧是在不稳定的网络连接上导致的LCP样本过大，我们不希望这些异常样本决定站点分类。 例如，如果我们使用较高的百分位数（例如第95位）评估具有100次访问的网站的效果，则只需花费5个离群值样本即可使第95个百分位值受到离群值的影响。
鉴于这些目标有些矛盾，经过分析，我们得出的结论是，第75个百分位数达到了合理的平衡。 通过使用第75个百分位，我们知道大多数对该网站的访问（4个中的3个）都达到了目标效果或更高的目标水平。 此外，第75个百分点的值受异常值影响的可能性较小。 回到我们的示例，对于访问量为100的网站，其中25次访问需要报告较大的离群值样本，以了解第75个百分位数的值会受到离群值的影响。 虽然100个样本中有25个可能是异常值，但与第95个百分位数的情况相比，可能性要小得多
Largest Contentful Paint （LCP）
Quality of experience (关于体验质量的问题)
1秒通常被引用为用户在开始失去对任务的关注之前将等待的时间。 在仔细研究相关研究后，我们发现1秒是描述值范围的近似值，范围从大约几百毫秒到几秒。
Card等人和Miller是1秒阈值的两个常见引用来源。 Card引入了Newell的统一认知理论，定义了1秒的“立即响应”阈值。 Newell将立即响应解释为“必须在大约一秒钟内（即大约从0.3秒到大约3秒）内对某些刺激做出响应”。 这是继纽维尔（Newell）关于“认知的实时约束”的讨论之后的结果，在该讨论中，“引起认知考虑的与环境的交互发生在几秒的数量级”，范围大约为0.5到2-3秒。
Miller是另一个常被引用的1秒阈值来源，他指出“如果响应延迟大于2秒，人类对计算机的交互会发生巨大的影响，有时可能是3秒”
Miller and Card的研究将用户失去焦点之前等待的时间范围定为大约0.3到3秒，这表明我们的LCP“good”阈值应在此范围内。 另外，假设现有的“First Contentful Paint”(FCP)的“good”阈值为1秒，并且最大“Largest Contentful Paint”(LCP)通常发生在“FCP”之后，我们进一步将候选LCP阈值范围从1秒限制为3秒。 要在此范围内选择最符合我们标准的阈值，我们杰西莱看一下这些候选阈值的可实现性
可达到性
使用来自CrUX的数据，我们可以确定满足候选LCP“良好”阈值的网络中来源的百分比。
虽然少于10％的来源符合1秒内的阈值，但其他所有1.5到3秒的阈值都满足我们的要求，即至少10％的来源满足“good”阈值，因此LCP是有效的候选者。
此外，为确保对于优化良好的网站始终可以实现所选的阈值，我们分析了网络上性能最高的网站的LCP性能，以确定对于这些网站始终可以实现的阈值。 具体来说，我们的目标是确定性能最高的网站始终可以在第75个百分位数上实现的阈值。 我们发现1.5秒钟和2秒钟的阈值无法始终达到，而2.5秒钟的阈值始终可以达到。
为了确定LCP的“poor”阈值，我们使用CrUX数据确定大多数来源满足的阈值：
对于4秒钟的阈值，大约26％的移动端来源和21％的PC端来源将被归类为poor。 这落在我们的10-30％的目标范围内，因此我们得出结论认为4秒是可以接受的“poor”阈值。
因此，我们得出结论，对于LCP，2.5秒是合理的“good”阈值，而4秒是合理的“poor”阈值。
First Input Delay
High-quality user experience（高质量的用户体验）
研究得出的结论是合理一致的，得出的结论是，大约100ms的视觉反馈延迟被认为是由相关的源（例如用户输入）引起的。 这表明100ms的“FID”“good”阈值很可能是最小的标准：如果处理输入的延迟超过100ms，则其他处理和渲染步骤无法及时完成。
Jakob Nielsen经常引用的“响应时间：3个重要限制”将0.1秒定义为让用户感觉系统正在做出即时反应的限制。 尼尔森引用了米勒和卡德（Miller and Card），后者引用了米乔特（Michotte）的1962年《因果关系》。 在Michotte的研究中，实验参与者被显示为“屏幕上有两个对象。对象A出发并向B移动。它在与B接触时即停止，而后者随后开始并远离A。” Michotte改变了从对象A停止到对象B开始移动之间的时间间隔。 Michotte发现，对于大约100ms的延迟，参与者给人的印象是对象A引起对象B的运动。对于大约100ms到200ms的延迟，因果关系是混杂的；对于超过200ms的延迟，则是对象的运动 B不再被视为是由对象A引起的。
同样，Miller将“对控制激活的响应”的响应阈值定义为“通常是通过按键，开关或其他控制构件的移动来发出的指示其已被物理激活的动作指示。应以……觉察到此响应。 时间延迟：不超过0.1秒”，后来又“按下按键和视觉反馈之间的延迟应不超过0.1到0.2秒”。 最近，Kaaresoja等人在《Towards the Temporally Perfect Virtual Button》中调查了在触摸屏上触摸虚拟按钮与随后的视觉反馈（指示该按钮被触摸）之间存在各种延迟的同时感。 当按钮按下和视觉反馈之间的延迟为85ms或更短时，参与者报告在75％的时间内，视觉反馈与按钮按下同时出现。 此外，对于100毫秒或更短的延迟，参与者报告了按键的感知质量始终如一，对于100毫秒至150毫秒的延迟，感知质量下降，对于300毫秒的延迟，感知质量下降至非常低的水平。
所以我们定义100ms为good
Cumulative Layout Shift
Quality of experience （用户体验质量定义）
累积版式移位（CLS）是一种新的指标，用于衡量页面可见内容的移位量。 鉴于CLS是新的，我们尚不了解可以直接告知该指标阈值的研究。
因此，为了确定与用户期望相符的阈值，我们评估了具有不同版式偏移量的真实世界中的研究，以确定在消费页面内容时造成重大破坏之前，可以接受的最大偏移量。 在我们的内部测试中，我们发现从0.15或更高的偏移水平一直被认为是破坏性的，而从0.1或更低的偏移是明显的，但没有过度破坏性。 因此，虽然零布局偏移是理想的，但我们得出的结论是，高达0.1的值是候选的“good” CLS阈值
可达到性
尽管CrUX数据表明0.05可能是一个合理的CLS“good”阈值，但我们认识到，在某些用例中，目前很难避免破坏性的布局偏移。 例如，对于第三方嵌入的内容（例如社交媒体嵌入），有时直到完成加载才知道嵌入内容的高度，这可能导致布局偏移大于0.05。 因此，我们得出的结论是，尽管许多来源都达到了0.05阈值，但CLS阈值0.1的宽松程度稍逊一筹，从而在体验质量和可实现性之间取得了更好的平衡。 我们希望，Web生态系统将继续寻找解决方案，以解决由第三方嵌入引起的布局变化，这将允许在将来的Core Web Vitals迭代中使用更严格的CLS“好”阈值0.05或0。 。
此外，为了确定CLS的“poor”阈值，我们使用CrUX数据来确定大多数来源满足的阈值：
对于0.25阈值，大约20％的移动端来源和18％的PC端来源将被归类为“poor”。 这落在我们的10-30％的目标范围内，因此我们得出结论，0.25是可接受的“poor”阈值。
我的想法
对于目前我正在从事的事情来说，LCP和CLS现阶段可加入作为目前项目的性能指标，
LCP(Largest Contentful Paint)
CLS(Cumulative Layout Shift)
目前项目的关注点在于网页的打开速度，FID作为交互后的反应时间是后续需要关注的指标。
LCP
LCP指标2.5s是合理的“good”阈值，而4秒是合理的“poor”阈值。2.5-4s是needs improvement的范围。
CLS
CLS指标高达0.1的值是候选的“good”，0.25是可接受的“poor”阈值，0.1-0.25是 needs improvement的范围
遗留问题：
LCP、CLS如何计算及统计？我们目前在哪个区间？如何提速？ 我们现阶段以最小的成本能完成的LCP、CLS提速的目标是多少？
