纯静态也慢，有点想不通

一个活动页全是静态文件，没有接口没有数据库，客户却说打开要三四秒。

我第一反应是「静态还能慢到哪去」，测完才发现，下载段占了大半，首页图加起来好几兆，全是没压缩的原图。

静态页的五段落点

同样是五段，重点完全不同，别拿动态站的结论往上套。

DNS：静态站常挂独立域名，解析慢会把所有资源的起跑线往后推，图片域名尤其明显。

TCP 和 TLS：每个新域名都要建连握手，域名越多，这部分开销越明显，拆分域名有时反而更慢。

TTFB：静态文件也有这一段，取决于磁盘、Web 服务配置，以及有没有回源。

下载：静态页的大头往往在这里，体积、压缩、缓存头一起决定，改起来也最快见效。

TTFB 在静态页里意味着什么

静态页的 TTFB 本该很短，长了就有故事，往往不是磁盘慢。

文件在本地磁盘，正常应该很快，几十毫秒级别，超过太多就有问题。

TTFB 明显偏高，先看是不是回源了，或者被前置的代理、WAF 拖住。

也可能是静态文件没走缓存，每次都重新读盘、重新压缩，白白耗时间。

下载段才是常见大头

这一段的优化，投入产出比最高，几行配置就能见效。

图片没压缩、尺寸超配，是最常见的浪费，手机端尤其吃亏。

文本资源没开压缩，HTML 和 CSS 的体积能省一半以上，改动成本极低。

缓存头配错，用户每次访问都重新下载，明明没改也照下不误。用宝塔拨测的网站测速跑一轮，五段耗时会告诉你时间到底花在哪。

用分组看是不是节点问题

先说清是全局还是局部，再谈手段，否则容易做无用功。

所有地区都慢，问题在文件和配置，跟节点没关系，加节点是浪费钱。

只有某几家运营商慢，是链路，加 CDN 节点比改代码有效，也更省事。

复测与动作

改哪一段，就看哪一段，别用一个总分总结一切。

同一组节点连测三次，确认改动是不是真的有效，别被一次波动骗了。

改压缩和缓存头后，重点看下载段；改节点后，重点看 TCP 和 TTFB，对应关系别搞反。

只优化了一段却盯着总分，很容易得出「没用」的错误结论，然后放弃本来正确的方向。

静态页的优化，说到底是把每一段的开销都摊开看。

摊开之后，改动就有依据了。

有依据的改动，才经得起复测。

复测通过，才算真的提上去了。

提上去之后，用户是能感觉到的。

用户感觉到，优化才算落地。