Core/Dash 维度： 重复访问者

分离新访问者与回访者的性能数据，找出冷缓存加载时间在何处拖累了您的真实用户数据。

免费试用

Trusted by market leaders · Client results

happyhorizonnestlekpnharvardsaturnloopearplugsaleteianina carevpnsnvadevintamy work featured on web.devebayfotocasawhowhatwearmonarchworkivaerasmusmcmarktplaatsdpg mediacompareperion

维度：用户行为：重复访问者 (fv)

重复访问者维度将您的性能数据分为两类人群：以前访问过您网站的用户和未曾访问过的用户。这两组群体在工程学上的差异在于浏览器缓存。回访者从磁盘加载您的字体、脚本和图像。而新访问者则通过网络获取每一个字节。

这很重要，因为您的汇总 LCP 分数是两者的加权平均值。如果 40% 的会话是新访问者，他们的冷缓存加载时间就会拉高您的 p75 数据。如果没有此维度，您将无法分辨 LCP 退化是真正的基础设施问题，还是由于获取新用户带来的暂时性激增。

为什么性能差距比您预期的还要大

浏览器缓存为回访者消除了整个请求链。在一个典型的内容网站上，重复访问者会跳过每个缓存资源的 DNS 查找、TCP 握手、TLS 协商和服务器响应。LCP 资源本身通常在 5 毫秒内从内存缓存中提供，而不是通过网络花费 200 到 800 毫秒。这并非微不足道的改善：这是页面加载方式上的结构性差异。

在 CoreDash 监控的站点数据中，同一页面上回访者的 LCP 分数通常比新访问者低 35% 到 60%。在首屏图像较大且源服务器在地理位置上距离用户较远的重图像页面上，这种差距最为明显。在采用服务器端渲染且 LCP 元素为文本的页面上，由于两组的文本加载延迟都接近于零，因此差距会缩小。

两组之间的 INP 差异较小，但仍然存在。新访问者在首次加载时由于模块包首次被执行，通常会触发更多的 JavaScript 解析。回访者则受益于 V8 的代码缓存，它存储了编译后的字节码并完全跳过了分析和编译步骤。在重 JavaScript 页面上，这可以缩减 50 到 150 毫秒的处理时间。

解读这三个值

0：Repeat Visitor（重复访问者）

浏览器报告这并不是用户在您源站上的首次会话。缓存资源可用。在 CoreDash 追踪的大多数营销和编辑网站上，重复访问者占所有会话的 55% 到 70%。他们的性能数据就是您的热缓存基线：这是了解您网站的真实用户所能体验到的最佳情况。如果这里的 LCP 很差，那么问题不在于缓存。请转而检查阻塞渲染的资源、服务器响应时间或渲染延迟。

1：New Visitor（新访问者）

无缓存。浏览器从网络获取所有资源。这是您的冷缓存最坏情况，代表了通过自然搜索、付费广告或社交分享找到您的每个用户的第一印象。新访问者通常占会话的 30% 到 45%。在以图像为主的页面上，他们的 LCP 分数比重复访问者高出 300 到 700 毫秒。如果您的新访问者 LCP 未能达到 2.5 秒的阈值，但您的重复访问者 LCP 通过了，那么您的优化目标很明确：减小 LCP 资源本身的体积和延迟，因为您无法依靠缓存来为这批受众提供服务。

2：Not Measured（未测量）

CoreDash 无法确定此次会话的访问类型。这通常发生在浏览器阻止了区分新访问者和回访者所需的存储访问权限时，或者当注重隐私的浏览器配置阻止了该检查时。在大多数网站上，这部分在会话中的比例不到 5%。将其视为本底噪声，而不是要去优化的细分市场。

调试工作流

  1. 确定您的基准划分：在 CoreDash 中打开重复访问者维度，并记录新会话与重复会话的百分比。如果新访问者占流量的 50% 以上，那么冷缓存性能就是主导您 user experience 的因素，并且必须成为主要优化目标。
  2. 按访问类型比较 LCP：过滤出仅新访问者的数据并记录 p75 LCP。然后过滤出重复访问者并记录相同指标。超过 500 毫秒的差距表明资源体积或网络获取时间是瓶颈。低于 200 毫秒的差距则表明渲染端问题对两组都有同等影响。
  3. 直接定位 LCP 资源：对于 LCP 缓慢的新访问者，修复方法是减少资源加载时间。压缩 LCP 图像，通过靠近用户的 CDN 边缘节点提供服务，并应用 fetchpriority="high"。无论缓存状态如何，这些改进都会持续生效。不要依赖缓存来弥补过大或响应缓慢的 LCP 资源。
  4. 通过 Navigation Type 维度进行验证：与 Navigation Type 维度进行交叉对比。重新加载（Reload）和后退/前进导航倾向于重复访问者。如果您的重复访问者 LCP 看起来出乎意料地慢，原因可能是占比很高的重新加载导航（此时缓存的资源需要重新验证，而不是直接提供服务）。

工程经验法则

  • 新访问者 LCP 目标：p75 低于 2.5 秒。这比重复访问者 LCP 更难实现，需要实际的基础设施工作：CDN、图像优化以及正确的提取优先级。
  • 新访问者和重复访问者 LCP 之间可接受的差距：最多 400 毫秒。更大的差距表明您的网站依赖浏览器缓存来通过 Core Web Vitals，这意味着第一印象表现不佳。
  • Not Measured 低于 5%：如果该部分增长到 10% 以上，请调查是否是 cookie 同意实现或存储权限变更阻止了访问类型的检测。

当一个网站的 LCP 处于勉强通过的边缘时，重复访问者维度是我最先应用的过滤器之一。聚合的现场数据掩盖了真实情况。按访问类型进行拆分，可以立即显示出优化工作是否扎实，或者网站是否在依赖忠实回访者的缓存命中率勉强过关，同时却在每一个通过搜索到访的新用户面前遭遇失败。