PageSpeed 没有返回分数，不意味着网站验收必须全部暂停，也不意味着性能可以直接判定合格。更合适的做法是保留工具缺失，继续完成能独立检查的页面与功能，另列性能数据待测项。分数、实际操作和服务器响应各有用途，不能互相冒充。
先保存失败，避免把工具问题写成网站结果
在 JVDS 2026年10月2日的线上 SEO 检测中，PageSpeed 请求遇到了限制，记录中也没有完整的 Lighthouse 与核心网页指标结果。那次检测能提供网址响应、页面内容和部分资源事实，但不能填上一项没有产生的性能分数。这是一次历史检测范围，不是网站当前性能结论。
遇到类似情况，先记录工具名称、日期、目标网址、设备选项和原始返回信息。若一次请求被限制，写“这次未获取结果”；若测试无法完成，写“原因待核对”。不要把空白填成零分，也不要从另一个网址借来高分。
假设项目约定验收包含性能报告，而工具当天无法使用，报告应将该项列为待测，并约定替代办法或补测安排。这样既保留了交付要求，也避免把等待一个工具变成所有工作停摆。成功标志是缺失项有明确对象和责任人。
先把验收项目分成三个篮子
第一个篮子是功能与内容：导航能否到达正确页面、表单是否完成目标操作、文章与图片是否完整、语言切换是否符合预期。这些可以通过实际访问检查，不需要等待综合性能分数。
第二个篮子是可观察的体验：首屏是否长时间空白、页面是否明显跳动、点击是否有反馈、移动端是否能完成任务。可以先在真实设备上记录现象。它能证明某次体验的问题或完成情况，不能换算成核心网页指标。
第三个篮子是定量性能：实验室测试结果、真实用户汇总以及前后版本可比较的数据。这一篮子需要相应工具和条件，缺少结果时保持待测。网站返回正常和内容可见，都不能给这一栏自动打勾。相关操作可参阅《Core Web Vitals是什么？LCP、INP、CLS与真实用户体验》。
先分篮子的意义是保留进度同时保持诚实。市场同事可以继续核对稿件，维护者可以继续检查表单，性能负责人则单独处理数据获取。不要让一个综合报告入口成为所有验收事项的唯一开关。
用固定样本完成一次人工体验检查
人工检查也应有范围。至少选取项目最重要的访问路径，例如首页进入主要服务，查看一个案例，打开需求表单并完成一次经授权的测试。长内容页面与有大量图片的详情页也应纳入样本，避免只看轻量首页。
把设备、网络、访问时间和是否首次打开记录下来。手机第一次打开与办公室电脑反复刷新，看到的状态可能不同。这里无需假装模拟全部用户，但要让下一位测试者能够照着重做。
观察时描述具体变化：是标题先出现而图片晚到，还是整屏一直空白；是点击后没有反应，还是已经跳转却内容尚未展示；是图片加载把按钮推走，还是页面正常滚动。这样的描述能够缩小技术检查方向，“有点卡”则很难进入工作清单。
可以录制必要的操作过程，截取异常前后画面，并记录复现条件。录屏便于说明现象，但不要把播放时间直接当作规范性能指标。成功标志是重要路径能完成，发现的问题有可重现步骤，而不是测试者凭感觉给出一个总分。
替代工具要说明测到了哪一层
若维护者改用本地浏览器测试，应保留工具、版本、设备模拟和网络设置。这样的实验室结果有助于发现资源或渲染问题，但与真实用户汇总的作用不同。web.dev 对 LCP 的说明将其与主要可见内容的呈现时间关联，单纯看到服务器开始返回并不能替代它。
如果只能拿到服务器响应时间，也可以记录，但字段名称应保持原来的含义。它适合排查连接和响应阶段，无法说明图片什么时候清晰出现、字体何时稳定、点击是否顺畅。不得把“响应较快”转成“手机体验达标”。
替代检测尽量使用相同页面与相同条件，保留原始报告。若前一次测首页、后一次测文章，或一个使用桌面、一个使用手机，就不宜作直接升降比较。比较基准不统一，容易让团队把测量差异当成优化成果。
没有适用工具时，可以先列出待确认假设。例如怀疑首屏主图较晚加载，需检查实际请求顺序；怀疑页面跳动，需记录图片出现前后的位置。把假设作为下一步调查方向，不能直接写成已经找到根因。
组织人工检查时，可以让熟悉内容的人与首次使用页面的人分别完成一条路径。前者容易发现素材或文案缺失，后者更容易暴露入口找不到、按钮反馈不清等情况。两者的观察都应写明任务，不用把主观满意度包装成统一性能数值。
若替代测试安装在开发电脑上，还需确认测的是正式公开网址还是本地版本。两个版本的资源位置、服务器路径和外部服务可能不同。本地结果能辅助开发定位问题，但交付记录应说明环境，避免把本地表现直接复制到线上验收栏。
恢复原工具后，不必只看总分。先核对报告能否完整生成，再看它是否提示了与人工观察一致的问题。若提示项影响已确认的功能或版式，应在修改后重复该操作。分数改善却表单失效，仍不能算完成原有验收任务。
写清临时放行与必须补测的边界
是否允许先上线，应回到实际项目要求。若核心表单无法提交、重要内容空白或手机导航不可用，这些已经确认的问题不应因为没有分数而被忽略。若业务路径检查通过，只剩约定的定量性能报告，双方可以明确是否允许带着待测项继续推进。
决定时应写明待测页面、补测责任、完成条件和如何处理不达预期的结果。不能只写“上线后再优化”，也不要预先断言补测一定通过。临时安排的价值在于它可执行，而不是用一句话取消原有要求。
假设补测发现某个重要案例页有明显体验问题，应按其实际影响排优先级。可能需要调整图像资源，也可能是脚本、字体或动画造成。先验证，再决定修改，不把所有未达预期都归到服务器费用不足。
对于确实依赖性能结论的发布节点，例如重要活动入口，应按项目既定要求补足证据后再确认。本文提供的是验收拆分方法，不是所有网站均可省略性能测量的建议。相关操作可参阅《企业官网上线验收清单：内容、功能、SEO、性能与安全》。
一份能继续推进的待测记录怎么写
建议每个待测项包含网址、未获得什么、原始失败信息、已有检查和下一步。比如“移动端页面的实验室性能结果未取得；已核对主要入口和表单操作；拟由维护者在确定环境重测，保留完整报告”。每一项都能指向一件实际工作。
已经完成的结果单独记录。不要用“网站整体无问题”覆盖一个待测清单，也不要因为一个数据缺口把所有已做工作记作失败。内容检查完成就是内容检查完成，性能未测就是性能未测，合并后的验收状态再按约定决定。
复测时先确认站点版本没有变化。如果页面内容、资源或代码已经更新，旧测试可以作为历史背景，但新的报告应记录新的版本。用于比较的前后样本还需要保持主要条件一致，否则不能把差异全部解释为改动效果。
最后检查记录是否回答了三个问题：谁继续做，做什么，什么结果代表完成。补测不应只留一张分数截图，重要问题应能对应具体页面、原因调查与复查结果。这样即使某个工具暂时不可用，验收仍有可执行的推进路线。
常见问题
工具返回错误，是否说明网站拒绝访问？
不一定。需要看错误来自工具请求限制、工具运行还是目标网站响应。只保留“失败”两个字不足以判定原因，最好保存原始信息交给维护者核对。
人工觉得很快，可以填一个估计分数吗？
不可以。人工观察可以描述使用条件和现象，不能生成工具没有给出的分数。缺失的字段应保留待测，避免后续人员把估计当成报告。
没有真实用户数据，是不是网站没有访问？
不能这样推断。公开汇总是否可用还与数据条件有关。可以记录当前未取得相应数据，并使用明确条件的实验室测试辅助诊断。
只测首页能完成官网性能验收吗？
需看约定范围。不同模板的图片、脚本和操作可能差别很大。若要求包含服务、案例与表单，应选相应样本，不能默认首页代表所有页面。
后续拿到分数，就可以删掉历史失败记录吗？
建议保留检测日期和过程，将新结果标成补测完成。历史记录帮助解释当时为什么留有待测项，也便于区分不同站点版本。
链接复制成功
