Shopify手机性能检查应同时覆盖页面类型和用户动作。先找真实访客使用的首页、集合与产品样本，再测加载、筛选、选规格和加购。三类页面有不同内容与集成，不能用一个首页分数代表整店。
准备一条可以重复的手机路径
从真实流量、订单和性能报告选重要页面，不预设所有店都应先优化首页。记录主题版本、手机与浏览器、网络、市场、语言、同意状态及缓存条件。真实手机能发现触控和布局问题，受控实验室有助于复现；两者都应说明覆盖范围。
Shopify性能报告可按页面类型、URL和设备缩小范围。移动和桌面分别观察，不因手机占比较高就忽略桌面，也不把桌面结果直接搬到手机。
首页：先确认真正的LCP元素
用性能记录识别当前视口的LCP候选，核它是图片还是文本，再看资源发现、下载、服务器等待与渲染。LCP定义关注视口内相关最大内容的呈现；不能仅凭“首页有大图”就宣布原因在图片。
确认某图就是关键LCP资源后，核原始HTML能否及时发现地址，是否误用懒加载，资源尺寸是否适合实际显示，以及CSS或脚本是否延后显示。fetchpriority是优先级提示，不能保证消除等待，也不该给全部图片都标high；具体做法见LCP图片检查。
轮播要测初始可见内容、其他帧的请求时机、切换与暂停。是否改成单图，应结合内容任务和真实使用情况决定；没有数据时先记录疑问，不能直接宣称手机访客都只看第一帧。
集合页：图片请求和筛选状态一起看
记录当前屏幕实际能看到哪些商品卡片，再核它们的currentSrc、固有尺寸、显示尺寸和Network传输。首屏有几张取决于布局与视口，不存在所有主题都通用的“前四张eager”规则；下方图片是否延后加载也要结合滚动体验验证。
有srcset不等于选对了资源，sizes要符合实际容器；一个普通src也不必然指向过大原图。应检查浏览器真正下载的文件，而不是仅凭标签形式给结论。
接着完成筛选、排序、清除条件、分页或加载更多，以及返回上一页。结果错误、筛选丢失和响应慢分别记录；状态问题可参见集合筛选与排序排查，内容入口则对照集合页结构，避免一轮性能维护顺手改URL规则。
产品页：下一帧反馈与业务完成都要核
直接打开代表性的变体落地URL，依次选规格、改数量、加购、查看购物车。检查按钮反馈、正确商品与价格、库存和错误提示；下一帧出现反馈不等于服务器已经成功加购。
INP衡量点击、轻触、按键的响应；滚动流畅度需另测。先记录慢交互的输入等待、处理与呈现阶段，再按主线程排查步骤找原因。字体替换、媒体尺寸和应用插入可能带来布局变化，按CLS与布局偏移区分实际记录及预期变化。
| 看到的现象 | 应保存的证据 | 下一步 |
|---|---|---|
| 主内容出现晚 | 实际LCP元素、请求与渲染时间 | 针对等待阶段修，不统一换图 |
| 筛选或加购反馈慢 | 带具体动作的trace、结果状态 | 定位事件处理和依赖 |
| 内容突然移动 | 偏移记录、插入时机与前后画面 | 找到原因元素，而非只看被挤动的文字 |
| 点击被浮层挡住 | 设备、滚动位置、命中对象与截图 | 按组件归属修可操作性，不只看CLS |
改动优先级由问题和影响面决定
结合受影响访问、业务严重性、定位把握和回滚方式排序。图片优先级、全局动画或事件处理都可能有跨页影响，不因为改动只有一行就统一评为低风险。应用试验尤其要先确认店铺级影响：复制主题只帮助保留主题版本，不能隔离所有应用、订单和数据变化。
完成一项有明确目的的调整后，按同条件复测并回归相邻模板；必要时查看应用评估和脚本归属。同时安排键盘、对比度与触控检查，避免页面更快却更难操作。
如何写出可靠的完成结论
报告应给出具体页面、动作、条件、全部重复测量与仍待验证的范围。实验室分数、现场CWV和交易功能分别评价；后台延迟与窗口解释见性能报告对照方法。手机路径跑通不代表全店已验证，更不能据此承诺流量或转化增幅。