Z-Blog 首屏 3.2s → 0.9s:一次真实的优化记录

· zblog · 阅读 4
摘要

先说结论:这次优化总共只做了四件事——清掉拖慢渲染的插件、给静态资源加缓存与压缩、图片懒加载与尺寸控制、首页减少一次远程请求。没有换服务器,首屏从 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。

六、结果对比

指标优化前优化后
TTFB0.52s0.21s
首屏(4G 模拟)3.2s0.9s
首屏请求数4118

最有价值的经验:先定位到具体那一个插件,比盲目装缓存插件有用得多。缓存能掩盖慢,但不能解决慢。