一、性能优化总览：为什么小程序需要性能优化？核心指标与优化原则
1.1 为什么小程序必须做性能优化？
说实话，这个问题我经常被问到。
有人觉得小程序就是个轻量应用，用户用完就走，优化不优化无所谓。但我在项目中踩过太多坑了——一个页面加载超过3秒，用户流失率直接飙升到50%以上。你想想看，用户打开你的小程序，转圈圈转半天，他还有耐心等吗？
小程序性能差，带来的问题很直接：
- 用户流失——加载慢，用户直接关掉走人
- 转化率低——电商类小程序，每慢1秒，转化率下降7%
- 口碑变差——用户会觉得你的产品不专业
- 审核被拒——微信官方对性能有硬性要求，太慢可能过不了审核
核心观点：性能优化不是锦上添花，而是生存刚需。尤其在小程序生态里，用户耐心极其有限。
我记得有一次，我们团队上线了一个活动页面，数据量稍微大了点，结果首屏加载花了整整5秒。当天用户反馈炸了，后台投诉量翻了3倍。后来我们花了三天时间做优化，把加载时间压到了1.2秒，用户留存率直接回升了30%。
所以，别小看性能优化。它直接关系到你的小程序能不能活下去。
1.2 核心性能指标：FMP、TTI、LCP
做优化之前，你得先知道「怎么衡量」。没有指标，优化就是瞎搞。
我个人习惯用三个核心指标来评估小程序性能：
| 指标 | 全称 | 含义 | 建议阈值 |
|---|---|---|---|
| FMP | First Meaningful Paint | 首次有效绘制时间 | ≤ 1.5秒 |
| TTI | Time to Interactive | 可交互时间 | ≤ 2.5秒 |
| LCP | Largest Contentful Paint | 最大内容绘制时间 | ≤ 2.5秒 |
FMP（首次有效绘制）
说白了，就是用户第一眼看到「有用内容」的时间。不是白屏，也不是loading动画，而是真正有信息量的东西。
我在项目中遇到过一种情况：页面渲染了，但展示的是骨架屏，用户还是看不到真实数据。这时候FMP其实还没达标。真正的FMP，是用户能看到商品列表、文章标题、图片这些「有意义」的内容。
TTI（可交互时间）
这个指标更狠。它衡量的是用户能不能「动手」了。
比如一个表单页面，页面渲染出来了，但按钮点不了，输入框点不动——TTI就没达标。我见过很多开发只关注首屏渲染，忽略了交互响应，结果用户干着急。
小技巧：TTI 和 FMP 之间往往有个时间差。这个差值越小，用户体验越好。我个人习惯把差值控制在0.5秒以内。
LCP（最大内容绘制）
这个指标关注的是页面中「最大块」的内容什么时候渲染完。比如一张大图、一个视频、一个长列表。
嗯，这里要注意：LCP 和 FMP 不是一回事。FMP 是「第一个有效内容」，LCP 是「最大的那个内容」。有时候FMP很快，但LCP很慢，用户还是会觉得卡。
我曾经优化过一个图片瀑布流页面，FMP只有0.8秒，但LCP高达4秒。原因就是首屏小图加载快，但最大的那张banner图迟迟没出来。后来做了图片懒加载和预加载的平衡，才把LCP压到1.8秒。
1.3 优化原则：三个核心方向
指标知道了，那怎么优化？我总结了三句话：
- 减少请求——能少发就少发，能合并就合并
- 压缩体积——代码、图片、数据，能小就小
- 延迟加载——不是首屏要用的，统统往后排
这三条原则，几乎能覆盖90%的性能问题。
原则一：减少请求
小程序的网络请求是有成本的。每次请求都要经历DNS解析、TCP连接、数据传输。请求越多，耗时越长。
我建议的做法：
- 接口合并——把多个小接口合成一个大接口
- 数据缓存——重复数据不要反复请求
- 预加载——用户还没点，先把数据拉下来
避坑指南：我曾经为了省事，把十几个小接口分开调用，结果页面加载发了20多次请求，直接卡死。后来合并成3个接口，速度提升了60%。记住，请求数量比请求大小更致命。
原则二：压缩体积
小程序包体积有限制（2MB），但很多人忽略了代码本身的体积。
常见的压缩手段：
- 图片压缩——WebP格式比PNG小30%-50%
- 代码压缩——去掉console.log、注释、无用代码
- 数据精简——接口返回的数据，只保留前端需要的字段
你想想看，一个接口返回100个字段，前端只用5个，剩下95个字段白白浪费带宽。我习惯让后端只返回需要的字段，能省不少流量。
原则三：延迟加载
不是所有内容都需要第一时间展示。用户往下滑的时候，再加载也不迟。
具体做法：
- 图片懒加载——只加载可视区域内的图片
- 组件按需加载——用到了再加载组件代码
- 数据分页——一次只加载一页数据
我记得有个项目，首页有50张商品图，全部一次性加载。优化后改成懒加载，首屏只加载前6张，剩下的用户滑到哪加载到哪。首屏加载时间从3.2秒降到了1.1秒。
1.4 优化流程：从测量到落地
光知道原则还不够，你得有一套可执行的流程。我自己的习惯是：
- 测量现状——用工具跑一遍，拿到FMP、TTI、LCP数据
- 定位瓶颈——哪个指标最差，就优先优化哪个
- 制定方案——根据瓶颈选择对应的优化手段
- 实施优化——改代码、调配置、换方案
- 验证效果——再次测量，看指标有没有改善
这个流程看起来简单，但很多人跳过了第一步和第五步。没有数据支撑，优化就是盲人摸象。
记住：优化不是一次性的。业务在变，数据在变，性能指标也会变。我建议每个版本上线前都跑一遍性能测试，形成常态化机制。
1.5 本章小结
这一章我们聊了三个核心问题：
- 为什么优化？——用户没耐心，转化率会掉，审核会卡
- 用什么衡量？——FMP、TTI、LCP，三个指标盯紧了
- 怎么优化？——减少请求、压缩体积、延迟加载
接下来的章节，我会带你深入每个优化点，从代码层面、网络层面、渲染层面，一步步把性能提上去。准备好了吗？我们开始动手。