性能
1. 首屏时间
首屏时间是指用户从打开小程序看到第一屏主要内容的时间，首屏时间太长会导致用户长时间看到的都是白屏，影响使用体验。
优化首屏时间，可以分为以下几种情况：
- 首屏渲染的内容较多，需要集合多份数据进行渲染。这种情况需要开发者把内容分优先级，把优先级高的内容做优先展示，缩短白屏时间；
- 首屏内容依赖的数据从服务端请求的时间太长。开发者需要从服务端侧具体分析服务端数据返回的时间长的原因；
- 一次性渲染数据太大或依赖的计算过于复杂。减少渲染的数据量、优化渲染相关数据的算法可以解决这类问题。
- 参考值：FCPThresholds = [1800, 3000]; LCPThresholds = [2500, 4000];
- 大于 thresholds[1] 说明很差，thresholds[0] ～ thresholds[1] 需要提升，小于 thresholds[0] 说明很好
官方建议：首屏时间不超过 5 秒
2. 渲染时间
渲染时间指的是首次渲染或因数据变化带来的页面结构变化的渲染花费的时间。
渲染界面的耗时过长会让用户觉得卡顿，体验较差，出现这一情况时，需要校验下是否同时渲染的区域太大（例如列表过长），或渲染依赖的计算是否过于复杂。
官方建议：渲染时间不超过 500ms
3. 脚本执行时间
脚本执行时间是指 JS 脚本在一次同步执行中消耗的时间，比如生命周期回调、事件处理函数的同步执行时间。
执行脚本的耗时过长会让用户觉得卡顿，体验较差，出现这一情况时，需要确认并优化脚本的逻辑
官方建议：一个执行周期内脚本运行时间不超过 1 秒
4. setData 调用频率
setData 接口的调用涉及逻辑层与渲染层间的线程通信，通信过于频繁可能导致处理队列阻塞，界面渲染不及时而导致卡顿，应避免无用的频繁调用。
官方建议：每秒调用 setData 的次数不超过 20 次
5. setData 数据大小
由于小程序运行逻辑线程与渲染线程之上，setData 的调用会把数据从逻辑层传到渲染层，数据太大会增加通信时间。
官方建议：setData 的数据在 JSON.stringify 后不超过 256KB
6. DLT 节点数
建议一个页面使用少于 1000 个 DLT 节点，节点树深度少于 30 层，子节点数不大于 60 个。一个太大的 DLT 节点树会增加内存的使用，样式重排时间也会更长，影响体验。
官方建议：页面 DLT 节点少于 1000 个，节点树深度少于 30 层，子节点数不大于 60 个
7. 图片缓存
开启 HTTP 缓存控制后，下一次加载同样的图片，会直接从缓存读取，大大提升加载速度。
官方建议：所有图片均开启 HTTP 缓存
8. 图片大小
图片太大会增加下载时间和内存的消耗，应根据显示区域大小合理控制图片大小。
官方建议：图片宽高乘积 <= 实际显示宽高乘积 * (设备像素比 ^ 2)
9. 请求耗时
请求的耗时太长会让用户一直等待甚至离开，应当优化好服务器处理时间、减小回包大小，让请求快速响应。
官方建议：所有网络请求都在 1 秒内返回结果
10. 网络请求数
短时间内发起太多请求会触发小程序并行请求数量的限制，同时太多请求也可能导致加载慢等问题，应合理控制请求数量，甚至做请求的合并等。
官方建议：通过 dlt.request 发起的耗时超过 300ms 的请求并发数不超过 10 个
11. 图片请求数
短时间内发起太多图片请求会触发浏览器并行加载的限制，可能导致图片加载慢，用户一直处理等待。应该合理控制数量，可考虑使用雪碧图技术或在屏幕外的图片使用懒加载。
官方建议：同域名耗时超过 100ms 的图片请求并发数不超过 6 个
12. 网络请求缓存
发起网络请求总会让用户等待，可能造成不好的体验，应尽量避免多余的请求，比如对同样的请求进行缓存
官方建议：3 分钟以内同一个 url 请求不出现两次回包大于 128KB 且一模一样的内容