优化 Cookie 通知，以提高性能和易用性。
本文介绍了 Cookie 通知对性能、性能衡量和用户体验的影响。
性能
Cookie 通知通常在网页加载过程早期加载，会向所有用户显示，并且可能会影响广告和其他网页内容的加载，因此可能会对网页性能产生重大影响。
Cookie 通知对网页指标的影响如下：
Largest Contentful Paint (LCP)：大多数 Cookie 意见征求通知都非常小，因此通常不包含网页的 LCP 元素。不过，有可能发生这种情况，尤其是在移动设备上。在移动设备上，Cookie 通知通常会占据大部分屏幕。当 Cookie 通知包含大段文本时，通常会出现这种情况（文本块也可以是 LCP 元素）。
First Input Delay (FID)：一般来说，您的 Cookie 意见征求解决方案本身对 FID 的影响微乎其微，因为 Cookie 意见征求只需要很少的 JavaScript 执行。不过，这些 Cookie 启用的技术（即广告脚本和跟踪脚本）可能会对网页的互动性产生重大影响。通过延迟这些脚本，直到接受 Cookie，可减少首次输入延迟 (FID)。
Cumulative Layout Shift (CLS)：Cookie 意见征求通知是导致布局偏移的一个很常见的原因。
一般来说，与您自己构建的 Cookie 通知相比，第三方提供商发送的 Cookie 通知对效果产生的影响更大。这并非 Cookie 通知所独有的问题，而是第三方脚本的一般性质问题。
最佳实践
本部分的最佳做法侧重于第三方 Cookie 通知。其中一些（但并非所有）最佳实践也适用于第一方 Cookie 通知。
异步加载 Cookie 通知脚本
Cookie 通知脚本应异步加载。为此，请将 async 属性添加到脚本标记中。
<script src="https://cookie-notice.com/script.js" async>
非异步脚本会阻止浏览器解析器。这会延迟网页加载和 LCP。如需了解详情，请参阅高效加载第三方 JavaScript。
直接加载 Cookie 通知脚本
Cookie 通知脚本应通过在主文档的 HTML 中放置脚本标记来“直接”加载，而不是由跟踪代码管理器或其他脚本加载。使用跟踪代码管理器或辅助脚本注入 Cookie 通知脚本会延迟 Cookie 通知脚本的加载：它会遮盖浏览器的先行解析器中的脚本，并阻止此脚本在 JavaScript 执行之前加载。
尽早与 Cookie 通知来源建立连接
所有从第三方位置加载 Cookie 通知脚本的网站都应使用 dns-prefetch 或 preconnect 资源提示，以便尽早与托管 Cookie 通知资源的来源建立起连接。如需了解详情，请参阅尽早建立网络连接以提升感知的网页速度。
<link rel="preconnect" href="https://cdn.cookie-notice.com/">
根据需要预加载 Cookie 通知
使用 preload 资源提示来加载其 Cookie 通知脚本对某些网站有益。preload 资源提示会通知浏览器针对指定资源发起提前请求。
<link rel="preload" href="https://www.cookie-notice.com/cookie-script.js">
当 preload 的使用仅限于每页提取几个关键资源时，其功能最为强大。因此，预加载 Cookie 通知脚本的实用性因情况而异。
在设置 Cookie 通知样式时，注意性能权衡
自定义第三方 Cookie 通知的外观和风格可能会产生额外的性能成本。例如，第三方 Cookie 通知并非总是能够重复使用在网页上其他位置使用的相同资源（例如网页字体）。此外，第三方 Cookie 通知往往会在较长的请求链结束时加载样式。为了避免任何意外情况，请注意 Cookie 通知的加载和应用样式及相关资源的方式。
避免布局偏移
以下是与 Cookie 通知相关的一些最常见的布局偏移问题：
- 屏幕顶部 Cookie 通知：屏幕顶部 Cookie 通知是导致布局偏移的一种常见原因。如果在周围的页面已呈现后在 DOM 中插入 Cookie 通知，它会将位于页面下方的页面元素进一步下推。您可以通过在 DOM 中为意见征求通知预留空间来消除此类布局偏移。如果这不可行（例如，如果 Cookie 通知的尺寸因地理位置而异），请考虑使用粘性页脚或模态窗口来显示 Cookie 通知。这两种替代方法都会在网页其余部分以叠加层的形式显示 Cookie 通知，因此在加载时 Cookie 通知不会导致内容发生变化。
- 动画：许多 Cookie 通知都使用动画，例如，“滑入”Cookie 通知是一种常见的设计模式。根据这些效果的实现方式，它们可能会导致布局偏移。如需了解详情，请参阅调试布局偏移。
- 字体：延迟加载字体可能会阻止渲染，并/或导致布局偏移。 这种现象在慢速连接下更明显。
高级加载优化
这些技术需要花费更多精力来实现，但可以进一步优化 Cookie 通知脚本的加载：
- 通过缓存和提供您自己的服务器中的第三方 Cookie 通知脚本，您可以提高这些资源的传送速度。
- 借助 Service Worker，您可以更好地控制第三方脚本（例如 Cookie 通知脚本）的提取和缓存。
性能衡量
Cookie 通知可能会影响效果衡量。本部分介绍其中一些影响以及缓解这些问题的技术。
真实用户监控 (RUM)
某些分析和 RUM 工具使用 Cookie 收集效果数据。如果用户拒绝使用 Cookie，这些工具将无法捕获性能数据。
网站应了解这种现象；了解您的 RUM 工具用于收集数据的机制也值得一试。但是，对于典型网站，考虑到数据偏差的方向和数据量，这种差异可能不会导致警报。Cookie 的使用不是衡量性能的技术要求。web-vitals JavaScript 库就是一个不使用 Cookie 的库的示例。
根据您的网站使用 Cookie 收集性能数据的方式（即 Cookie 是否包含个人信息），以及相关法律法规，使用 Cookie 来衡量效果可能与您网站上用于其他目的（例如广告 Cookie）的某些 Cookie 没有相同的法律规定。在征求用户意见时，某些网站会选择将性能 Cookie 拆分为单独的 Cookie 类别。
合成监控
如果不进行自定义配置，大多数合成工具（例如 Lighthouse 和 WebPageTest）只会衡量尚未对 Cookie 意见征求通知做出响应的首次使用的用户的体验。但是，在收集效果数据时，不仅需要考虑缓存状态的变化（例如初始访问与重复访问），还需要考虑 Cookie 接受状态的变化（已接受、拒绝或未响应）。
以下部分讨论了 WebPageTest 和 Lighthouse 设置，这些设置有助于将 Cookie 通知纳入性能衡量工作流程。但是，Cookie 和 Cookie 通知只是在实验室环境中难以完美模拟的众多因素之一。因此，请务必将 RUM 数据作为性能基准测试的基石，而不是合成工具。
使用 WebPageTest 测试 Cookie 通知
设计脚本
您可以使用脚本在收集跟踪记录时让 WebPageTest “点击”Cookie 意见征求横幅。
转到脚本标签页以添加脚本。以下脚本导航到要测试的网址，然后点击 ID 为 cookieButton 的 DOM 元素。
combineSteps
navigate %URL%
clickAndWait id=cookieButton
使用此脚本时，请注意：
combineSteps指示 WebPageTest 将后续脚本步骤的结果“合并”为一组跟踪记录和测量结果。在不使用combineSteps的情况下运行此脚本也会很有帮助，单独的跟踪记录可让您轻松查看在接受 Cookie 之前还是之后加载了资源。%URL%是一种 WebPageTest 惯例，表示要测试的网址。clickAndWait告知 WebPageTest 点击attribute=value指示的元素，并等待后续浏览器 activity 完成。它遵循以下格式：clickAndWait attribute=Value。
如果您已正确配置此脚本，则 WebPageTest 截取的屏幕截图不应显示 Cookie 通知（已接受 Cookie 通知）。
如需详细了解 WebPageTest 脚本，请查看 WebPageTest 文档。
设置 Cookie
如需在已设置 Cookie 的情况下运行 WebPageTest，请转到高级标签页，然后将 Cookie 标头添加到自定义标头字段中：
更改测试位置
如需更改 WebPageTest 使用的测试位置，请点击 Advanced Testing 标签页上的 Test Location 下拉菜单。
使用 Lighthouse 测试 Cookie 通知
在 Lighthouse 运行中设置 Cookie 可以作为一种机制，用于使页面进入特定状态，以便 Lighthouse 进行测试。Lighthouse 的 Cookie 行为因上下文（开发者工具、CLI 或 PageSpeed Insights）而略有不同。
DevTools
从开发者工具运行 Lighthouse 时，系统不会清除 Cookie。但是，其他类型的存储空间默认会被清除。您可以使用 Lighthouse 设置面板中的 Clear Storage 选项更改此行为。
CLI
从 CLI 运行 Lighthouse 会使用新的 Chrome 实例，因此默认情况下未设置任何 Cookie。如需在设置了特定 Cookie 的情况下从 CLI 运行 Lighthouse，请使用以下命令：
lighthouse <url> --extra-headers "{\"Cookie\":\"cookie1=abc; cookie2=def; \_id=foo\"}"
如需详细了解如何在 Lighthouse CLI 中设置自定义请求标头，请参阅在经过身份验证的页面上运行 Lighthouse。
PageSpeed Insights
通过 PageSpeed Insights 运行 Lighthouse 会使用新的 Chrome 实例，并且不会设置任何 Cookie。无法将 PageSeed Insights 配置为设置特定的 Cookie。
用户体验
不同的 Cookie 意见征求通知的用户体验 (UX) 主要取决于以下两个决定：Cookie 通知在网页中的位置，以及用户可以自定义网站对 Cookie 的使用方式。本节讨论这两种决策的潜在方法。
在考虑可能的 Cookie 通知设计时，请考虑以下事项：
- UX：用户体验是否良好？这一特定的设计会对现有的页面元素和用户流产生什么影响？
- 业务：您网站的 Cookie 策略是什么？您设置 Cookie 通知的目的是什么？
- 法律：这符合法律要求吗？
- 工程：这需要投入多少精力来实现和维护？更改这会有多难？
展示位置
Cookie 通知能够以页眉、内嵌元素或页脚的形式显示。它们还可使用模态窗口显示在网页内容顶部，或以插页式广告形式投放。
页眉、页脚和内嵌 Cookie 通知
Cookie 通知通常放置在页眉或页脚。在这两个选项中，通常比较适合使用页脚放置位置，因为页脚位置并不显眼，不与横幅广告或通知竞争注意力，并且通常不会导致 CLS。此外，它也是放置隐私权政策和使用条款的通用位置。
虽然内嵌 Cookie 通知可供使用，但可能难以集成到现有界面中，因此并不常见。
模态
模态是显示在网页内容之上的 Cookie 意见征求通知。模态的外观和表现可能会因其大小而大相径庭。
对于难以以不会导致布局偏移的方式实现 Cookie 通知的网站来说，较小的部分屏幕模态是一个很好的替代方案。
另一方面，应谨慎使用会遮挡大部分网页内容的大模态。特别是，对于内容模糊的陌生网站，小型网站可能会发现用户跳出，而不接受 Cookie 通知。虽然它们不一定是同义词概念，但如果您正在考虑使用全屏 Cookie 意见征求模式，则应了解有关 Cookie 墙的法律法规。
可配置性
Cookie 通知界面为用户提供不同级别的控制，以控制他们接受哪些 Cookie。
无可配置性
这些通知式 Cookie 横幅不会向用户显示用于选择停用 Cookie 的直接用户体验控件。它们通常会包含指向网站的 Cookie 政策的链接，该政策可能会向用户提供有关如何使用网络浏览器管理 Cookie 的信息。此类通知通常包含“关闭”和/或“接受”按钮。
部分可配置性
此类 Cookie 通知可让用户选择拒绝使用 Cookie，但不支持更精细的控制。这种 Cookie 通知方法不太常见。
完全可配置性
这些 Cookie 通知为用户提供了更精细的控制选项，以配置他们接受的 Cookie 用法。
用户体验：用于配置 Cookie 使用情况的控件最常使用在用户响应初始 Cookie 意见征求通知时启动的单独模态显示。不过，如果空间允许，某些网站会在初始 Cookie 意见征求通知中内嵌显示这些控件。
细化程度：最常用的 Cookie 可配置方法是允许用户按 Cookie“类别”选择启用 Cookie。常见 Cookie 类别的示例包括功能 Cookie、定位 Cookie 和社交媒体 Cookie。
不过，某些网站会更进一步，允许用户基于 Cookie 选择启用这项功能。或者，另一种为用户提供更具体的控制选项是将“广告”等 Cookie 类别划分到具体的用例中，例如，允许用户分别选择启用“基本广告”和“个性化广告”。
