写网站优化方案，网站最容易犯的系统写毛病是上来就列“服务器要升级、图片要压缩、优化代码要合并”。网站这跟医生没问诊就开药没区别。系统写我见过一个日活两千的优化电商站，技术团队花三个月重构了前端，网站结果跳出率反而涨了12%。系统写后来查日志才发现，优化真正的网站问题出在购物车接口平均响应1.8秒——用户点“加入购物车”之后要愣两秒才看到反馈，以为没点上，系统写又点一次。优化

所以方案的网站第一页不该是技术清单，而是系统写问题清单。从哪来？优化监控数据、用户反馈、客服记录、甚至老板半夜刷手机时的直觉。把“首页加载超过3秒”这种模糊感受，变成“移动端4G网络下首屏渲染中位数4.2秒，超过Google建议的2.5秒阈值”。数字不会撒谎，但数字要选对。别盯着PV和UV，去看Apdex（应用性能指数）或者自定义的“关键操作完成率”。

接下来才是技术层。但别按教科书分类，按影响面排序。比如数据库慢查询，一条没加索引的SQL能拖垮整个商品列表页。我习惯先跑一遍慢日志，把执行时间超过500ms的语句拎出来，看它们出现在哪些业务路径上。如果一条慢查询只影响后台报表，可以缓一缓；如果它卡在用户登录环节，当天就得改。

前端优化有个反直觉的点：不是所有资源都要压缩合并。HTTP/2普及之后，把20个小JS文件合成一个巨大bundle反而可能更慢，因为浏览器无法并行解析。更实际的做法是拆成关键路径和非关键路径。首屏需要的CSS内联，其余异步加载。图片别只想着WebP，先检查有没有用CSS缩放一张2000px宽的图去显示200px的缩略图——这种蠢事我至少见过五十次。

缓存策略要分层写。浏览器缓存、CDN缓存、服务端缓存、数据库查询缓存，每层的失效时间不一样。有个坑：很多人给静态资源设了一年过期，结果发版时用户拿不到新JS。解决方案不是缩短过期时间，而是给文件名加hash。这属于工程习惯，写进方案里能省掉以后无数扯皮。

别忽略“非技术优化”。比如把表单的必填字段从12个减到5个，转化率提升比任何代码压缩都明显。又比如错误提示别写“系统繁忙请稍后重试”，改成“您的订单未提交成功，请检查网络后点击此处重试”——后者能减少30%的客服工单。这些改动不需要动架构，但需要产品、运营、技术坐在一起对需求。

方案里要留出验证环节。上线后看什么指标？不是“感觉快了”，而是具体到“商品详情页的LCP从3.8秒降到1.9秒”“支付接口P99延迟从2.1秒降到800毫秒”。准备一个回滚方案，万一CDN配置改错了，十分钟内能切回旧配置。我见过一次因为改了Nginx的gzip级别导致CPU飙满，整个站点502了四十分钟——就因为方案里没写回滚步骤。

最后，优化方案不是一次性文档。把它当成活页夹，每解决一个问题就划掉一行，每发现新瓶颈就加一行。每周花二十分钟看监控大盘，比每季度写一份五十页的PPT有用得多。网站优化这件事，方向比速度重要，测量比猜测可靠。