如何检查网站在手机上是否好用

检查网站能否在手机上正常使用，需要把性能报告与实际操作测试结合起来。页面加载很快，提交按钮却可能点不到；布局能适应屏幕，表单内容却可能在提交时丢失。

Google 已于2023年12月停用 Mobile-Friendly Test及其API。PageSpeed Insights、Lighthouse、浏览器设备模拟和真机测试各有用途。任何一项都不能单独证明网站易用、符合无障碍要求或能获得好的搜索排名。

先选重要页面和实际操作流程

从首页、一个主要产品或服务页、一篇文章开始。加入真实的联系、预约或购买流程，即使其中会跳转到其他域名。测试相关语言版本，以及首次访问时的同意横幅、再次访问、菜单展开、表单报错等状态。

我们的免费移动适配检查工具可以作为初步筛查。它检查抓取到的HTML及响应信息，寻找缺少viewport标签、内联固定宽度、内联字号过小等线索。它不会渲染页面、执行JavaScript或根据外部样式表计算布局。HTML大小不等于页面的总下载量，抓取耗时也不是真实手机的加载时间。发现提示后，仍需在浏览器中确认。

分清PageSpeed的两类结果

打开 PageSpeed Insights，输入公开页面URL，选择移动设备。

实测数据来自Chrome UX Report，覆盖此前28天。先看报告显示的是“This URL”（此URL）还是“Origin”（源）。某个URL的数据不足时，PageSpeed可能改用源级数据，即协议、主机名和端口相同的页面集合。源级评估通过，不代表这个具体页面通过；两个层级都没有足够数据时，缺少评估也不等于不合格。

实验室部分则是在模拟条件下新运行的一次Lighthouse测试，可以用来调查加载缓慢的资源或阻塞工作的脚本。其性能分数与实测评估不同。一次页面导航测试无法测出访客群体的INP。Google文档解释了这些区别。

查看保存的2026年8月4日移动报告原图（选中Origin，Core Web Vitals评估通过）

这张保存的示例显示源级实测结果：LCP为2.4秒，INP为112毫秒，CLS为0。图中没有Lighthouse性能分数。它用于说明报告的数据范围，不是对我们首页当前性能的重新测量。

Core Web Vitals阈值是什么意思

以下分类采用相应实测数据的第75百分位值，而不是平均值：

完整的三项评估要求全部达到良好。INP数据不足时，如果LCP和CLS都良好，PageSpeed仍可能判定通过；LCP或CLS数据不足则无法给出评估。这是PageSpeed的评估规则，不能代替实际交互测试。

比较Search Console时先对齐范围

在Search Console打开Core Web Vitals移动报告，查看受影响的URL组、该组最差的指标和示例URL。Google把体验相似的页面分组，这些组不一定与你的网站模板一一对应。先复现问题，再判断是不是共享组件造成的。

即使两边都看实测数据，PageSpeed与Search Console仍可能不同。核对URL、源或分组范围、设备、采集时期以及URL处理方式。Search Console区分URL参数，PageSpeed实测数据则不带这些参数进行汇总。因此，不能把所有差异都解释成“实验室与真实用户不同”。报告文档说明了这些区别。

修复上线后，立即用相同的浏览器步骤和实验室设置复测。随着新访问进入滚动窗口，实测结果会逐渐变化。“Start Tracking”启动28天验证，不会强制抓取或重新索引。显示的数据可能在28天结束前变化，但验证仍需要完成监测期，并有足够数据。

记录Lighthouse的测试条件

在Chrome打开页面，再打开DevTools，选择Lighthouse和移动设备后运行检查。本地Lighthouse可以测试已登录页面，而公开的PageSpeed请求未必能访问这些页面。Lighthouse文档介绍了可用方式。

保存报告、日期、URL、Lighthouse版本、设备配置、限速设置和被测页面版本。比较改动时保持条件一致；遇到意外结果，重复测试。电脑、浏览器版本、同意状态和配置都会影响测量。手动限制DevTools中的CPU速度，并不保证与PageSpeed模拟条件一致。

用PageSpeed API自动运行实验室测试

下面的Bash命令请求移动性能、无障碍和SEO诊断。将示例URL替换为公开页面：

