页面加载速度，同一地址因设备或登录状态返回不同内容怎样对照
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /adb582686046.html
📄
页面加载速度，同一地址因设备或登录状态返回不同内容怎样对照
直接回答：不要拿“同一地址”当作同一份文档来对照。先固定一个可复现的请求身份（设备类型、是否登录、Cookie 或令牌），再分别记录每次返回的 HTML 主体、关键资源清单和首屏可见内容，最后只比较同一身份下的前后差异。跨身份的差异要单独归类，不能混进速度结论。
矛盾现象：无痕窗口快，登录后慢
常见的情形是：同一 URL 在无痕窗口里测出的加载速度正常，登录后却明显变慢，甚至首屏结构都不一样。此时如果直接把两次数据放进同一张对照表，会得出“优化无效”或“服务器变慢”的错误判断。实际上两次请求很可能命中了不同的文档版本。
这个现象至少有两种成立条件不同的解释：
- 解释一：返回的是不同文档。登录态下服务端渲染了不同的模板，注入了用户专属模块、推荐位或个性化脚本，导致 HTML 体积、阻塞资源数量和执行顺序都变了。此时慢的是那份登录版文档，而不是同一份文档变慢。
- 解释二：返回的是同一份文档，但缓存与请求条件不同。无痕窗口没有本地缓存、没有旧 Cookie，可能命中 CDN 的边缘缓存或走了不同的压缩协商；登录请求绕过缓存直回源站，还额外带上了鉴权跳转。此时文档相同，慢的是链路和缓存命中状态。
能区分两种解释的证据
关键证据是响应本身，而不是总耗时。按下面顺序取一次记录，就能把两种解释分开：
- 保存原始 HTML 主体。把两种身份下返回的 HTML 分别存成文件，比较字节数和首屏关键节点的结构。若结构不同，属于解释一；若结构一致，继续看下一步。
- 看响应头里的缓存与协商字段。对比
Cache-Control、Vary、Content-Encoding以及是否出现Set-Cookie。若登录请求的Cache-Control为私有或禁止缓存，且Vary包含 Cookie，说明差异来自缓存策略，属于解释二。 - 记录关键资源的请求清单。同一份文档若在登录态多出若干阻塞脚本或接口，文档结构可能相同但渲染路径不同，这仍应归入解释一的变体，需要按“文档版本”而非“网络快慢”处理。
一个注明假设的短例子：假设某页面匿名版 HTML 为 80 KB、引用 3 个阻塞脚本；登录版 HTML 为 140 KB、引用 7 个阻塞脚本，且响应头带 Cache-Control: private。此时可以判断，登录态的慢主要来自文档版本与缓存策略的叠加，而不是服务器整体性能下降。这个数字只用于说明比较方法，不代表任何真实站点数据。
对照时最容易遗漏的一个条件
设备类型和登录状态往往不是独立变量。移动端 UA 可能触发不同的模板分支，登录态又可能触发个性化分支，两者叠加会产出四份不同的文档。如果只用“桌面匿名”对照“移动登录”，差异来源就无法归因。
可行做法是先做一张请求身份矩阵，把设备与登录状态拆成独立维度，每格只测一种组合：
- 桌面 + 匿名
- 桌面 + 登录
- 移动 + 匿名
- 移动 + 登录
每个格子内固定相同的地理位置、网络条件和测量工具，再分别记录 HTML 主体、首屏可见内容和关键资源。这样任何一格的变化都能对应到唯一变量。
一个实际动作及其对下一步的影响
先执行这个动作：在登录态下用同一请求头连续取两次响应，比较两次返回的 HTML 是否完全一致。如果两次不一致（例如出现随机推荐位或时间戳），说明该文档本身不可稳定对照，必须先固定随机因素或改测一个稳定子集，再谈速度对比。如果两次一致，就可以把这份登录版 HTML 作为基准，与匿名版做结构化 diff。
这个动作的结果直接决定下一步：文档不稳定时，任何跨身份的速度差值都不能作为优化依据；文档稳定时，才能把差异拆成“文档体积变化”和“链路与缓存变化”两部分分别处理。对照的前提是先把请求身份和文档版本钉死，否则测到的只是两个不同对象的偶然快慢。
