网站提速前应先评估缓存改动与配置风险

网站访问速度优化常被简化为“把缓存时间调长”。但对包含登录、购物车、库存、价格或个性化推荐的页面来说，缓存改动可能比原有的慢速更危险：用户可能看到旧内容，甚至误读他人的页面状态。因此，提速前应先确认哪些内容能够缓存、缓存多久，以及配置失误后的影响范围。

先区分可缓存内容与不可缓存内容

缓存策略的第一步不是修改配置，而是按内容变化频率和用户差异分类。带版本号的 CSS、JavaScript、字体和图片通常适合长时间缓存，例如文件名包含 app.202609.css 这类版本标识时，更新后可通过更换文件名让浏览器获取新资源。

文章正文、产品说明或公告可能适合短时间缓存，但应考虑发布后的可见延迟。购物车、订单、账户余额、支付结果和含个人信息的页面通常不应被公共缓存。一个页面即使只有顶部导航因登录状态不同，也不能直接套用面向所有访客的整页缓存。

风险通常来自“匹配范围过大”。例如在 Nginx 中把所有 HTML 都设置为公共缓存，可能把登录前页面误用于登录后请求；把带查询参数的地址全部视为同一资源，也可能造成语言、设备或筛选条件混淆。若 CDN 规则忽略 Cookie、Authorization 或部分查询参数，问题会进一步扩大。

另一个风险是更新失效。若首页缓存时间设置为数小时，运营人员发布紧急通知后，用户仍可能继续看到旧版本。若静态文件采用长缓存却没有版本号，浏览器可能保留旧脚本，导致新旧接口不兼容。网站访问速度优化必须同时考虑缓存命中收益与内容正确性。

原则很简单：公开、稳定、无用户差异的资源可以优先缓存；涉及身份、权限、实时状态和交易结果的内容，应优先保证准确性。

建立基线。在固定页面、固定地区和相近网络条件下记录首字节时间、最大内容绘制、页面总请求数、响应状态码和缓存命中情况。单次结果容易受网络波动影响，宜进行多次访问并观察范围。
列出缓存对象。逐项记录 URL 类型、响应头、是否包含 Cookie、是否依赖登录状态、内容更新频率和允许的最大旧数据时间。
检查规则优先级。同时检查源站、反向代理、CDN 和浏览器响应头，确认是否存在一层覆盖另一层的情况。重点关注 Cache-Control、Vary、ETag、Expires 以及是否错误缓存 401、403、500 等响应。
先做小范围灰度。优先选择静态资源或公开内容，在一个路径、一个节点或少量流量上启用新规则。不要一开始就调整全站默认 TTL。
验证正确性。分别测试未登录、已登录、不同语言、移动端与桌面端请求，检查价格、权限、表单、图片版本和发布内容是否一致。
保留回滚入口。记录原配置、发布时间和变更范围，准备缩短 TTL、清理指定缓存或恢复旧规则。回滚动作应由没有参与编写规则的人也能执行。

缓存命中率升高并不代表用户体验一定改善。还应同时观察 TTFB、LCP、源站回源请求量、5xx 比例、缓存清理后的恢复时间，以及页面内容错误反馈。对于静态资源，命中率和下载字节数更有参考价值；对于动态页面，则要重点确认身份和数据是否正确。

如果改动后首字节时间只改善很小，但旧内容投诉、接口错误或回源峰值增加，就不应继续扩大范围。可以改为只缓存图片、字体和带版本号的脚本，或缩短公开页面 TTL。对于更新频繁的内容，主动失效通常比无限延长缓存更稳妥。

不一定。长 TTL 能减少重复请求，但会延长旧内容保留时间。适合长缓存的是带版本号的静态资源，不是所有页面。

可能是首屏仍包含未缓存接口、图片过大、节点距离较远，或缓存只减少了回源却没有改善关键渲染路径。

如果内容正确性或权限受到影响，应先停止扩大流量并恢复安全规则，再按范围清理缓存，避免错误内容继续传播。

不一定。若访问区域集中、静态资源较少，合理设置浏览器缓存和源站压缩可能已经足够；跨地区访问或图片、脚本较多时，CDN 的收益通常更明显。

归根结底，网站访问速度优化应建立在内容分类、配置审查和可回滚验证之上。先确认缓存不会破坏身份、数据与发布流程，再逐步扩大规则范围，往往比一次性延长全站缓存更安全。