站点变慢先做的五步体检

用户说「网站好慢」时，先做五步体检，再决定是否加机器。盲目升级配置既费钱，也可能完全打偏。

第一步：分清慢在首屏还是慢在操作

• 打开首页是否超过三秒才有内容；
• 点按钮后是否转圈很久；
• 只在手机慢还是电脑也慢；
• 是否只有某一栏目慢。

记录时间点与网络环境，避免凭感觉优化。

第二步：看体积与图片

常见肥点：

1. 未压缩的大图；
2. 一次加载过多轮播与视频；
3. 未启用现代图片格式；
4. 第三方统计或客服脚本阻塞渲染。

先把首屏图片压到合理体积，往往立刻有体感提升。

第三步：缓存与重复请求

• 静态资源是否带长期缓存；
• 接口是否被页面重复打很多次；
• 列表页是否每次都全量查询；
• HTML 是否可短时缓存（视业务而定）。

第四步：服务端与数据库

若接口本身就慢：

• 找出最慢的三个接口；
• 看慢查询与缺失索引；
• 检查是否同步调用了不稳定的外部服务；
• 高峰期 CPU 与内存是否打满。

第五步：设定预算与回归

• 首屏内容时间目标（例如两秒内）；
• 图片体积上限；
• 上线前用同一套检查再跑一遍；
• 把性能项写进验收，而不是上线后当惊喜。

一天内可完成的最小动作

• 压缩首页可见图片；
• 去掉首屏不必要的第三方脚本；
• 给最慢列表加索引或分页；
• 记录优化前后各三个样本时间。

五步体检做完，再谈换机器或换架构，决策会理性很多。性能是体验问题，也是转化问题，值得当成固定检查，而不是投诉驱动的救火。

落地时的协作建议

把本文的检查项复制到协作文档里，按负责人拆分，比只在群里口头提醒更有效。建议固定三个角色：

• 产品或业务负责人：确认范围与验收口径；
• 技术负责人：确认实现与监控；
• 运营或内容负责人：确认文案、素材与对外说明。

每周只开一次短会对齐进度，会比每天追问更省时间。遇到驳回或延期，先回到清单定位是哪一类问题，再决定是否加资源，避免情绪化加需求。

记录模板（可直接复制）

1. 日期与环境（测试 / 预发 / 生产）；
2. 现象：一句话描述用户可见结果；
3. 已排除项：打勾列出；
4. 下一步：唯一负责人 + 截止时间；
5. 验证方式：怎样算修复完成。

坚持用同一模板两到三周，团队会形成共同语言，后续类似问题处理会快很多。也方便事后复盘：到底是清单不全，还是执行跳步。

什么时候可以收工

满足下面四条再宣布「这一阶段完成」：

• 清单上的高优先级项全部有结论（通过 / 不适用 / 延期并写明原因）；
• 主路径在目标环境可完整走通；
• 对外文案与实际行为一致；
• 有人能在五分钟内讲清回滚或降级办法。

收工不等于永远不再改，而是当前风险已降到可接受，并把剩余项明确排期。这样既不会无限拖延上线，也不会在「差不多就行」里埋雷。

落地时的协作建议

把本文的检查项复制到协作文档里，按负责人拆分，比只在群里口头提醒更有效。建议固定三个角色：

• 产品或业务负责人：确认范围与验收口径；
• 技术负责人：确认实现与监控；
• 运营或内容负责人：确认文案、素材与对外说明。

每周只开一次短会对齐进度，会比每天追问更省时间。遇到驳回或延期，先回到清单定位是哪一类问题，再决定是否加资源，避免情绪化加需求。

记录模板（可直接复制）

1. 日期与环境（测试 / 预发 / 生产）；
2. 现象：一句话描述用户可见结果；
3. 已排除项：打勾列出；
4. 下一步：唯一负责人 + 截止时间；
5. 验证方式：怎样算修复完成。

坚持用同一模板两到三周，团队会形成共同语言，后续类似问题处理会快很多。也方便事后复盘：到底是清单不全，还是执行跳步。

什么时候可以收工

满足下面四条再宣布「这一阶段完成」：

• 清单上的高优先级项全部有结论（通过 / 不适用 / 延期并写明原因）；
• 主路径在目标环境可完整走通；
• 对外文案与实际行为一致；
• 有人能在五分钟内讲清回滚或降级办法。

收工不等于永远不再改，而是当前风险已降到可接受，并把剩余项明确排期。这样既不会无限拖延上线，也不会在「差不多就行」里埋雷。