HTML缓存虽非页面速度本身，但直接影响首屏加载和重复访问响应时间；合理配置Cache-Control（如public/max-age或private/max-age）、避免滥用Expires、慎用ETag，并与部署流程对齐，才能真正提升性能。
HTML缓存本身不是“页面速度”，但它直接影响页面速度——尤其是首屏加载和重复访问的响应时间。缓存配置不当，页面再优化也白搭；缓存配对了，哪怕后端慢半拍，用户也可能感知不到。
Cache-Control 设置错，HTML 缓存就形同虚设
很多人以为只要加了 Cache-Control 就算启用了缓存，其实关键在值是否合理：
-
Cache-Control: no-cache不代表“不缓存”，而是每次请求都得向服务器验证（走304流程），对 HTML 这类常更新的内容看似安全，但会增加 RTT 延迟，拖慢重复访问 -
Cache-Control: public, max-age=300更适合静态化后的 HTML（比如 CMS 生成的落地页），5 分钟内完全跳过网络请求 -
Cache-Control: private, max-age=60适合含用户态信息的 HTML（如带登录昵称的首页），避免 CDN 缓存，但允许浏览器本地存 1 分钟 - 千万别对 HTML 设
max-age=31536000（1 年）——HTML 文件极少真正“永久不变”，一旦发版出错，用户可能卡在旧版本几小时甚至更久
Expires 和 Cache-Control 同时存在时，浏览器只认后者
这是 HTTP/1.1 的明确规则，Expires 在现代实践中已基本退居备选：
- 如果响应头里同时有
Cache-Control: max-age=1800和Expires: Wed, 21 Oct 2027 07:28:00 GMT，浏览器以max-age为准，Expires被忽略 -
Expires依赖服务器时钟准确性，跨时区或服务器时间偏差 >1 秒就可能导致缓存提前失效或滞留 - 仅当服务端无法支持 HTTP/1.1（极少见）时，才需 fallback 到
Expires
Last-Modified 和 ETag 对 HTML 缓存验证的实际影响
它们不决定“是否缓存”，而决定“缓存过期后怎么验证”——这点常被误解：
立即学习“前端免费学习笔记（深入）”；
-
Last-Modified精度是秒级，同一秒内多次发布会导致验证失效（服务器返回200而非304），白白重传 HTML -
ETag默认由服务器按文件内容生成（如 Nginx 的etag on），更可靠，但若 HTML 中含微秒级时间戳或随机 token，ETag 每次都变，等于禁用验证缓存 - 对模板渲染型 HTML（如 Express + EJS），建议关闭 ETag，只用
Last-Modified配合构建时写入的稳定时间戳（如从git log -1 --format=%ct获取）
HTML 缓存和页面速度优化不是二选一，而是分层配合
单独压 gzip、上 CDN、开 Brotli，都不如让 HTML 本身少走一次网络请求来得直接。但要注意：
- CDN 缓存 HTML 时，必须确认它支持根据
Cookie或Authorization头做缓存键分离（否则登录页和未登录页可能混用缓存） - Service Worker 可拦截 HTML 请求并注入动态内容，但它和 HTTP 缓存是两套机制——若 Service Worker 返回缓存 HTML，但该 HTML 里引用的 JS/CSS 仍走 HTTP 缓存，版本可能不一致
- 页面速度工具（如 Lighthouse）测的是真实加载耗时，它不会告诉你“这次用了缓存”，但你能从 Network 面板看到
Status是200 (from disk cache)还是304，这才是 HTML 缓存生效的实锤
最易被忽略的一点：HTML 缓存策略必须和部署流程对齐。比如自动构建后 HTML 文件名不变，但内容变了，光靠 max-age 不够——得靠 ETag 或构建时注入版本哈希（如 <link rel="stylesheet" href="/app.css?v=abc123">），否则浏览器根本不知道该不该重新验证。
