功能没问题、审核也过了，用户留不留得住看什么？打开速度。小程序对性能有硬指标——体验分，低于阈值连"搜索优先展示"的资格都没有。这篇从首屏、渲染、网络、服务端四层给出优化清单，全部可落地。

一、先理解体验分

微信小程序的体验分由多项性能指标加权得出，核心几项：

体验分低的影响很实际：搜索排名降权、广告投放成本上升、用户流失。打开超过 3 秒，一半用户直接杀掉进程。

二、首屏优化：每一毫秒都值钱

首屏时间是体验分的头号权重。优化按收益排序：

1. 分包加载（大项目必做）

主包限制 2MB（整体积 20MB+）。把非首屏页面、重组件扔进子包：

// app.json：配置分包
{
  "subpackages": [
    {
      "root": "packageA",
      "pages": ["detail/detail", "list/list"]
    }
  ],
  "preloadRule": {                      // 预载：进首页时悄悄下载子包
    "pages/index/index": {
      "network": "all",
      "packages": ["packageA"]
    }
  }
}

2. 首屏数据并行请求

// 错误：串行，等 A 完再请 B，白等一倍时间
const user = await getUser()
const list = await getList()

// 正确：并行
const [user, list] = await Promise.all([getUser(), getList()])

3. 骨架屏替代 Loading 转圈

白屏 + 转圈 = 用户感知的"慢"；骨架屏 = "内容马上来"。首屏结构确定就上骨架屏，感知时间能砍 40%。

4. 本地缓存优先

// 策略：先渲染缓存，再静默刷新
onLoad() {
  const cached = wx.getStorageSync('home-data')
  if (cached) {
    this.setData({ list: cached })     // 秒开
    this.fetchFresh()                   // 后台更新
  } else {
    this.fetchFresh()
  }
}

三、渲染优化：setData 是老大难

setData 是小程序唯一的渲染通道，也是最常见的性能杀手。

1. 只传变化的数据

// 错误：整个对象重传，几十个字段全走一遍序列化
this.setData(this.data.item)

// 正确：路径更新，只动一个字段
this.setData({ 'item.title': newTitle })

2. 合并调用

// 错误：三次独立 setData，三次渲染
this.setData({ a: 1 }); this.setData({ b: 2 }); this.setData({ c: 3 })

// 正确：一次搞定
this.setData({ a: 1, b: 2, c: 3 })

3. 长列表用 recycling 方案

超过 100 项的长列表，普通渲染必卡。用官方 recycle-view 或社区的虚拟列表组件，只渲染视口内的项——这一条能让长列表页从 30 帧掉到 60 帧。

4. 别在 onPageScroll 里 setData

滚动事件高频触发，每次 setData 都引发渲染。要做的交互（如标题显隐）用 CSS 类切换或 WXS 响应式实现。

5. 图片懒加载 + 尺寸占位

<image lazy-load src="{{item.cover}}" mode="aspectFill"
        style="width:{{item.w}}px;height:{{item.h}}px" />

lazy-load 让视口外图片不加载；提前算好宽高占位，避免图片加载完成时页面"跳一下"。

四、网络层优化

1. 请求合并

把首页的 5 个接口合成 1 个聚合接口（BFF 模式），TCP 握手和域名解析只付一次代价。移动网络下，每次新建连接的隐性成本可能比传输本身还高。

2. 开启 HTTP/2

Nginx 配 listen 443 ssl http2;，多路复用让并行请求不再互相排队，配置见小程序后端搭建实战。

3. 静态资源全上 CDN

接口走服务器，图片/JS/字体走 CDN。静态资源分离方案见对象存储分离静态资源。

4. 接口压缩

Nginx 开 Gzip/Brotli，JSON 响应体积砍 70%：

gzip on;
gzip_types application/json text/plain application/javascript;
gzip_min_length 1k;

5. 失败重试与超时

公网请求必须设超时（建议 10s）和有限重试（1 次），别让用户对着转圈的圈圈怀疑人生。

五、服务端：接口快才是真的快

前端优化到极限，接口 800ms 全白搭。服务端 checklist：

• [ ] 接口响应 < 200ms（P95），慢查询治理见MySQL 慢查询优化实战
• [ ] 热点数据 Redis 缓存，命中率 > 80%
• [ ] N+1 查询消除，关联查询一次拿齐
• [ ] 响应体只返回前端要的字段（别把整表字段甩过去）
• [ ] 压测过峰值，见服务器性能测试与压测方法
• [ ] 接口监控告警，P95 劣化第一时间知道，方案见网站状态监控页搭建

六、用数据说话：性能分析工具

开发者工具自带两把刀：

1. Audits 面板：一键跑分，按体验分维度给优化建议——提交审核前跑一遍，低于 80 分别提审
2. Network + Performance 面板：看每个请求的耗时瀑布、JS 执行耗时，定位具体瓶颈

真机调试：模拟器的性能数据和真机差距巨大，安卓中低端机才是大多数用户的真实环境——性能测试必须在真机上做。

结语

小程序性能优化的核心认知：用户感知的速度 > 实际速度。骨架屏、缓存优先、骨架占位这些"心理优化"，和真正的并行请求、分包加载同样重要。把这份清单按收益从上往下做，体验分和留存率会一起上去。

需要更快更稳的后端，可以看看财富云计算：NAT 型云服务器支持 443 映射，SSD 盘 + 5M 起步带宽，接口 P95 压到 200ms 以内毫无压力，价格比独立 IP 机型省一半以上——前端再优化，也离不开一个不拖后腿的服务端。

延伸阅读

1. 网站环境怎么选：LNMP 手动 / 宝塔面板 / Docker / 云开发
2. 问卷表单系统搭建：SurveyKing / Formbricks，数据自己收
3. 图床搭建：Lsky Pro / Lychee，自托管图片托管方案
4. 邮件列表搭建：listmonk 自托管 Newsletter，把读者握在自己手里
5. 文档站点搭建：MkDocs / VuePress / Docsify，产品文档与技术手册方案
6. RSS 阅读器搭建：FreshRSS 自托管，把信息流拿回自己手里
7. 短链接服务搭建：Shlink 自托管，链接数据自己掌握
8. 网站状态监控页搭建：Uptime Kuma，服务器挂了第一时间知道

更多阅读

1. 上一篇：小程序图片上传与文件存储：对象存储直传方案
2. 下一篇：企业官网搭建指南：从域名到上线，小公司最省钱的完整方案