Z-Blog 首屏 3.2s → 0.9s:一次真实的优化记录
摘要
先说结论:这次优化总共只做了四件事——清掉拖慢渲染的插件、给静态资源加缓存与压缩、图片懒加载与尺寸控制、首页减少一次远程请求。没有换服务器,首屏从 3.2s 降到 0.9s。下面是过程与数据。 一、先量,不要猜 用两把尺子: 浏览器 Per
先说结论:这次优化总共只做了四件事——清掉拖慢渲染的插件、给静态资源加缓存与压缩、图片懒加载与尺寸控制、首页减少一次远程请求。没有换服务器,首屏从 3.2s 降到 0.9s。下面是过程与数据。
一、先量,不要猜
用两把尺子:
- 浏览器 Performance 面板:看 LCP 与主线程阻塞时间。
- 命令行
curl -o /dev/null -s -w "%{time_total}":看服务端真实响应时间。
结论很明确:服务端 TTFB 约 0.5s(可接受),问题在资源加载——首页加载了 40+ 个请求,其中 3 个来自外部域(统计、字体、一个已停更的插件接口)。
二、动作一:插件减负
把插件逐个禁用测首屏。发现某个「相关推荐」插件在首屏同步查询了关联表,单次耗时 800ms 左右。改为异步输出后,TTFB 从 0.5s 降到 0.2s。
三、动作二:静态资源缓存 + 压缩
- CSS/JS/图片设置长缓存(带版本号参数)。
- 开启 gzip/brotli,CSS 与 JS 体积下降约 70%。
- 合并主题下零散的 CSS 引用,减少请求数。
四、动作三:图片
- 统一宽度上限,禁止直接上传 3000px 原图在首页缩略显示。
- 首屏以下图片全部
loading="lazy"。 - 给图片容器写死宽高比,避免布局抖动(这正是 LCP 偏高的隐藏原因)。
五、动作四:干掉首屏的远程请求
把统计脚本改为延迟加载,字体改为系统字体栈。首屏请求数从 40+ 降到 18。
六、结果对比
| 指标 | 优化前 | 优化后 |
|---|---|---|
| TTFB | 0.52s | 0.21s |
| 首屏(4G 模拟) | 3.2s | 0.9s |
| 首屏请求数 | 41 | 18 |
最有价值的经验:先定位到具体那一个插件,比盲目装缓存插件有用得多。缓存能掩盖慢,但不能解决慢。
2026年10月22日 10:38
前后30天 · 点日期看归档
9月22日
9月23日
9月24日
9月25日
9月26日
9月27日
9月28日
9月29日
9月30日
10月1日
10月2日
10月3日
10月4日
10月5日
10月6日
10月7日
10月8日
10月9日
10月10日
10月11日
10月12日
10月13日
10月14日
10月15日
10月16日
10月17日
10月18日
10月19日
10月20日
10月21日
10月22日
10月23日
10月24日
10月25日
10月26日
10月27日
10月28日
10月29日
10月30日
10月31日
11月1日
11月2日
11月3日
11月4日
11月5日
11月6日
11月7日
11月8日
11月9日
11月10日
11月11日
11月12日
11月13日
11月14日
11月15日
11月16日
11月17日
11月18日
11月19日
11月20日
11月21日