优化 Cookie 通知以提升性能和易用性。
本文档讨论了 Cookie 通知对性能、性能衡量和用户体验有何影响。
性能
Cookie 通知通常在网页加载流程的早期加载，会向所有用户显示，并且可能会影响广告和其他网页内容的加载，因此可能会对网页性能产生重大影响。
下面说明了 Cookie 通知对网页指标的影响：
Largest Contentful Paint (LCP)：大多数 Cookie 意见征求通知都相当小，因此通常不包含网页的 LCP 元素。不过，这种情况可能会发生，尤其是在移动设备上。在移动设备上，Cookie 通知通常会占据屏幕的更大比例。当 Cookie 通知包含大量文本块时，通常会发生这种情况（文本块也可能是 LCP 元素）。
Interaction to Next Paint (INP)：Cookie 通知通常会在用户接受后添加大量第三方脚本，因此往往会导致 INP 较高。主要问题通常是执行 Accept 互动，因为这会导致系统进行大量处理来一次性添加这些第三方脚本。如需了解如何缓解此问题，请参阅“最佳实践”部分。
Cumulative Layout Shift (CLS)：Cookie 意见征求通知是导致布局偏移的常见原因。
一般来说，与您自己创建的 Cookie 通知相比，来自第三方提供商的 Cookie 通知对性能的影响会更大。这并不是 Cookie 通知独有的问题，而是第三方脚本的一般性质。
最佳做法
本部分介绍的最佳实践侧重于第三方 Cookie 通知。其中一些（但不是全部）最佳实践也适用于第一方 Cookie 通知。
了解 Cookie 通知对 INP 的影响
如前所述，由于用户点击 Accept 按钮时需要进行大量处理，因此它通常是导致 INP 问题的特定原因。
Chrome 团队与多家意见征求管理平台 (CMP) 合作，在用户点击“接受”后让出，以便浏览器在下一次绘制时快速确认用户已接受。请参阅此 PubTech 案例研究作为示例。
如果您的 CMP 受到此影响，请尝试与其联系，看看他们能否同样为嵌入其代码的网站避免 INP 问题。如需有关让出策略的指导，请参阅“优化长任务”一文。
异步加载 Cookie 通知脚本
Cookie 通知脚本应异步加载。为此，请将 async 属性添加到脚本代码中。
<script src="https://example.com/script.js" async>
非异步脚本会阻塞浏览器解析器。这会延迟网页加载和 LCP。如需了解详情，请参阅高效加载第三方 JavaScript。
直接加载 Cookie 通知脚本
应通过将脚本标记放置在主要文档的 HTML 中“直接”加载 Cookie 通知脚本，而不是通过跟踪代码管理器或其他脚本加载。使用跟踪代码管理器或辅助脚本注入 Cookie 通知脚本会延迟 Cookie 通知脚本的加载：它会阻止浏览器的先行解析器对脚本进行加载，并阻止脚本在 JavaScript 执行之前加载。
与 Cookie 通知来源建立早期连接
从第三方位置加载 Cookie 通知脚本的所有网站都应使用 dns-prefetch 或 preconnect 资源提示，以帮助尽早与托管 Cookie 通知资源的来源建立连接。如需了解详情，请参阅尽早建立网络连接以提高感知的网页速度。
<link rel="preconnect" href="https://cdn.example.com/">
根据需要预加载 Cookie 通知
有些网站使用 preload 资源提示加载其 Cookie 通知脚本会大有裨益。preload 资源提示会告知浏览器针对指定资源发起早期请求。
<link rel="preload" href="https://www.example.com/cookie-script.js">
当用途仅限于为每个页面提取几个关键资源时，preload 的功能最为强大。因此，预加载 Cookie 通知脚本的实用性因情况而异。
在设置 Cookie 通知样式时，请注意性能权衡
自定义第三方 Cookie 通知的外观和风格可能会产生额外的性能成本。例如，第三方 Cookie 通知并不总是能够重复使用网页上其他位置使用的资源（例如 Web 字体）。此外，第三方 Cookie 通知往往会在长请求链的末尾加载样式。为避免意外情况，请了解您的 Cookie 通知如何加载并应用样式和相关资源。
避免布局偏移
以下是与 Cookie 通知相关的一些最常见的布局偏移问题：
- 屏幕顶部的 Cookie 通知：屏幕顶部的 Cookie 通知是导致布局偏移的常见原因。如果在周围网页已呈现后将 Cookie 通知插入 DOM，则该通知会将其下方的网页元素推向页面下方。您可以在 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所指示的元素，并等待后续浏览器活动完成。其格式为clickAndWait attribute=Value。
如果您已正确配置此脚本，WebPageTest 截取的屏幕截图应该不会显示 Cookie 通知（已接受 Cookie 通知）。
如需详细了解 WebPageTest 脚本，请参阅 WebPageTest 文档。
设置 Cookie
如需使用 Cookie 集运行 WebPageTest，请前往高级标签页，然后将 Cookie 标头添加到自定义标头字段：
更改测试位置
如需更改 WebPageTest 使用的测试位置，请点击高级测试标签页上的测试位置下拉菜单。
使用 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 通知的潜在设计时，需要考虑以下几点：
- 用户体验：这是否能提供良好的用户体验？这种特殊设计将如何影响现有的页面元素和用户流？
- 财经：您网站的 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 类别细分为特定用例，以便为用户提供更具体的控件，例如允许用户分别选择启用“基本广告”和“个性化广告”。
