Core/Dash 维度: 回访访客

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

回访访客维度将您的性能数据分为两个群体：之前访问过您网站的用户和未访问过的用户。这两组之间的工程差异在于浏览器缓存。回访访客从磁盘加载您的字体、脚本和图片。新访客则从网络获取每一个字节。

这很重要，因为您的汇总 LCP 分数是两者的加权平均值。如果 40% 的会话来自新访客，他们的冷缓存加载时间正在拉高您的 p75。没有这个维度，您无法判断 LCP 回归是真正的基础设施问题还是新用户获取的临时峰值。

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

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

在 CoreDash 监测网站的数据中，回访访客在相同页面上的 LCP 分数通常比新访客低 35% 到 60%。在图片密集型页面上，当主图较大且源服务器与用户地理距离较远时，差距最大。在使用服务器端渲染且 LCP 元素为文本的页面上，差距会缩小，因为两组的文本加载延迟都接近于零。

两组之间的 INP 差异较小但仍然存在。新访客在首次加载时通常会触发更多的 JavaScript 解析，因为模块包是首次被评估的。回访访客受益于 V8 的代码缓存，它存储编译后的字节码并完全跳过解析和编译步骤。在 JavaScript 密集型页面上，这可以减少 50ms 到 150ms 的处理时间。

解读三个值

0：回访访客

浏览器报告这不是用户在您源站上的第一次会话。缓存资源可用。在 CoreDash 跟踪的大多数营销和编辑网站上，回访访客占所有会话的 55% 到 70%。他们的性能数据是您的热缓存基准：了解您网站的真实用户的最佳场景。如果您的 LCP 在这里表现不佳，问题不在缓存。请检查渲染阻塞资源、服务器响应时间或渲染延迟。

1：新访客

没有缓存。浏览器从网络获取每个资源。这是您的冷缓存最差情况，代表了每个通过自然搜索、付费广告或社交分享找到您的用户的第一印象。新访客通常占会话的 30% 到 45%。他们在基于图片的页面上的 LCP 分数比回访访客高 300ms 到 700ms。如果您的新访客 LCP 未通过 2.5s 阈值但回访访客 LCP 通过了，您的优化目标很明确：减少 LCP 资源本身的大小和延迟，因为您不能依赖缓存来服务这部分受众。

2：未测量

CoreDash 无法确定此会话的访问类型。这通常发生在浏览器阻止了区分新访客和回访访客所需的存储访问权限时，或者当注重隐私的浏览器配置阻止了检查时。在大多数网站上，此类别低于会话的 5%。将其视为噪声底线而非需要优化的细分群体。

调试工作流程

1. 建立基准分布：在 CoreDash 中打开回访访客维度，记录新访客与回访访客会话的百分比。如果新访客超过 50% 的流量，冷缓存性能是您主要的用户体验，必须作为首要优化目标。
2. 按访问类型比较 LCP：仅筛选新访客并记录 p75 LCP。然后筛选回访访客并记录相同指标。差距超过 500ms 表明资源大小或网络获取时间是瓶颈。差距低于 200ms 表明渲染端问题同样影响两组。
3. 直接针对 LCP 资源：对于 LCP 较慢的新访客，解决方法是减少资源加载时间。压缩 LCP 图片，从靠近用户的 CDN 边缘节点提供服务，并应用 fetchpriority="high"。无论缓存状态如何，这些改进都持续有效。不要依赖缓存来弥补过大或服务缓慢的 LCP 资源。
4. 使用导航类型维度验证：与导航类型维度交叉参考。重新加载和前进后退导航倾向于回访访客。如果您的回访访客 LCP 意外缓慢，高比例的重新加载导航（缓存资源被重新验证而非直接提供）可能是原因。

工程经验法则

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

回访访客维度是当网站在 LCP 上显示临界通过时我首先应用的筛选器之一。汇总的实际数据隐藏了真实情况。按访问类型分割立即显示优化工作是否扎实，还是网站依靠忠实回访受众的缓存命中而让每个从搜索到达的新用户都失败了。