同一页面为什么文字先开、图片后到：边缘缓存与回源边界

同一个页面里，标题和正文已经出现，图片仍留着空白，下载文件也没有开始。肉眼容易把它概括成“网页只开了一半”，甚至直接判断整条线路拥塞。实际上，浏览器为HTML、样式、图片和文件分别发出请求，每个请求都可能拥有不同的缓存键、新鲜度与提供位置。

部分内容先到只证明对应请求已经完成。它不能证明页面上的其他资源共享同一边缘服务器、缓存状态或源站路径。判断应从“整页快慢”改成“哪个资源在什么条件下完成”。

页面不是一个不可分割的文件

浏览器取得HTML后，会从文档中发现样式、脚本、字体、图片和媒体地址。每个地址都是独立资源。它们可能来自同一主机，也可能指向不同主机；即使主机相同，缓存规则也可以不同。

文字先显示，常见含义只是HTML与必要样式已经可用。图片较大、发现得较晚、需要新连接或必须回源时，会在后面完成。这个顺序由资源关系与当次请求状态共同形成，不是“文字走好线路、图片走坏线路”的证明。

文件下载通常又有不同条件。大文件可能使用Range请求，也可能根本不适合当前共享缓存。RFC 9111允许缓存保存明确标记的不完整响应或206部分内容，但只有请求范围落在已有部分，或内容后来被补全，才能安全重用。

因此，小图文正常而大文件等待，只能把观察范围缩到大文件请求。它尚不能代表所有页面、所有节点或全部跨境路径同时异常。

边缘副本和源站回答不同问题

共享缓存可以在中间位置保存可重用响应，但它不会改变原始资源由服务器生成这一事实。CDN不是源站替代品；边缘层只能在响应规则与请求条件允许时提供已有副本。

若HTML在边缘已有可用副本，它可以较快返回；图片若没有副本，就可能向源站取得。反过来也可能成立：HTML包含个性化内容而需要回源，公共图片却能直接由边缘提供。不能按资源类型预设谁一定命中。

Resource Timing可以分别记录每个资源的请求阶段与体积。即使响应来自较近的中间位置，连接建立、缓存验证、服务器处理和资源体积仍会影响结果。物理距离不是页面耗时的唯一变量。

标准资料能够说明缓存重用机制，却不能证明CMYNetwork使用某家CDN、某个数据中心或某条海缆。没有响应资料或服务方说明时，文章只能保留架构层面的可能性。

缓存键让同一地址出现多个版本

RFC 9111规定，缓存键至少包含请求方法和目标URI。响应若使用Vary，还会按指定请求字段区分版本。语言、内容编码或其他协商条件不同，都可能让两台设备取得不同变体。

所以“地址相同”不等于“缓存对象完全相同”。电脑与手机发送的请求字段不同，缓存可能无法复用另一台设备触发的响应。页面显示顺序不同，也不能只凭URL相同就排除内容协商。

每个子资源又有自己的URI。HTML命中缓存，不会自动让图片命中；图片已经缓存，也不会替下载文件建立副本。把整页称为一次缓存命中，会遮住真正需要比较的请求单位。

缓存本身还是可选能力。规范描述何时可以存储与重用，并不要求每个实现保存所有合格响应。即使响应看起来是静态文件，站点策略、认证状态或本地配置仍可能阻止共享缓存使用它。

新鲜副本与验证等待要分开

缓存拥有副本后，还要判断它是否新鲜。新鲜响应可以不联系源站直接重用；超过新鲜寿命的响应可能带着验证器联系源站，确认内容未改变后继续使用原正文。

这会造成很典型的错觉：文字和图片“都有缓存”，文字却马上出现，图片仍等了一次网络往返。前者可能仍然新鲜，后者可能正在验证。二者都叫缓存资源，却不是同一种请求路径。

验证成功通常不用再次传输完整正文，但等待源站确认仍会产生延迟。若源站返回新版本，缓存还要接收完整内容。只看最后显示出来的同一张图，无法区分中间发生了验证还是重新下载。

Age字段可以帮助理解响应经过的时间，但它不是本次加载耗时，也不是文件发布日期。没有完整响应头和时序记录时，不应从页面视觉表现补写缓存年龄。

字段不可见也不能改写成缓存命中

Resource Timing为页面取得的资源建立独立条目，并可记录发起类型、请求阶段与大小。它让HTML、图片和文件进入同一套观察方法，但不保证每个字段都对页面脚本开放。

本地缓存模式可以让transferSize为零；跨来源限制同样可能让大小或详细时序不可见。零值只有在许可条件与其他字段相符时，才支持缓存路径判断。字段被隐藏时，正确结论是资料不足。

transferSize、encodedBodySize和decodedBodySize回答不同问题。前者描述当次记录的传输量，后两者区分编码正文与解码正文。图片显示较晚可能与传输体积有关，却不能只按文件外观猜测。

过期响应可能带着验证器联系源站。服务器可以据此判断已有正文能否继续使用；验证过程与完整下载的传输量和等待阶段不同，记录时不能放在同一列。

连接复用也不能改写成缓存命中

多个资源可能复用一条既有连接，从而省去新的连接建立时间。这会让后发请求更快，却不表示响应正文来自缓存。相反，缓存已过期的资源即使复用连接，仍可能等待验证结果。

页面记录应把连接阶段与正文来源分开。没有请求时序和响应字段时，只能写资源完成先后，不能把连接复用、边缘命中或源站回源任选一个当成事实。

高峰时段要比较资源而不是口号

晚间出现变化时，为固定页面中的HTML、代表性图片和一个大文件各留一份记录。每项至少保留URL、开始时间、完成时间、状态码、传输体积、响应中的缓存字段，以及是否第一次加载。

普通时段用同样方法再做一组。若只有大文件持续变化，结论应停在大文件路径或提供端；若多种资源同时变化，才有理由扩大检查范围。一次刷新成功不能抹掉此前记录，一次失败也不能代表整个晚高峰。

比较时不要同时清缓存、换网络、换浏览器和换设备。一次改变多个条件，即使结果恢复，也无法知道哪项变化真正有关。可以先保留普通加载，再单独做一次受控的首次加载对照。

页面开发者工具能提供请求级资料，但它仍只记录当前设备所见。没有运营商、CDN和源站内部数据时，最多能说明哪些请求共享现象，不能定位跨境光纤、海缆或具体机房。

可以写下的结论边界

文字先开、图片后到，可以支持“不同资源完成时间不同”。若响应资料显示HTML由缓存直接重用、图片经过验证，还能进一步说明缓存状态不同。若没有这些字段，就应把原因标成未知。

CDN靠近用户可能减少资源距离，但缓存未命中、验证和源站响应仍会引入等待。路径冗余可以提升可用性，却不承诺每次请求速度相同。

最终记录应回答三个问题：哪个资源变慢，是否发生完整传输或验证，差异是否在重复对照中出现。回答不了的问题继续留空，不用“节点拥塞”“海缆故障”或“CDN失效”填补。

资源计时与缓存边界参考以下规范：

• World Wide Web Consortium，Resource Timing 候选推荐草案，2026年4月20日；用于资源条目与字段边界。
• RFC Editor / IETF，RFC 9111《HTTP Caching》，2022年6月；用于缓存重用与验证规则。

资料来源

• World Wide Web Consortium：《Resource Timing》，发布或更新于 2026-04-20
• RFC Editor / IETF：《RFC 9111: HTTP Caching》，发布或更新于 2022-06-01