01 / 为首屏建立预算
先列出用户完成首个任务必须看到的内容。商品首图、价格与核心按钮优先，评价、推荐和复杂动画延后加载。图片按展示尺寸生成资源，避免小卡片下载原始大图。
性能测试覆盖中低端设备及受限网络，并分别测量冷启动、热启动与回访体验。开发电脑上的加载速度不能代表实际用户。
把资源请求按依赖顺序绘制出来，定位串行接口和阻塞首屏的脚本。先解决关键请求链，再做文件压缩；如果页面必须等待多个互相依赖的接口，再小的图片也无法消除等待。
02 / 缓存内容，谨慎缓存业务状态
门店介绍、图片和静态分类适合缓存。库存、优惠资格和订单状态应显示更新时间，并在关键操作前向服务端确认。
离线时可以保留浏览记录和购物车草稿，但不能声称支付或预订已经成功。恢复连接后合并草稿，并提示发生变化的价格与库存。
缓存键包含用户或租户范围，退出登录时清除受保护的本地数据。草稿需要版本与修改时间；恢复后让用户确认服务器已经变化的字段，不使用最后一次写入静默覆盖整条订单。
03 / 支付结果以服务端确认为准
客户端跳转回页面只表示用户离开了支付界面。订单支付成功应由验签后的服务端通知或主动查询确认，页面展示处理中、成功和失败三种独立状态。
客户端重复刷新不会再次扣款；同一订单的支付请求应具备稳定的业务幂等标识。
为“处理中”提供明确的刷新与查询路径，同时保留订单编号。用户返回后可查询结果，但不自动重新发起支付。取消、超时和晚到回调也应映射到一致的服务端订单状态。
04 / 小流量验证再逐步发布
先向内部测试者开放，再逐步扩大范围。监控首屏可交互耗时、接口错误、支付确认延迟和关键任务完成率。
平台能力与审核要求可能变化，正式接入时以 Zalo 当前官方开发文档和商户实际权限为准。
按版本区分监控数据，确认错误来自应用代码、平台接口还是网络环境。发布前保留上一稳定版本和配置回退方式，且验证缓存不会让旧客户端调用不兼容的新接口。
- 低端设备与弱网分别测量冷启动。
- 离线草稿与已确认业务结果明确区分。
- 退出登录清除受保护缓存，支付状态由服务端确认。
移动端性能优化
