页面不是一次请求
首页文字很快出现，大文件却一直停在下载中，并不矛盾。浏览器先取得主HTML，再按文档里的地址请求样式、脚本、字体、图片和文件。每个地址都有自己的主机、缓存状态、连接复用和响应大小。主文档完成只能证明其中一条请求链可用，不能替其余资源作结论。
先保存精确URL，而不是只写“首页”或“下载”。同一页面里的图片可能来自静态资源主机，文件可能来自对象存储，接口还可能使用另一域名。即使域名相同，路径和缓存规则也可以不同。若记录时把它们合在一起，文字正常与文件变慢就会被压成含义不清的“网站偶尔卡”。
发起者也要保留。HTML直接引用、CSS继续引用字体、脚本运行后再请求数据，出现的时间和前置条件不同。某个资源晚开始，可能是在等待上游脚本执行，并非它的网络阶段本身很慢。
用资源计时分开阶段
W3C Resource Timing为单个资源提供多组时间点，包括DNS、连接、请求开始、首字节与响应结束。常用字段包括 domainLookupStart、connectStart 和 requestStart。首字节与响应结束则看 responseStart 和 responseEnd。DNS段表示浏览器为该资源查询名称的可见时间。requestStart到responseStart可观察请求发出至首个响应字节；responseStart到responseEnd描述响应主体到达的后半段。
这些差值要按资源分别看。DNS或连接阶段长，方向在解析或连接准备；首字节前等待长，可能涉及网络往返、缓存转发或服务器处理；首字节很快而结束很晚，更接近正文体积、链路吞吐或传输中停顿。浏览器看得到的是阶段边界，不会揭示服务器内部每一个队列，因此结论应停在“时间集中在哪一段”。
DNS阶段为零不代表没有DNS。浏览器可能复用先前解析结果，连接也可能已为同一主机建立。两台设备一台显示查询、另一台不显示，可以来自缓存和连接复用差异。复测时要写明是否新会话、是否同一浏览器配置，不能把零直接当成解析器更快。
跨源资源还可能因Timing-Allow-Origin缺失而隐藏部分字段。缺值与耗时为零不是同一件事。若第三方图片只显示总时长，应标注“细分计时不可见”，不要凭空补成DNS或源站判断。
传输量和正文大小回答不同问题
Resource Timing同时提供transferSize和encodedBodySize。前者包含本次获取可见的传输量语义，后者描述压缩编码下的正文大小。若正文大小存在而传输量很小或为零，缓存复用是一个解释方向；若两者都很大，文件确实需要更多传输。但零值还可能受跨源权限或实现条件影响，必须连同deliveryType、响应头和字段可见性读取。
图片慢与大文件慢也不能只按“都是静态资源”归类。图片可能已经在边缘缓存，大文件可能需要Range范围请求；图片正文几十KB，文件却有数百MB。相同首字节时间下，后者的responseEnd自然更晚。比较时应选同一个精确URL，不能用不同大小的文件证明某台设备更快。
缓存新鲜不等于源站刚更新
RFC 9111把缓存响应的年龄未超过新鲜寿命称为fresh。新鲜响应可以直接满足后续请求，缓存复用时Age反映估计的当前年龄。Age不是文件发布日期，也不证明具体经过哪个CDN；它描述的是这份响应在缓存链中的年龄信息。
两台设备访问同一URL，一台已有浏览器缓存，另一台需要网络请求；或者两次请求落到不同共享缓存，进入缓存的时间也不同。因此文字和样式可能立即复用，文件却重新验证或回到上游。记录Cache-Control、Age、ETag、Last-Modified和状态码，比只看“命中/未命中”标签更完整。
缓存未命中也不等于源站故障。它只说明这一层没有直接复用合适响应，后续仍可能由上游缓存或源站正常回答。反过来，缓存命中证明拿到了可复用副本，不保证页面里其他资源也命中，更不保证副本符合用户期待的版本。
大文件可能使用部分响应
RFC 9111允许缓存明确标记的不完整响应或206部分内容，但只有请求范围落在已有部分，或缓存后来补全内容时，才能用来回答。大文件的Range、续传和分段缓存因此与小型HTML不同。下载停在中途，可能发生在后续范围、连接恢复或上游取回，主页面仍可完全正常。
检查文件时应保存状态码、Content-Range、Accept-Ranges、请求的Range以及实际收到字节。第一次返回206不等于失败，它可能正是客户端请求的一段；关键是后续范围能否继续、范围是否连续、最终大小是否符合预期。若浏览器界面只显示“下载中”，网络记录才有足够细节区分等待首字节和正在慢速传输。
不要用清缓存作为第一结论。清除后现象改变，只能说明本地状态参与了结果；它仍不能证明CDN或源站原先错误。保留清除前记录，再用无痕会话或另一浏览器做对照，证据才不会随操作消失。
跨设备对照要锁定同一资源
建立一张资源表，先写精确URL、发起者、主机、DNS时间、连接时间、首字节等待和传输时间。再补充transferSize、encodedBodySize、状态码、Age、Cache-Control、Range与设备条件。首页文字、图片和文件各选一个代表URL，分别重复两次，观察第二次是否因缓存或连接复用改变。
这张表的核心机制可以概括为：主文档触发多个资源URL；各URL经过自己的解析与连接，再由浏览器缓存、共享缓存或源站回答，最后按资源大小和范围传输完成。它不是一条从DNS直达“页面完成”的单线流程，而是一组可以并行、复用或等待前置脚本的请求。
页面文字完成回答主文档和关键渲染资源是否可用。单个文件的responseStart与responseEnd回答该资源的等待和传输，两类结果不能互相替代。若首页在一秒内可读，只能说明关键路径达到可见状态；一个未显示在首屏的大文件仍可能刚开始请求，甚至尚未被脚本触发。
复测还应区分冷启动和温启动。冷启动尽量使用没有现成连接与资源副本的新会话，观察解析和首次连接；温启动紧接着访问同一URL，观察连接复用、重新验证和缓存。两组数据都需要，只有冷启动会忽略真实回访状态，只有温启动又会把偶然的旧副本当成网络能力。
服务工作线程也可能从自己的缓存或合成响应回答资源。若站点使用这类前端逻辑，网络面板里的请求发起者、deliveryType和worker相关时间点应一并保存。它能解释“浏览器显示成功但没有常规网络传输”的一部分情况，却仍不能由此推断资源一定新鲜。
当两台设备结果不同，先核对它们请求的URL、查询参数、重定向终点和Range是否一致。一个版本参数差异就会形成另一缓存键；一个文件请求从0开始，另一个从已下载位置续传，响应条件也不同。对齐请求身份后，再比较设备、解析器和网络才有意义。
如果设备A只有文件的首字节等待变长，而主文档与图片相近，问题范围应收窄到文件请求链；若同一主机所有资源的DNS段都变长，可再比较解析器和网络；若首字节相近但大文件传输段持续拉长，则应关注体积、范围请求和链路，而不是把DNS当成主因。
最终行动很简单：按精确URL保存计时阶段、传输量、状态码、Age、Cache-Control与设备条件，再在相同网络复测同一资源。DNS时间为零、transferSize为零或缓存未命中都需要结合复用、跨源权限和响应头解释，不能单独定位故障。缺少字段时就标记不可见，不用别的资源结果补齐。
浏览器计时不能替代运营商路由测量，DNS答案也不是完整网络路径。页面资源还可能来自不同CDN和源站。可靠结论不是“整站正常”或“CDN坏了”，而是明确到某个URL、某个时间窗、某个阶段与某台设备。只要保持这种粒度，文字正常、图片稍慢和文件停滞就能同时被解释，而不会互相否定。
资料来源
- World Wide Web Consortium：《Resource Timing》，发布或更新于 2026-04-02
- RFC Editor / IETF：《RFC 9111: HTTP Caching》，发布或更新于 2022-06-01