cookie通知的最佳实践

标准的国际网站都会在初次进入时，在底部弹出cookie相关的接受通知。

本文主要讨论通知对于性能，性能测量和用户体验的影响。
This article discusses how cookie notices can affect performance, performance measurement, and user experience.

性能

通知可能会对页面造成很大的性能影响，因为它们总是会在页面加载的时候显示给所有用户，这样会影响到广告和其他内容的加载。
下面是通知对于WV指标的影响：

• LCP: 一般情况下通知都是很小的，因此它通常不会包含LCP元素。但是在移动端则不同，移动端设备的消息总会占据屏幕的很大一块，通常这种情况都是发生在文本内容过多的情况，因此它也会影响到LCP。
• FID：通常来讲，消息的弹入弹出对FID都会有一点影响，毕竟要通过JS代码的调用来控制。像广告和跟踪脚本如果使用了通知的话，可能会对页面的影响有显著影响。延迟加载这些脚本一定程度上可以优化FID。
• CLS：确认通知是布局偏移的一种常见情况

一般来讲，你自己的通知对于页面的影响是可控的，但是第三方的脚本就不一样了，基于其实现可能会对页面起到很大的影响。这不是通知的原因，主要还是第三方脚本不可控。

最佳实践

本文中的最佳实践主要集中于第三方的脚本通知。实现的一部分对于自己的脚本也有一定作用。

异步加载脚本

通知脚本应该异步加载，你可以通过添加async的标识实现：

<script src="https://cookie-notice.com/script.js" async>

非异步脚本会阻塞浏览器解析。这会延迟页面加载和 LCP。更多信息请阅读 Efficiently load third-party JavaScript。
如果你一定要使用同步脚本的话（例如，脚本间有相互依赖关系），你应该确保脚本尽可能快的加载。一种方式就是使用preconnect、prefetch

直接加载脚本

你的部分脚本可以直接内联写在html里面，而不是使用script引入，或者动态引入。使用脚本引入或者动态入住的话会影响到其他脚本的加载：脚本的下载解析都会阻塞其他内容的解析。

提前建立连接

所有的网站在加载第三方的资源的时候，都应该使用dns-prefetch、preconnect等标识去提前与第三方监理连接。更多内容请阅读 Establish network connections early to improve perceived page speed.

<link rel="preconnect" href="https://cdn.cookie-notice.com/">

脚本从多个资源站点加载内容是一件很正常的事—比如，从a站点和b站点加载内容。每一个站点都需要独立的链接，因此需要提前建立以节约时间。

根据需要预加载脚本

一些网站觉得使用preload预加载脚本非常有用。这个标记可以让浏览器提前与服务端建立连接下载资源。

<link rel="preload" href="https://www.cookie-notice.com/cookie-script.js">

使用preload预加载指定的关键资源时，它是最有用的。但是，有没有用终归还是取决于实际的使用姿势，毕竟加载多了一样有问题。

为通知添加样式的时候应该注意衡量性能

自定义的通知外观可能会造成额外的性能消耗，并且第三方的脚本又总是不能复用资源。此外，第三方的通知脚本总会在链接后面加样式。为了避免出问题，要注意你的脚本是怎么样使用样式和加载资源的。

防止布局偏移

下面是一些通知的常见问题：

• 屏幕顶部通知：屏幕顶部通知是布局偏移的常见来源之一。在页面加载好之后插入通知，会造成后续元素的偏移。可以在DOM中预留空间来解决这个问题，但是这并不是一个好的解决方案，这种布局偏移的问题可以通过将DOM设置为绝对定位等模式来解决。通知在加载的时候不应该造成任务位移。
• 动画：许多通知都是使用动画的—比如，通知的划入是一种很常见的设计模式。基于其实现方式，有可能会造成布局位移。更多内容阅读 Debugging layout shifts.
• 字体：延迟加载字体可能会阻止渲染和/或导致布局偏移。这种现象在慢速连接上更为明显。

加载优化

以下技术花点时间实现可以有效改善加载性能：

• 缓存脚本
• 使用service worker缓存脚本

性能测量

通知可能会影响性能测量。本节讨论其中的一些影响和减轻影响的技术。

真实用户监控 (RUM)

一些分析和 RUM 工具使用 cookie 来收集性能数据。如果用户拒绝使用 cookie，这些工具将无法捕获性能数据。
网站应该注意下这种情况：了解您的RUM工具收集数据的机制是值得的。对于一个网站来说，使用不使用cookie可能不是很重要，首先性能测量中cookie并不是必须的，其次你可以使用web-vitals来测量性能。
基于你的网站使用cookie收集性能数据的方式和相关立法的问题。使用 cookie 进行性能测量可能不受与某些网站相同的立法要求的约束。在您的网站上用于其他目的的 cookie——例如，广告 cookie。某些网站在征求用户同意时选择将性能 cookie 作为单独的 cookie 类别。

