优化 Cookie 通知以提升性能和易用性。
本文档讨论了 Cookie 通知对性能、性能衡量和用户体验有何影响。
性能
Cookie 通知会对网页性能产生重大影响，这是因为 Cookie 通知通常会在网页加载过程早期加载，会向所有用户显示，并且可能会影响广告和其他网页内容的加载。
下面说明了 Cookie 通知对网页指标的影响：
Largest Contentful Paint (LCP)：大多数 Cookie 意见征求通知都相当小，因此通常不包含网页的 LCP 元素。不过，这种情况可能会发生，尤其是在移动设备上。在移动设备上，Cookie 通知通常会占用大部分屏幕。当 Cookie 通知包含一大段文本（文本块也可以是 LCP 元素）时，通常就会出现这种情况。
Interaction to Next Paint (INP)：Cookie 通知通常是导致 INP 高的原因，因为 Cookie 通知在被接受后通常会添加大量第三方脚本。主要问题通常是执行 Accept 互动，因为这会导致大量处理工作，以便一次性添加这些第三方脚本。如需了解如何缓解此问题，请参阅下文的“最佳实践”部分。
Cumulative Layout Shift (CLS)：Cookie 意见征求通知是非常常见的布局偏移的原因。
一般来说，与您自己创建的 Cookie 通知相比，来自第三方提供商的 Cookie 通知对性能的影响会更大。这并非 Cookie 通知所独有的问题，而是第三方脚本的一般性质。
最佳实践
本部分中的最佳做法主要介绍第三方 Cookie 通知。这些最佳做法中的部分（但非全部）也适用于第一方 Cookie 通知。
了解 Cookie 通知对 INP 的影响
如前所述，由于用户点击 Accept 按钮时需要进行大量处理，因此它通常是导致 INP 问题的特定原因。
Chrome 团队与许多意见征求管理平台 (CMP) 合作，在点击“接受”后让浏览器能够在下次绘制时快速确认接受。可参阅此 PubTech 案例研究作为示例。
如果您的 CMP 受到上述影响，请尝试与他们联系，看看他们是否同样可以避免对嵌入该 CMP 的网站出现 INP 问题。请参阅优化长期任务一文，了解如何获得相关策略的指导。
异步加载 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 测试 Cookie 通知
以下部分讨论了 WebPageTest 和 Lighthouse 设置，这些设置对于将 Cookie 通知整合到效果衡量工作流中非常有用。不过，在实验室环境中，这些很难完美模拟的因素有很多，Cookie 和 Cookie 通知只是其中之一。因此，务必要将 RUM 数据作为性能基准测试的基石，而不是使用合成工具。
使用脚本
您可以使用脚本让 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。如需通过 CLI 运行设置了特定 Cookie 的 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。另一种为用户提供更具体的控制方法是将 Cookie 类别（如“广告”）细分到特定用例中，例如允许用户单独选择启用“基本广告”和“个性化广告”。
