如何提升网页核心指标
原文：https://simonhearne.com/2020/core-web-vitals
核心网页指标（Core Web Vitals）是即将影响 SEO 排名的三个全新的性能指标。学习如何提升他们来获得最好的用户体验！
简介
谷歌在 2020 年 5 月宣布将更新网页体验排名算法，这次更新包括两个关键部分：
三个新的性能指标将被用于 SEO 排名。
“头条新闻”不再需要 AMPHTML，并且页面性能会作为排名因子。
这次更新对于喜欢高速网站的人们来说是一个好消息：提供高速体验的网站能过获得两项来自谷歌的 SEO 收益，这表明谷歌更加重视用户体验中的速度。
这次更新由于新冠肺炎被延期到了 2021 年 5 月。
如果你想知道自己的网站目前在这些指标上的表现情况，你可以尝试通过PageSpeed Insights或[web.dev/measure](https://web.dev/measure/)来运行你的网站。这些由谷歌提供的工具会给你的网站一个体验评分，并告诉你如何才能提升这些新指标。
这些性能指标被设计为可以普遍地衡量页面速度，并且可以看作是用户体验的直接体现，他们可以对目前大部分网页的用户体验进行有效测量。同时，谷歌声明，他们会持续观察和评估这些指标，或许在未来会更改为其他更合理的指标。
最大内容渲染（Largest Contentful Paint）是一个衡量渲染性能的指标，他可以替换 page load 或 DOM ready 。
首次输入时间（First Input Delay）是用来衡量浏览器需要多久来响应用户的输入，例如点击。
累积布局偏移（Cumulative Layout Shift）是用来衡量网页的稳定性，它表示页面生命周期内所有意外的布局偏移。
建议值来自于真实用户体验数据的 P75：至少你的网页 75%的浏览应该达到 Good，这样就可以通过测试。
提升你的网页核心指标或许有助于提升 SEO 排名，但一定会对提升用户指标有帮助
谷歌如何测量速度
这三个性能指标是相对较新的，因此他们只在基于 Blink 内核的浏览器中支持（Chrome, Chrome on Android, Chromium Edge）。谷歌将用于“页面体验”的数据来源于Chrome UX 报告（CRUX）。这是一个全球 Chrome 浏览器中实际页面加载的匿名性能统计信息的集合。CRUX 会测量登陆页面和会话中页面的所有常规页面的加载，而与缓存状态无关。它不测量单页应用程序中的软导航（路径更改）。
这意味着软导航可能会受到惩罚，其 CLS 分数高于预期，并且 LCP 值缺失或不合理地高。不幸的是，目前还没有很好的解决方案。因此，减少意外的布局偏移并尽可能优化 LCP 显得尤为重要！
此次更新随附了一组建议的速度目标，这些目标是在 CRUX 数据中的第 75 个百分位数处测得的，因此至少有 75％的体验达到或超过了这些目标。由于缓存和会话状态在 CRUX 数据集中不可用，因此第 75 个百分位值取自所有页面加载（无论是否缓存）。
PageSpeed Insights 将为您提供三组性能指标（如果有）：
现场数据 - 给定 URL 的 CRUX 的数据
原始摘要 - 你的所有页面的汇总现场数据
实验 - 来自 Google 服务器的测试，该测试会有限制
如果您的页面没有足够的流量来产生现场数据，那么您将仅获得原始摘要结果。PageSpeed Insights 中的建议和诊断来自实验测试，性能指标则来自现场结果。这些建议可以让你大致了解需要改进的方面，它们可以对你的网页核心指标产生积极影响。
优化网页核心指标
接下来我们来探讨一下如何依次测量、诊断和改进三个新指标：LCP，FID 和 CLS。记住，任何改善这些指标的优化措施几乎都会使你的页面感觉更快，并改善用户体验！
最大内容渲染（LCP）
LCP 是在屏幕上绘制首屏可见元素中最大的元素时的时间点。在大多数情况下，这要么是主图/视频，要么是页面上的主要文字块。
LCP 是“页面加载时间”的一个很好的替代方案：它可以测量您的网站在页面上呈现关键内容前所需做的一切的耗时——DNS，TLS，HTML，CSS 以及阻塞的 JavaScript，但并不包括异步脚本或延迟加载的内容。
只有在下面三个阶段都完成后才会发生 LCP：
传递并解析了 HTML
关键路径资源已下载、解析和处理
LCP 资源已下载并呈现（图像，视频，Web 字体等）
快速返回 HTML 是可以提高页面速度的最重要的操作之一，如果你可以将 HTML 返回降低 100 毫秒，则每个时间指标都将提高 100 毫秒！快速地返回 HTML 可以归结为一些关键的优化：
DNS - DNS 是互联网的通讯录。可以通过增加 TTL 并使用全球分布的 DNS 服务来优化 DNS（有关更多详细信息，请参见此博客文章）。
TCP - 建立 TCP 连接的约束因素（通常）是用户与服务器之间的往返时间。使用内容分发网络可以将其降低到最低。
TLS - 安全网站需要一个或多个其他往返来创建安全连接。确保在站点的证书上启用了 OCSP 装订（甚至可以从 EV 降级到 OV 来实现此目的！），并且已将服务器或 CDN 配置为支持 TLSv1.3（请参阅 TLS 是否还快吗？）。
TTFB - 网站首字节的时间受服务器创建响应的速度限制。如果有可能，应将 HTML 缓存在 CDN 或反向代理中。如果无法进行 HTML 缓存（例如，页面中有个性化设置），请确保服务器能够在 100ms 内交付页面。
HTML - 听起来似乎很明显，但是 HTML 文档的大小和结构对性能至关重要。确保 HTML 文档已压缩，并且网络上的压缩文件大小低于 50kB。请注意确保
<title>在<head>文档的第一个并且此处没有阻塞的第三方<script>。
下载 HTML 后，浏览器将逐行解析文档以在关键路径中查找资源。head中的 CSS 和 JavaScript 具有很高的优先级，然后是图片，浏览器会按照它们出现的顺序下载。如果浏览器解析器看到一个阻塞的script标签（即没有 async 或 defer 属性），它将在获取，解析和执行该脚本时停止正在执行的所有操作。因此，在执行顺序不重要时，脚本应该始终是异步的，在执行顺序重要时，则应推迟脚本。检查内联脚本以减少其影响也很有用。
在可能的情况下，依靠现代 JavaScript 的支持，应该按页面对 JavaScript 包进行拆分。这将使你可以发送尽可能小的捆绑包，并在支持的情况下使用现代技术。请注意，module 默认情况下具有延迟行为：
关键路径的下一步是加载样式表：如果没有 CSS，浏览器将不知道如何呈现页面，因此它将阻阻塞任何<link rel="stylesheet">标签后的渲染。确保 CSS 根据页面分别打包，以减少不必要的重量，你可以在以后的页面生命周期中使用 media="none" 的 hack 手段来获取并缓存完整的样式表（确保此文件不会引起布局偏移！）：
LCP 的测量与缓存状态无关，因此请确保你的静态资源（JavaScript，CSS，图片和字体）可以在浏览器中缓存至少一小时，你可以使用像cache-control: max-age: 3600的响应标头来实现。另外，请确保你的文本资源已使用 gzip 或 brotli 压缩！
大部分电子商务网站上有一个常见问题——大量非关键图像在页面的早期加载，例如在大菜单定义中。原生延迟加载是一项通过减少页面加载期间的带宽争用来优化 LCP 的一项出色技术。Safari 尚不支持 loading 属性，但 WebKit 中提供了该属性，同时 iOS 的 Safari 中也以实验属性的形式支持了该属性，因此我们可以期待它很快获得常规支持！它在将数据发送到 CRUX 所有浏览器中都支持，因此现在使用它，你就可以在网页体验的 SEO 更新中受益。
确保您的主要元素具有loading='eager'属性，并且非首屏或默认隐藏的图像具有loading='lazy'属性。通过这种简单的优化，浏览器可以优先考虑尽快下载重要资产，从而改善 LCP 和用户体验。你在web.dev上阅读更多内容。
如果你的主要元素是图像或视频，则应以针对浏览器的最佳格式来提供。像 Cloudinary 或 Akamai Image and Video Manager 这样的第三方服务是动态优化媒体内容的不错选择。
主要元素不应与 JavaScript 绑定，因此最好用静态图像和具有适当 poster 属性的原生 <video> 元素来代替图像轮播和嵌入式视频播放器。如果你有视频海报，请确保已对其进行优化，并使用有效 preload 属性，例如 none 或，metadata 以减少页面加载期间的带宽争用。在 Mozilla Developer Network 上阅读有关这些优化的更多信息。
一条经验法则，主图像不应大于 200kB。
首次输入时间（FID）
FID 衡量浏览器在对例如点击之类的离散用户输入事件做出反应之前，忙于其他任务的时间。这可以表明 UI 对用户的反应如何，以及 CPU 在 JavaScript 处理方面有多忙。
在不降低用户体验的情况下改善 FID 的唯一方法是减少在页面加载期间和页面生命周期内执行 JavaScript 所花费的时间。提升此指标的一种简单方法是隐藏你的内容（也许在加载屏幕/微调器之后），直到 JavaScript 完成执行为止，这样访问者就不会在应用程序完全准备就绪之前尝试进行交互。不过，这很可能会对 LCP 和 CLS 指标产生负面影响，因此请谨慎使用！
假设我们需要同时改善 FID 和视觉效果，我们只有几种选择：
延迟或删除第三方脚本
推迟非关键脚本
提高 JS 性能
首要任务是在关键页面上运行性能跟踪，以了解消耗主线程时间的位置。任何耗时较多的部分都应该进行关注和调排查。
专注于长任务，这些都是单个执行块，最有可能导致较高的首次输入延迟。单击一个长任务以在下面的“自下而上”选项卡中显示调用堆栈：
你可以按 URL 对视图进行分组，以快速确定导致问题的脚本，在上面这个案例中，cookielaw 横幅 SDK 200 毫秒的 “self” 时间，意味着该时间花费在了此脚本中，而不是因为它的调用。这可能是由于脚本本身运行缓慢，或者是由于实施效果不佳而导致多个重复的函数调用。是时候去找出问题了！
高 FID 的另一个潜在原因是注水（“hydration”）过程。如果你有服务器端渲染的单页应用程序，则注水过程会将客户端应用程序功能添加到静态 HTML 中。尽管此过程可导致更快的首次渲染（和 LCP），但它可能会延迟交互性并增加用户尝试进行交互时出现延迟的可能性。如果你将 SSR 与客户端注水一起使用，Addy 针对这个问题又一个简要介绍，并提供了一些资源来解决这一性能差距。
累积布局偏移（CLS）
CLS 衡量的是用户加载页面并与页面交互时 UI 的稳定性。这是页面生命周期中所有意外布局变化的总和，例如当广告横幅加载并推动页面的主要内容时。
布局平移分数是由平移对视图窗口的影响得出的：视图窗口变化了多少以及元素移动了多远的乘积。理想的累积分数是 0，0.1 是好的。有关更多详细信息，请参见官方文档。
意外的布局变化意味着它们不会在离散的用户交互之后立即发生，因此可能会对用户体验产生负面影响。
CRUX 会在页面的整个生命周期中对其进行 CLS 度量，从导航的开始一直到用户离开页面。在这段时间内，所有意外的布局偏移都将相加，总分为测量结果；这使其成为在一个在实验环境中很难进行测量的指标。这也意味着，如 WebPageTest 和 mPulse 这些工具，会报告最好的情况下的 CLS，他们只会收集页面加载时的数据，而忽略后续的变化，例如滚动过程中发生的变化。
在页面加载期间优化 CLS 非常简单，我们只需要防止布局偏移即可！布局偏移的原因多种多样，因此让我们看一下其中的一些原因以及如何防止它们发生。
网页字体 - 使你的网页字体字符和行距与备用字体匹配
广告 - 为广告预先分配版式版位，如果广告失败或被阻止，则使用备用图片
延迟加载 CSS - 确保关键布局 CSS 位于关键路径中
图片 - 为图片添加 width 和 height 属性，这样浏览器就可以在下载图片之前分配空间
动态内容 - 尽可能为动态元素分配布局空间
Chrome 开发人员工具现在提供了一种便捷的方法，可以识别哪些元素导致了版式移位，以及它们如何对影响 CLS。
如果你将鼠标悬停在体验跟踪的布局偏移上，Chrome 会高亮显示页面上的元素。注意，详细信息显示了元素从何处移至何处。
我建议在 Performance 选项卡中设置网络和 CPU 节流选项，这样就更有可能捕获由于网络竞争而导致的布局变化。
一旦确定了引起布局偏移的元素，就该确定如何减少或防止它们了。
在上面来自 CNN 的示例中，标题元素在页面加载期间多次移动。主要的变化是由于作者图像的加载，并且将内容向右推了一部分。另一个布局变化则是由于标题的 Web 字体更改。只需将 width 和 height 属性添加到<img>元素，即可解决图像偏移！
对于文本元素的偏移，则是由于字体具有 font-display:swap 描述符（这是一件好事！），但后备字体与网页字体具有不同的字符宽度。加载网页字体后，文本元素将随着字符的压缩程度的变化而偏移，最终该元素的大小会适配内容的大小。在这个案例中，这是一个很小的布局偏移，但是对正文文本的影响可能更大，因为文本溢出可能会导致正文元素的大小调整。这可能可以使用[font-face 描述符](https://www.chromestatus.com/feature/5651198621253632)来将系统字体匹配到 Web 字体，从而解决这一问题，但最可靠的方法，是预加载网页字体和使用 font-display: optional。这种组合让浏览器在需要使用网页字体时可以直接使用，同时在网页字体不可用的情况下，可以让浏览器使用后备字体。这样可以确保不会因字体而导致布局变化，无论是初始页面加载还是后续页面加载（会使用初始加载时缓存的网页字体）都不会。
其他指标
虽然最初的 Page Experience 更新将 LCP，FID 和 CLS 定义为核心网络要素，但这些要素可能会随着时间而改变！还有许多其他指标可以提供附加价值，值得跟踪和优化。以下是一些你可能希望跟踪和改进的关键指标。
首次内容渲染（FCP）
LCP 测量屏幕上最大的渲染，而 FCP 测量首次渲染的出现时间。这是一个重要的指标，尤其是这是用户第一次知道其导航功能确实有效。此时间点还与用户的浏览器从上一页切换上下文的时间很好地关联。
FCP 通常与首次渲染相同，或在之后不久。首次渲染在计算中包括不可见元素，而 FCP 仅测量用户可见的内容。在下面的案例中，是网站徽标和标题：
可交互时间（TTI）
可交互时间（TTI）是当用户尝试交互时，页面何时可交互的近似值。此时间点的测量，是在 FCP 与主线程空闲（至少五秒钟没有长时间的任务）之间进行的。尽可能降低此指标将确保你的用户在尝试与你的页面进行交互时获得良好的体验。结合使用 TTI 和 TBT 可以大致了解浏览器在加载页面时的繁忙程度。
总阻塞时间（TBT）
总阻塞时间（TBT）衡量的是浏览器 CPU 在加载页面时的忙碌程度，以 FCP 和 TTI 之间的长任务（少于 50 毫秒）之和来衡量。减少此时间可能会改善用户体验，也可能有助于改善感知性能。在 JavaScript 配置文件中查找大型的长任务，并尝试减少，删除或延迟它们。
如何追踪性能
Google 的 PageSpeed Insights，Lighthouse 和 web.dev 等工具可以为你提供核心网络指标测量。不过，“现场”数据有一些限制：该数据仅从同意了匿名使用统计信息的 Google Chrome 浏览器用户收集，并且每月进行汇总，延迟一到两个星期。因此，如果是十月的第一周，则可能只有八月整个月的数据可用。
如果您想更紧密地跟踪网络生命，请使用 Akamai mPulse 之类的真实用户测量解决方案。RUM 工具可以从支持它们的每个浏览器中收集性能数据，并实时了解性能跟踪情况。你还可以快速发现特定页面或设备的问题，使数据更具指导意义。
结论 &行动
提议的页面体验更新很可能会在 2021 年中期发生。这将影响 SEO 排名以及 Google SERP 中“头条新闻”的资格标准。Google 提出了三个新的性能指标，这些指标将作为此 SEO 更新的标志，并根据它们与用户感知的性能的邻接程度以及在现场收集数据的能力进行选择。
针对这些由 Google 在 CRUX 中进行的测量的性能指标进行优化有可能会对未来的排名产生积极的影响，但无疑会对用户体验产生积极的影响。我们知道，更快的体验会导致跳出率降低，会话时间增加，满意度提高，转换率提高，SEO 流量增加，收入增加……那么，马上开始吧？
性能优化的好处在于，可以通过相对较小的代码调整来实现许多目标，因此，继续测试您的关键页面，发现有待改进的地方并做出积极的改变。
还未添加个人签名 2021.01.13 加入
还未添加个人简介
评论