性能不是单一分数，也不能直接换算成AI提及率。它首先影响用户是否能顺利打开、阅读和操作页面，同时过慢或资源失败也会增加技术排查难度。
移动端先检查内容是否同等可用
移动审计应同时看正文是否完整、资源是否可访问、交互是否稳定，以及LCP、INP、CLS等真实用户体验指标。桌面正常不能代替移动验证。
性能优化不能只追求测试工具满分而删除重要正文，也不能为了移动版简洁隐藏产品参数。
工具分数要落到真实阻塞
保持同一网址和核心信息完整，先修影响访问与阅读的故障，再处理细节优化。
桌面端默认展开的参数表，在手机上若被放进必须点击才加载的组件，可能导致读者和部分抓取环境拿不到核心内容。审计先比较两端正文与指令，再结合网络请求、布局变化和主内容加载时间定位真正阻塞。
实验室工具适合复现大脚本或图片问题，真实用户数据用来观察不同设备和页面类型，二者不能混成一个分数。优化后从资讯列表进入详情、阅读参数、打开联系入口并返回栏目，确认性能改动没有破坏客户任务。
从两端对比到业务路径回归
1. 检查内容一致
对比桌面和手机的标题、正文、图片替代文本、结构化数据和索引指令。
2. 查找关键阻塞
关注服务器响应、主内容加载、大脚本、布局跳动和必须点击后才出现的正文。
3. 结合两类数据
实验室工具用于定位，真实用户数据用于观察实际体验，分别记录设备和页面类型。
4. 回归业务路径
从文章列表进入详情、阅读参数、点击联系与返回栏目，确认优化没有破坏用户任务。
性能修改不能破坏阅读任务
- [ ] 桌面和手机的标题、正文、图片替代文本、结构化数据与索引指令经过逐项对比。
- [ ] 服务器响应、主内容加载、大脚本、布局跳动和点击后才出现正文等问题各有测量证据。
- [ ] 实验室结果与真实用户数据分栏记录设备、页面类型和时间范围，没有互相替代。
- [ ] 文章列表、详情、参数阅读、联系入口与返回栏目在窄屏完成回归，优化没有破坏业务任务。
性能检查要落到具体页面和用户路径。单个总分升高，却让正文缺失或联系入口不可用，仍属于回归失败。
事实边界
Core Web Vitals是Google公开的网页体验指标，不是GEO验收指标。平台抓取策略与回答选择还需通过各自文档和实测判断。