从8秒到1.2秒，一个强迫症工程师的网站提速手记

作为在运维圈摸爬了十二年的“老骨头”，我的工作台上永远摆着一杯凉透的浓缩咖啡和一本翻烂了的《HTTP权威指南》，我的性格很奇怪，见不得任何请求超过500毫秒，也听不得任何一张未压缩的PNG在服务器里“呼哧带喘”，就把我们刚给某电商平台做完的一次深度性能体检报告，掰开揉碎了讲给你听。

第一步：诊断，先别急着动刀。 很多站长喜欢一上来就禁用了所有插件，结果网站直接白屏，我的做法是先用Chrome DevTools的Performance面板记录一次完整页面加载轨迹，重点看两个关键指标：TTFB（首字节时间）和LCP（最大内容绘制），我之前碰到过一个案例，TTFB高达2.7秒，但服务器配置明明不差——最后发现是数据库查询里有个没加索引的联表查询，每访问一次首页就要全表扫描。

第二步：图片、JS、CSS的“瘦身”与“合流”。 这是收益最高的一步，原站首页有47张体积不等的图片，我用了三招：

从8秒到1.2秒，一个强迫症工程师的网站提速手记

1. 格式降级：把所有大于100KB的JPG转成WebP，透明背景的PNG转成AVIF（兼容性选项用<picture>标签回退），压缩率从平均85%直接飙升到91%，但肉眼几乎看不出色差。
2. CSS/JS合并：把30个独立的CSS文件按“首屏关键样式”和“非阻塞样式”拆分，用工具合并成2个文件，JS方面，把所有交互逻辑打包进一个bundle，并且加上defer属性，确保不阻塞DOM解析。
3. 图片懒加载：给所有非首屏的图片加上loading="lazy"，并预设好宽高比占位符，避免布局偏移。

第三步：缓存配置，这是给用户“穿越”的机会。 我调整了响应头，对于静态资源（图片、CSS、JS），设置Cache-Control: max-age=31536000, immutable，意味着浏览器一年内不再请求服务器，对于动态HTML页面，设置Cache-Control: no-cache配合ETag，让服务器快速返回304状态码，在Nginx层打开了gzip on和gzip_types，把纯文本压缩率提到60%。

第四步：CDN部署，让用户“就近”拿数据。 我把源站的静态资源全部迁移到CDN，并设置了“回源未命中则缓存至边缘节点”的规则，关键一步是开启了CDN的预压缩功能，在源站直接生成.gz文件，CDN节点直接分发gzip版本，省去边缘节点的压缩耗时。

第五步：服务器配置的“精雕细琢”。 我检查了Apache，果断换成了Nginx，调大了worker_processes和worker_connections，更关键的是开启了open_file_cache，它能在内存中缓存文件描述符，对于大量小图片的访问，命中率翻倍，我关闭了Nginx的访问日志记录（实时写入磁盘太伤I/O），改用异步syslog。

实测数据对比（同一台机器，晚高峰时段，模拟100并发）：

数字不会撒谎,最直观的感受是：原来用户刷首页要盯着白屏发呆，现在几乎是“秒开”，从8秒到1.2秒，这只是第一步，真正的优化出色，不在于用了多炫酷的技术，而在于每一个毫秒背后，都有基于数据实证的决策，你的网站在哪一秒拖了后腿？先把DevTools里的那个红色警告截图发给我看看。