curl --get \
  'https://www.googleapis.com/pagespeedonline/v5/runPagespeed' \
  --data-urlencode 'url=https://example.com/' \
  --data-urlencode 'strategy=mobile' \
  --data-urlencode 'category=performance' \
  --data-urlencode 'category=accessibility' \
  --data-urlencode 'category=seo'

Windows用户需要在Bash终端中使用这段多行语法。入门指南说明了API访问方法，并建议频繁自动查询时使用密钥。安排批量测试前，检查项目配额。HTTP错误，包括配额错误，不代表被测页面不合格。

在lighthouseResult中读取categories和audits；类别分数0.92相当于百分制的92分。保存fetchTime、lighthouseVersion、requestedUrl、finalUrl和configSettings，接受结果前先处理runtimeError。字段定义见响应参考。持续监测实测数据时，Google建议使用CrUX API或CrUX History API，因为计划从PageSpeed API中移除CrUX数据。

在浏览器和真机上完成实际任务

开启DevTools设备工具栏，从360 × 800和390 × 844 CSS像素开始，逐步调整宽度，再测试横屏。设备模式只是近似模拟。最后要用访客实际使用的手机和浏览器测试，包括适用时的iPhone Safari。

• 打开和关闭导航、同意设置及对话框。固定页眉和横幅不能遮住文字或控件。
• 阅读长标题、表格和翻译文本，测试缩放及窄屏布局。《Web内容无障碍指南》（WCAG）的重排标准对纵向滚动内容采用320 CSS像素宽度，相当于1280像素视口放大到400%。确实需要二维结构的表格有例外；应保留可读内容和可操作的滚动，不要直接隐藏溢出内容。
• 点击相邻控件，并在支持时用键盘操作。WCAG 2.2 AA的目标尺寸标准采用24 × 24 CSS像素，并有间距等例外。48 × 48等更大的控件可以是舒适的设计选择，但任一尺寸都不能单独证明无障碍合规。
• 保持屏幕键盘打开，填写表单。检查标签、焦点、报错、输入保留、提交和确认状态。购买或预约应使用获准的测试环境，并核对相应凭证或记录。
• 换用有代表性的移动网络重复测试。加载延迟或请求失败时，应提供清晰的恢复操作。

有用的问题记录要具体。假设案例：“预约页在390 × 844下，键盘和同意横幅遮住提交按钮。页面可以滚动，但按钮仍无法操作。”附上URL、浏览器、设备、页面状态、复现步骤、截图、预期结果和负责人。即使性能分数是绿色，预约无法完成也应优先处理。

修复实际测出的原因

LCP慢时，先找出真正的最大内容元素，以及它出现较晚的原因。若是图片，让浏览器尽早发现它，并避免延迟加载。只有资源需要更早被发现时才使用预加载，不要预加载所有图片或字体。LCP优化指南解释了这一区别。

交互迟缓时，录制操作并调查阻塞工作。减少不必要的脚本处理，或拆分长任务，同时保留必要功能和同意机制。布局偏移则应为图片、嵌入内容和新插入的内容预留空间。INP与CLS指南分别介绍这些问题的诊断方法。

使用WordPress或Shopify时，在测试环境里用相同内容和流程验证主题或应用改动。先测量影响，再决定是否归因于插件或需要重建。部分问题可调整配置，其他问题需要修改组件。我们的网站优化服务可以帮助定位和实施这些改动，需要修改代码时再结合网站开发。

把索引与可用性分开检查

Google的移动优先索引指南推荐响应式设计，也支持其他移动配置。确保Googlebot可以访问移动端内容、图片和元数据。页面好用，仍可能有索引问题，需要单独进行SEO排查。

Core Web Vitals参与Google的排名系统，但高分不保证高排名，低分也不能单独证明受到惩罚。页面体验指南把这些指标放在页面整体价值中考虑。

最后保留一份可执行的记录：发现了什么问题、上线了什么改动、哪些任务已复测成功、哪些实测验证仍待完成。主题、应用、表单或标签改动后，再检查受影响流程。报告通过与访客完成实际任务，是两项不同的验证。