我是陈默,一个常年和服务器日志、瀑布图打交道的网站性能优化工程师，性格里带着点偏执——看到加载超过2秒的页面就手痒，看到没压缩的图片就想右键另存为再跑一遍工具，今天不聊虚的，直接拆解我们团队上个月对一家中型电商站的优化过程，他们老板原话是：“再慢下去，投的广告费全给谷歌交学费了。”
先诊断，别急着开药
网站速度诊断,最忌讳凭感觉，我用的三板斧：Lighthouse跑分、WebPageTest多地域测速、Chrome DevTools的Performance面板录屏，重点看三个指标：TTFB（首字节时间）、LCP（最大内容绘制）、TBT（总阻塞时间），那个电商站初始数据：LCP 3.8秒，TBT 1.2秒，首屏图片总大小4.7MB，诊断结论很清晰——图片没压、JS没拆、服务器在裸奔。
网站优化优化服务，从3.8秒到0.9秒，一次真实的性能救赎
图片、JS、CSS的压缩与合并
图片是头号杀手,他们首页轮播图单张2.3MB，还是PNG，我换成WebP格式，配合<picture>标签做降级，再用Sharp工具批量压缩到原体积的18%，注意：不是所有图都无脑压，商品细节图保留85%质量，背景图压到60%。
JS和CSS方面,他们引了7个独立JS文件、4个CSS文件，我做了三件事：1）用Terser压缩JS，去掉console和注释；2）CSS用cssnano压缩，合并重复媒体查询；3）把首屏关键CSS内联进<head>，非关键CSS异步加载，合并后文件数从11个降到3个，但要小心：HTTP/2下不必过度合并，否则缓存粒度太粗，我保留了商品详情页的独立JS块。
缓存配置方案
他们原来的缓存策略是Cache-Control: max-age=0，等于没配，我改成：静态资源（图片、字体、带hash的JS/CSS）设max-age=31536000, immutable；HTML设no-cache配合ETag；API接口用stale-while-revalidate=60，同时开启Service Worker做离线缓存兜底，效果立竿见影：二次访问的重复请求减少72%。
CDN加速部署建议
他们服务器在美东,但用户40%在亚洲，我选了CloudFront + 阿里云CDN双线，关键点：1）开启Brotli压缩（比Gzip再小15%）；2）配置边缘缓存规则，把商品图片缓存Tiered到200ms以内；3）用Lambda@Edge做图片实时缩放，注意：CDN不是万能药，动态API请求别走CDN，否则缓存击穿更慢。
服务器配置优化要点
原服务器是2核4G的云主机,跑着Nginx + PHP-FPM + MySQL，我做了：1）Nginx开启gzip_static和open_file_cache；2）PHP-FPM进程数从5调到20，但设了pm.max_requests=500防内存泄漏；3）MySQL加innodb_buffer_pool_size到2G，慢查询日志揪出3条没走索引的SQL，4）开启HTTP/2和TLS 1.3，减少握手延迟。
实测数据对比
优化前：LCP 3.8s，TBT 1.2s，首屏加载4.7MB，移动端评分32。
优化后：LCP 0.9s，TBT 0.15s，首屏加载680KB，移动端评分94。
服务器TTFB从820ms降到110ms，CDN命中率91%，最直观的：跳出率从58%降到31%，加购转化率提升22%，老板第二天给我发了条消息：“广告费终于不烧得心疼了。”
网站优化优化服务,不是堆工具，而是像外科手术——诊断准、下手稳、验证狠，每个字节都值得较真，因为用户不会等，搜索引擎更不会。
发表评论