通过跨网站预提取,加快 Largest Contentful Paint (LCP)。
从 Android 版 Chrome 103 开始,Chrome 将逐步推出专用预提取代理功能,将 Google 搜索和其他参与网站的出站导航速度提高 30%(达到中位数)。通过这种专用预提取代理功能,您可以预提取跨源内容,而无需在用户开始导航之前将用户信息暴露给目标网站。
请继续阅读下文,了解此功能的工作原理、此功能如何帮助显著提高网站的 Largest Contentful Paint (LCP),或引荐来源网站如何帮助用户通过加快跨网站导航的速度实现目标。
专用预提取代理的工作原理
安全通信通道
此功能使用 CONNECT
代理在 Chrome 和托管要预提取内容的服务器之间建立安全通信通道。这种安全通信通道可防止代理检查任何数据传输。值得注意的是,虽然专用预提取代理必须看到主机名以便建立安全通信通道,但无法看到完整的网址,也看不到资源本身。
此外,由于安全通信通道是端到端加密的,因此中间方既无法观察主机名,也无法观察预提取网站的内容。最后,代理本身会阻止目标服务器查看用户的 IP 地址。
防止用户识别
除了前面详述的网络方面,我们还需要防止服务器在预提取时通过之前存储在设备上的信息来识别用户。为此,Chrome 目前只允许用户没有 Cookie 或其他本地状态的网站使用专用预提取代理。对于通过专用预提取代理发出的预提取请求,存在以下限制:
- Cookie:预提取请求不能带有 Cookie。
- 如果有针对某项资源的 Cookie,Chrome 将会执行没有凭据的抓取操作,但不会使用相应响应(请参阅后面的缓存部分)。
- 虽然对预提取请求的响应可以包含 Cookie,但这些 Cookie 只有在用户导航到预提取的网页时才会保存。
- 数字“指纹”收集:系统还会调整可用于数字“指纹”收集的其他途径。例如,预提取代理发送的
User-Agent
标头仅包含有限的信息。
未来,我们希望将专用预提取代理扩展到包含 Cookie 或本地状态的链接,同时保持相同的隐私特征。如需了解详情,请参阅后续步骤部分。
缓存
Chrome 会预提取资源(即使这些资源已存在于缓存中),但不会包含任何条件标头,如 ETag
或 If-Modified-Since
(它们包含服务器设置的值,即使没有 Cookie 也能进行跟踪)。进行这种预提取是为了防止将客户端的缓存状态泄露到预提取的网站。此外,仅当用户决定要转到预提取的网站时,Chrome 才会将预提取的资源提交到缓存中。
专用预提取代理使用入门
面向网站所有者
网站所有者无需采取任何行动,即可针对用户没有 Cookie 或本地状态的链接使用私人预提取代理。我们的实验结果表明,对于大多数网站来说,这是一个重要的机会。此外,通过超快的加载体验吸引初访者或不常访问的用户始终是一个不错的选择。通过以往的实验,我们发现使用预提取导航时 Largest Contentful Paint 的速度会提高 20% 到 30%。
未来,我们希望将此功能推广到与 Cookie 或地方州有关的链接,同时保持其隐私特征。Cookie 面临的挑战在于,它们可能会被用来以难以预测的方式改变用户体验。因此,网站所有者很可能需要选择启用或调整其网站,才能为带有 Cookie 的链接使用专用预提取代理。
具体而言,虽然预提取请求将保持无凭据状态,但当用户导航到相应网页时,该网页将可以访问 Cookie 和其他本地状态。开发者可以利用这一点,重新添加基于 Cookie 或本地状态的个性化和更改。或者,开发者可能也希望将某些资源声明为完全可以按原样预提取和使用,而无需 Cookie(即,不依赖于任何 Cookie 的资源)。请查看后续步骤部分,了解详情并制定我们的计划。
与地理位置相关的内容或服务
如果您的网站根据用户的 IP 地址在各市场中表现出不同的行为(例如,内容不同或选择性访问),您可能想知道如何处理专用预提取代理的预提取请求。请务必注意,专用预提取代理由分布在全球各地的多台服务器提供支持,并且代理的 IP 将地理定位到用户发起预提取时所在的国家/地区。
因此,鉴于此,我们向您推荐以下做法:
- 通过是否存在
Sec-Purpose: Prefetch; anonymous-client-ip
HTTP 标头来识别来自专用预提取代理的预提取请求。 - 通过 IP 地址查询发出请求的专用预提取代理的地理位置。如需查看已推出地理位置和相应 IP 地址的最新列表,请参阅此资源。
- 根据与此特定地理位置关联的市场来提供资源。
流量控制
从以往的实验中,我们发现此功能通常会导致对主要资源(例如 HTML 文档)的额外请求不到 2% 的额外请求。也就是说,如果您谨慎行事,可以使用流量建议的比例字段来控制专用预提取代理应通过的流量。您可以先从 0.3(即 30%)等较小的部分开始,然后将以下 JSON 添加到需要使用 application/trafficadvice+json
MIME 类型提供的 /.well-known/traffic-advice
文件中,从而逐步增加到 1.0(即 100%):
[{
"user_agent": "prefetch-proxy",
"fraction": 0.3
}]
fraction
字段是一个介于 0.0(完全无预提取)和 1.0(100% 的预提取请求完成)之间的浮点数。
您还可以通过以下配置完全停用此功能:
[{
"user_agent": "prefetch-proxy",
"disallow": true
}]
/.well-known/traffic-advice
文件由代理(而非客户端)提取,并按照常规的 HTTP 缓存语义在代理处缓存。为了提高灵活性(例如,突然出现大量访问高峰),您可能需要暂时拒绝包含 503 状态代码的预提取请求 (Sec-Purpose: prefetch;anonymous-client-ip
),并在响应中设置 Cache-Control: no-store
标头。您还可以添加 Retry-After
标头,以告知 Chrome 等待多长时间后再重试预提取请求。
对于引荐来源网站所有者
如果您的网站包含大量指向其他网站的链接,不妨使用专用预提取代理功能来加快这些跨源导航的速度。您将需要为网页添加推测规则,以便 Chrome 了解您认为应该通过专用预提取代理预提取哪个网页。以下是一个简单的示例:
<script type="speculationrules">
{
"prefetch": [
"source": "list",
"urls": ["https://example.com/index.html"],
"requires": ["anonymous-client-ip-when-cross-origin"]
]
}
</script>
后续操作
此次发布只是第一步。我们希望根据社区的兴趣和反馈扩大和改进此功能。例如,我们非常希望收到一些反馈,希望我们能够提供一些反馈,说明如何以尽可能减少开发者麻烦的方式扩展至带有 Cookie 和本地状态的链接,或如何使此功能对引荐网站更加有用。