页面在地铁站台、信号较弱的室内或网络拥塞时加载缓慢，往往不只是“文件太大”：重复下载、关键内容排在后面、缓存拿错版本，也会拖慢体验。移动网络弱网环境下的资源加载优化，应把压缩和缓存分开判断，再按资源用途组合使用。
压缩省的是单次传输，缓存省的是重复传输
压缩会缩小本次请求需要传输的数据量，适合文本类资源。服务器可按客户端支持情况，对 HTML、CSS、JavaScript 和 JSON 使用 Brotli 或 Gzip。两者都是常见的 HTTP 内容编码方式，客户端和服务器协商可用编码即可；若响应经过缓存，还应正确区分不同编码版本。
缓存则让浏览器在资源仍有效时直接复用本地副本，减少再次请求。它对重复访问、返回上一页或页面共享资源尤其有帮助，但首次访问仍要下载资源。JPEG 图片、MP4 视频等本身已压缩的内容，通常不适合再套一层通用压缩；应优先检查尺寸、码率或是否有更合适的资源版本。
因此，压缩通常更直接地降低单次下载量，缓存更能改善重复访问。移动网络弱网环境下的资源加载优化，不应把“延长缓存时间”当成压缩的替代品，也不能把所有资源统一设成长期缓存。
先分清哪些内容必须先到
弱网下，首屏关键内容与装饰性资源不应争抢同一优先级。可以先让页面结构、主要文字和完成当前操作所需的脚本到达，再加载屏幕下方的图片、非必要动画和较大的字体文件。图片可按显示尺寸提供合适文件，并对首屏以下内容使用懒加载；但首屏主图若被延迟，反而可能让页面显得更慢。
资源优先级要结合页面用途确定：信息页可先显示标题和正文，图文内容再补齐图片；交互页面则应确保必要脚本和表单样式先加载。懒加载能减少初始请求，却不等于所有图片都应延后，离开首屏很近的内容也要留出加载时间。
缓存规则要避免“命中”错误内容
稳定文件可以长缓存，入口页面要便于更新
文件名包含内容哈希的 CSS、JavaScript 等静态资源，内容变化时文件名随之变化，适合设置较长的浏览器缓存期限，并使用 immutable 表明有效期内无需重复验证。HTML 入口通常需要较短缓存期限或重新验证，避免页面仍引用旧资源。具体时长应根据发布频率和回滚要求决定，不宜脱离更新流程统一设定。
确认缓存键覆盖所有影响内容的条件
若同一地址会因压缩格式、语言、设备尺寸或登录状态返回不同内容，缓存必须能够识别这些差异。服务端使用内容协商时，应按实际变化维度设置 Vary；查询参数若会改变资源内容，也不能在缓存键中随意忽略。带有用户专属信息的响应应谨慎设置共享缓存，必要时使用 private 或 no-store，避免其他用户取得不属于自己的内容。
按这个顺序落地和检查
- 列出资源清单：标记 HTML、样式、脚本、图片、字体和媒体文件，记录哪些会影响首屏或当前操作。
- 先减低优先级外的负担：缩小超出显示需求的图片，对首屏以下内容使用懒加载，避免把关键脚本也一并延后。
- 配置文本压缩：为文本响应启用合适的内容编码，检查响应头中的 Content-Encoding 与缓存变体设置是否一致。
- 按更新方式设缓存：带版本标识的静态文件可长缓存；入口文档和经常变化的内容应支持重新验证；个性化响应不要进入不合适的共享缓存。
- 重复验证：分别检查首次访问与再次访问，并在不同网络质量下观察关键内容出现顺序、请求失败和缓存命中情况。更新资源后，再确认旧页面不会继续引用已失效文件。
常见问题
压缩和缓存，哪一个对弱网更重要？
首次访问时，压缩更直接地减少传输量；重复访问时，缓存通常更能减少请求。应按访问方式组合，而不是二选一。
所有文件都应设置长期缓存吗？
不应如此。内容哈希明确的静态文件较适合长缓存；经常变化的 HTML、个性化响应要设置更谨慎的规则。
启用懒加载后，首屏图片也要延迟吗？
通常不应。首屏主图可能影响用户判断页面是否加载完成，应按实际布局优先加载；懒加载更适合首屏以下内容。
怎样判断是否发生资源错配？
对照响应内容、编码、语言或用户状态与缓存键设置，检查不同条件下是否拿到相同缓存结果。移动网络弱网环境下的资源加载优化，最终要同时做到传得少、复用对、关键内容先到。
