先说结论：好不好看、对不对，都不如"快不快"先被感知

UI 验收那篇讲"好不好用"，功能验收那篇讲"对不对"，但有一个维度常被跳过、用户却最先感知——快不快。首屏转圈 3 秒、列表滑动卡顿，体验再好也留不住人。这一篇补上"性能"这一维，和前两篇组成完整的交付验收。

首屏为什么是最贵的 1 秒？

首屏是用户打开后看到第一屏内容的等待时间，直接决定去留：

  • 精简首屏请求：进页面不要一口气拉十几个接口，先拉最关键的；
  • 骨架屏代替白屏：用占位骨架让用户"感觉在加载"，比转圈圈体验好；
  • 首屏数据缓存：常驻内容本地缓存，二次进入秒开。

首屏优化的本质，是让"用户想看的东西"最先到。这和我们在 UI 验收里讲的"第一眼层级"是一回事——视觉上要抓得住，速度上也要接得住。

资源加载慢，问题常出在哪？

加载不是只靠"网速"，更多是工程取舍：

  • 图片是头号杀手：大图不压缩、不按屏适配，流量和速度一起崩；
  • 包体积：主包塞太多，启动就重；能用分包、懒加载的别全塞进首屏；
  • 接口合并：一个页面七八个请求，能合并就合并，减少握手和等待。

我们做性能复盘时，常发现"不是慢在服务器，是慢在前端贪心"。把资源管住，速度立刻回来——这和数据埋点里"盯住关键指标"一脉相承：先测出来慢在哪，再动手。

交互流畅度怎么保？

加载完还要"跟手"：

  • 长列表虚拟滚动：几百条数据别一次性渲染，只渲染可视区域；
  • 避免主线程阻塞：重计算、大循环挪到后台或拆分，别卡住滑动；
  • 动画克制：炫酷动画若掉帧，不如干脆利落。

流畅度用户说不清，但能感觉到"这 app 顺不顺"。我们做功能验收时会真机跑长列表和连续操作，卡顿在这种真实场景下最容易被揪出来。

性能要不要进验收标准？

应该进。

  • 定指标：首屏时间、接口耗时、卡顿率，写进验收标准，而不是"感觉还行"；
  • 真机测：高端机永远快，中低端机和弱网才是真实战场；
  • 持续盯：上线后靠埋点看真实性能，别交付完就不管。

性能是交付质量的一部分，不是上线后的"优化彩蛋"。如果你要做性能优化、又不知道从哪下手，把业务和当前数据说给我们，方案评估免费——我们先帮你测出慢在哪，再谈怎么改。