Core/Dash 维度： 回访访客

维度：用户行为：回访访客 (fv)

回访访客维度将你的性能数据分为两类人群：访问过你网站的用户，以及未访问过的用户。这两组人在工程上的区别是浏览器缓存。回访访客从磁盘加载字体、脚本和图片。新访客从网络获取每一个字节。

这很重要，因为你汇总的 LCP 分数是两者的加权平均值。如果你的会话中有 40% 是新访客，他们的冷缓存加载时间就会拉高你的 p75。如果没有这个维度，你无法判断 LCP 恶化是真正的基础设施问题，还是新用户获取量的短暂飙升。

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

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

在 CoreDash 监控的各个网站数据中，回访访客在相同页面上的 LCP 分数通常比新访客低 35% 到 60%。在图片密集、首屏大图庞大且源服务器地理上远离用户的页面中，差距最大。在采用服务端渲染且 LCP 元素为文本的页面上，由于两组的文本加载延迟都接近零，差距会缩小。

两组之间的 INP 差异较小，但依然存在。新访客在首次加载时，由于模块包是首次评估，通常会触发更多的 JavaScript 解析。回访访客则受益于 V8 的代码缓存，它存储编译好的字节码，完全跳过解析与编译步骤。在 JavaScript 繁重的页面上，这可以减少 50 到 150 毫秒的处理时间。

解读这三个值

0：回访访客

浏览器报告这不是用户在你源站上的首次会话。缓存资源可用。在 CoreDash 跟踪的大多数营销和编辑类网站上，回访访客占所有会话的 55% 到 70%。他们的性能数据是你的热缓存基准：这是熟悉你网站的真实用户的最佳情况。如果你的 LCP 在这里表现很差，问题就不在缓存。去排查 render blocking 资源、服务器响应时间或渲染延迟。

1：新访客

无缓存。浏览器从网络获取每个资源。这是你的冷缓存最坏情况，代表了通过自然搜索、付费广告或社交分享找到你的每个用户的第一印象。新访客通常占会话的 30% 到 45%。在以图片为主的页面上，他们的 LCP 分数比回访访客高 300 到 700 毫秒。如果新访客 LCP 未通过 2.5 秒阈值，而回访访客 LCP 通过了，优化目标就很明确：减小 LCP 资源本身的体积并缩短其延迟，因为你不能指望通过缓存来服务这部分受众。

2：未测量

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

调试工作流

1. 建立基准比例：在 CoreDash 中打开回访访客维度，记下新会话与回访会话的百分比。如果新访客超过流量的 50%，冷缓存性能就是主导的用户体验，必须成为首要优化目标。
2. 按访问类型比较 LCP：过滤出仅新访客，记录 p75 LCP。然后过滤出回访访客，记录相同的指标。超过 500 毫秒的差距表明资源大小或网络获取时间是瓶颈。低于 200 毫秒的差距则暗示对两组影响同等的渲染端问题。
3. 直接针对 LCP 资源：对于 LCP 慢的新访客，修复方法是缩短资源加载时间。压缩 LCP 图片，通过靠近用户的 CDN 边缘节点分发，并应用 fetchpriority="high"。无论缓存状态如何，这些收益都持续存在。不要依赖缓存来弥补尺寸过大或分发缓慢的 LCP 资源。
4. 使用导航类型维度验证：与 导航类型 维度交叉比对。重载和前进后退导航会向回访访客倾斜。如果你的回访访客 LCP 看起来异常缓慢，高比例的重载导航（缓存资源被重新验证而不是直接分发）可能是原因。

工程经验法则

• 新访客 LCP 目标：p75 低于 2.5 秒。这比回访访客 LCP 更难达到，需要实际的基础设施工作：CDN、图片优化和正确的获取优先级。
• 新访客与回访访客之间可接受的 LCP 差距：最高 400 毫秒。更大的差距表明你的网站依赖浏览器缓存来通过 Core Web Vitals，这意味着第一印象正在失败。
• 未测量低于 5%：如果这个桶增长到 10% 以上，请调查 Cookie 同意实现或存储权限变更是否在阻塞访问类型检测。

当一个网站在 LCP 上刚及格时，回访访客维度是我首先应用的过滤器之一。聚合的 field data 掩盖了真相。按访问类型拆分能立刻揭示优化工作是否扎实，还是网站只靠忠实回访受众的缓存命中勉强过关，却让每个通过搜索访问的新用户体验糟糕。