「静态站快」这句话太笼统了。把一次 Wordpress 请求拆开看,才能知道快在哪里。
一次动态请求都发生了什么
- Nginx 把
.php交给 PHP-FPM; - PHP-FPM 拉起(或复用)一个进程,加载 WordPress 核心;
wp-load.php连数据库,读wp_options——通常是一个 2 MB 的autoload数组;- 路由解析:
WP_Query生成 SQL,查文章、查 meta、查 term; - 主题层:模板层级、
get_header()、几十个apply_filters(); - 插件:每个插件在
plugins_loaded和init上挂的钩子; - 渲染成 HTML,输出。
这中间任何一环没命中 opcache 或对象缓存,成本立刻翻倍。而内容可能三个月没变过。
静态站发生了什么
- Nginx 打开一个文件;
- 发出去。
就这两步。没有第 3 步。
数字对比
同一台机器上(2C2G,Nginx,无页面缓存插件):
| 指标 | WordPress | 静态站 |
|---|---|---|
| TTFB | 180–600 ms | 8–20 ms |
| 首页传输 | 90–400 KB | 约 20 KB(HTML + CSS + JS,gzip) |
| 请求数 | 20–40 | 3 |
| 每个请求的 CPU | 5–30 ms | ~0.1 ms |
真正拉开差距的不是传输体积,是每个请求都要重新计算一遍本来不变的答案。
静态站失去的东西
- 评论要另找方案(本站在 Node 后端上做了个极简留言板);
- 发布要跑一次构建;
- 全文搜索要自己实现(这里用客户端索引,文章少的时候完全够)。
这些东西加起来,大概值我一次周末的时间,而换回来的是一台 2G 机器能扛住几百人同时打开首页。
补充:不是所有页面都适合静态
登录、后台、下载计数这些天然是动态的。所以本站的结构是:内容静态,能力动态。文章页是文件,留言和下载走接口。
缓存不是优化,是承认「这个答案不会变」。
COMMENTS留言 (0)
LOGIN REQUIRED