我端坐在机房角落的折叠椅上，盯着屏幕上的瀑布流请求图，像法医盯着解剖台上的时间线，机柜风扇的嗡鸣是唯一的背景音，咖啡杯沿积了三天褐色的渍，我是老周，四十岁，干这行十五年，信条只有一条：优化第一，没有第二，用户不会为你的“尽力了”买单，他们只会为那个转圈的菊花图标关掉你的页面,转头走进竞争对手的怀抱。
从7秒到0.8秒，一场关于体面的网站抢救实录
今天的主诉患者是个中型电商站，首页加载7.2秒，跳出率78%，我灌了口凉透的咖啡,开始动刀。
第一刀：诊断，不靠猜，靠“抓包”
我用Chrome的Lighthouse跑三趟，再开DevTools的Performance面板录制滚动和点击交互，别信什么“感觉快了”，数据不会撒谎，诊断出三大病灶：首屏壁纸图是2.4MB的原始JPG；页面底部塞了三个不同的轮播插件，每个都自带一套jQuery；CSS引了五份，其中两份是去年废弃的，这就像一个人穿着三件羽绒服跑百米,不慢才怪。
第二刀：图片与资源压缩合并
我把壁纸图扔进Squoosh，转成WebP，64%质量，肉眼几乎无差别，体积从2.4MB砍到187KB，把五个CSS文件合并成一个app.min.css，三个JS插件统一改用原生JS的Intersection Observer实现懒加载，并把核心JS放到defer，至于那两份废弃CSS？直接在根目录删掉，毫不留情，合并压缩后静态资源总体积减少62%。
第三刀：缓存方案，让服务器学会“记性”
我在Nginx里配置了分层缓存策略，静态资源（图片、CSS、JS）设置Cache-Control: max-age=31536000, immutable——文物级缓存，一年不用回源，HTML页面设置max-age=300，动态数据则走Redis内存缓存，把数据库查询次数打了个对折，最关键的是改了ETag策略，彻底解决304协商缓存每次都触发、白跑一趟的毛病。
第四刀：CDN，把内容“快递”到用户家门口
选了国内某云的CDN，开启智能压缩（Brotli），并做了边缘规则，把一些产品列表页的JSON接口也放到CDN边缘节点，配合Cache-Tag做秒级缓存刷新，部署后，一个上海电信的用户访问，节点命中率从31%飙升到89%，物理距离带来的延迟,从原来平均120ms降到22ms。
第五刀：服务器配置优化
MySQL的innodb_buffer_pool_size从默认的128M调到物理内存的60%，PHP-FPM的pm.max_children按内存上限重新计算，不再让进程饿死或撑满，最后开启Nginx的keepalive并调整worker_processes为CPU核心数，这次是彻底的“换血”。
实测对比（同一台测试机，无痕模式，上海电信百兆宽带）：
- 优化前：首屏时间7.2秒，完整加载时间9.8秒，总请求数78个，页面大小6.8MB。
- 优化后：首屏时间8秒，完整加载时间5秒，总请求数22个，页面大小1MB。
用户从点击到看到商品图，原本能泡一碗面,现在只是眨眨眼。
我把这份报告贴在工位上，旁边写着“优化第一”，这不是工作，是给这个急躁的网络世界，留一丝体面，别再说“能用就行”，那是慢性自杀，数据不骗人，快,才是硬道理。
发表评论