监控合成

如果没有自定义配置，大多数工具（例如 Lighthouse 和 WebPageTest）将仅衡量未响应 cookie 同意通知的首次用户的体验。但是，在收集性能数据时，不仅需要考虑缓存状态的变化（例如，初始访问与重复访问），还需要考虑 cookie 接受情况——接受、拒绝或未响应。
以下部分讨论了 WebPageTest 和 Lighthouse 设置，它们有助于将 cookie 合并到性能测量工作流中。但是，cookie 和 cookie 通知只是在实验室环境中难以完美模拟的众多因素之一。因此，重要的是让RUM 数据成为性能基准测试的基石，而不是工具。

使用WebPageTest测试cookie通知

脚本

您可以使用脚本让WebPageTest在收集跟踪时“单击”cookie 同意按钮。
通过转到脚本选项卡添加脚本。下面的脚本导航到要测试的 URL，然后单击带有 id 的 DOM 元素。
注意：WebPageTest 脚本是以制表符分隔的。

combineSteps
navigate    %URL%
clickAndWait    id=cookieButton

使用此脚本时请注意：

• combineSteps告诉 WebPageTest 将脚本步骤的结果“组合”到一组跟踪变量中。运行这个脚本combineSteps也很有用——单独的跟踪可以很容易地查看资源是在接受 cookie 之前还是之后加载的。
• %URL% 是 WebPageTest 约定，指的是正在测试的 URL。
• clickAndWait告诉 WebPageTest 单击由指定元素并等待后续活动完成。它遵循格式clickAndWait attribute=Value。

如果你已经正确的配置了脚本，则 WebPageTest 截取的屏幕截图不应显示 cookie 通知（cookie 通知已被接受）。
更多内容阅读 WebPageTest documentation.

设置cookie

要使用 cookie 收集并运行 WebPageTest，请转到“高级”选项卡并将 cookie 标头添加到“自定义标头”字段：

更改测试位置

要更改 WebPageTest 使用的测试位置，请单击“高级测试”选项卡上的“测试位置”下拉菜单。

使用Lighthouse测试cookie通知

在 Lighthouse 运行时设置 cookie 可以作为一种让页面进入特定状态以供 Lighthouse 测试的方法。Lighthouse 的 cookie 行为因上下文（DevTools、CLI 或 PageSpeed Insights）而异。

开发工具

从 DevTools 运行 Lighthouse 时不会清除 Cookie。但是，默认情况下会清除其他类型的存储。可以使用Lighthouse设置面板中的清除存储选项更改此行为。

命令行

从 CLI 运行 Lighthouse 使用全新的 Chrome 实例，因此默认情况下不会设置 cookie。要使用特定 cookie 集从 CLI 运行 Lighthouse，请使用以下命令：

lighthouse <url> --extra-headers "{\"Cookie\":\"cookie1=abc; cookie2=def; \_id=foo\"}"

有关在 Lighthouse CLI 中设置自定义请求标头的更多信息，请阅读 Running Lighthouse on Authenticated Pages。

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 横幅不会向用户提供直接的 UX 控件来选择或关闭 cookie。相反，它们通常包含指向站点 cookie 政策的链接，该链接可能会向用户提供有关使用他们的网络浏览器管理 cookie 的信息。这些通知通常包括“拒绝”和/或“接受”按钮。

部分可配置

一些 cookie 通知为用户提供拒绝 cookie 的选项，但不支持更精细的控制。这种 cookie 通知方法不太常见。

完全可配置

这些 cookie 通知为用户提供了更细粒度的控制来配置他们接受的 cookie 使用。

• UX: 用于配置 cookie 使用的控件最常使用单独的模式显示，当用户触发cookie 同意通知时启动该模式。但是，如果空间允许，某些站点将在初始 cookie 同意通知中内嵌显示这些控件。
• 粒度: cookie 可配置性的最常见方法是允许用户按 cookie“类别”选择加入 cookie。常见 cookie 类别的示例包括功能、目标和社交媒体 cookie。但是，有些网站会更进一步，允许用户根据每个 cookie 选择是否加入。另一种为用户提供更具体控制的方法是将“广告”等 cookie 类别分解为特定用例——例如，允许用户分别选择“基本广告”和“个性化广告”。