---
lastModified: 2026-10-13
type: feature
title: "用 Runner AI 进行网站速度测试"
description: "通过 Runner AI 的网站速度测试，查看可用的移动端和桌面端 Lighthouse 结果，并结合抓取报告确认受影响页面。把已核实的问题交给 Runner，审核修改、检查预览，再单独决定发布。缺失指标不代表通过检测，评分也不能证明所有顾客的体验；发布后仍需对同一地址和设备重新测量，并复查原来的购物操作。"
category: ai-cro
h1: "网站速度测试，让问题变成可审核的商店修改"
keyword: "网站速度测试"
legacyKind: structured
---

**网站速度测试**测量的是页面在特定测试条件下的加载表现。Runner AI 的网站审核可以包含 Lighthouse 检查，并在抓取问题旁展示可用的移动端和桌面端结果。你需要先有已发布的在线商店和符合条件的 SEO 分析目标。把保存的证据用于提出范围明确的修改请求，不要把评分当成所有顾客的体验，也不要以为运行审核会自动改变商店。

## 从可访问的在线商店开始网站速度测试

打开商店项目，进入<strong>增长</strong>，再进入<strong>SEO</strong>。如果 Runner 显示首次设置清单，先满足发布要求并完成初次分析，再查看报告。标为示例的数据只是演示，不是你商店的测量结果。解释任何评分前，先打开准备分析的公开地址，确认它确实是目标在线商店。

打开网站健康状态卡片，进入网站审核视图。新建审核的操作会打开设置，不会修改商店。选择合适的最大页面数，启用 Lighthouse 选项，再运行审核。页面数限制的是抓取范围，并不意味着每个被抓取的地址都有独立的移动端和桌面端 Lighthouse 测试。查看结果旁显示的已分析地址，确认测量对应哪一页。

等待报告完成，不要把已启动的审核当成已完成的测量。在检查记录中保留目标地址，以及上一次检查后做过的商店修改。[电商网站审核](/zh/ecommerce-website-audit)帮助你整理技术问题和购物流程中的障碍。本页关注该流程中的可选速度证据，不是同时模拟大量顾客的负载测试，也不是持续监控网站是否在线。

## 阅读移动端和桌面端结果，不补填缺失指标

Lighthouse 结果可用时，Runner 会分别展示移动端和桌面端卡片，包含可用的性能、无障碍、最佳实践和 SEO 评分，以及供应商返回的指标。比较两次分析前，先核对设备和地址。桌面端表现良好不代表移动端同样良好，综合评分也不能解释每一种延迟的原因。

指标网格可能包含首次内容绘制（FCP）、最大内容绘制（LCP）、总阻塞时间（TBT）、速度指数、可交互时间（TTI）、累积布局偏移（CLS）、交互到下一次绘制（INP）和首字节时间（TTFB）。具体值取决于供应商的返回数据。横线表示没有可用值，不表示零延迟、检测通过，也不是让你自行估算。时间和布局偏移衡量的不是同一件事。

把这些结果理解为一次具体分析的证据，而不是所有顾客体验的统计。实验室测量、真实使用数据和浏览器预览回答的是不同问题。需要深入诊断或真实用户背景时，可以通过[网站优化工具](/zh/website-optimization-tools)选择补充证据。不要仅凭评分变化就宣称转化率上升、搜索排名改善或加载时间得到保证。

## 把一个已确认的问题交给 Runner 修改

在问题和页面视图中找到受影响的地址，阅读保存的发现。页面响应时间可以提供背景，但不等同于主要视觉内容出现所需的时间。打开公开页面，重现你觉得缓慢的顾客操作。记录路径、设备、初始状态、预期结果和实际延迟，不要发送凭据或顾客的私人信息。

选择合适问题上的 Runner 修复操作，会打开包含选定证据和工作请求的对话。修复全部问题的选项会发起更广泛的对话。这两种操作都不会自行应用修改或发布在线商店。把请求限定到可以审核的范围，并要求调查时保留产品事实、导航、购买控件以及无关内容。

例如，商品页的主图出现较晚，就说明具体页面和观察到的行为。先请 Runner 查明原因，不要直接要求删除所有图片或脚本。第三方依赖或经营限制可能需要另外作出决定。[电商网站无障碍](/zh/ecommerce-website-accessibility)检查可以帮助你确认，速度修改没有删掉标签、焦点行为或顾客需要的信息。

## 发布后重新测试，并区分不可用的检查

在预览中审核提议的修改，再执行原来的顾客操作。确认商品选择、导航、购物车交互和受影响内容仍然正常。检查预览不会更新公开商店。只发布你批准的工作，重新打开公开地址，然后用同一个已分析地址和设备，将新审核与原来的证据进行比较。

保持比较范围明确。如果内容、目标或测试条件发生变化，就记录差异，不要把每次评分波动都归因于修改。对可疑结果重复检查后再下结论，并保留最初想改善的具体指标或可见行为。评分更高不能替代检查顾客是否还能完成原来的任务。

Runner 会区分未请求 Lighthouse 和 Lighthouse 不可用。如果没有请求，就启用选项后再运行审核。如果不可用，先查看已完成的抓取发现，之后再尝试可选检查。抓取失败时，确认公开地址可访问，并考虑缩小审核范围。缺失证据仍是未解决的检查，不代表网站速度良好。[Runner AI 功能目录](/zh)介绍相关的商店改进流程。

## 常见问题

### Runner AI 会用 Lighthouse 测试每个页面吗？

不要这样假设。最大页面数限制的是技术抓取，Lighthouse 结果会注明已分析地址。把结果用于商品、分类或结账页面之前，先检查该地址和可用的设备卡片。速度证据应该始终对应实际测量的页面和条件，不能从一页的评分推断整个商店。

### 缺少指标意味着页面通过检测吗？

不意味着。横线表示该指标没有可用值，不表示零毫秒，也不表示核心网页指标通过检测。将缺失值与已有评分分开。如果这个指标会影响你的决定，就使用合适的额外测量。不要把供应商的不完整数据变成性能承诺。

### 选择 Runner 修复会自动让商店变快吗？

不会。它会打开包含证据和工作请求的对话。你需要审核修改建议、检查预览，再单独决定发布。之后重做受影响的操作，并测量公开结果。新对话或已接受的代码修改都不能证明加载速度改善或转化率上升。

### 抓取完成但 Lighthouse 不可用时怎么办？

使用已有的抓取结果，并保留可选检查的未解决状态。确认目标公开地址，之后再尝试 Lighthouse。不要用示例数据或虚构评分替代缺失结果。抓取完成和网站速度测试取得可用结果是两种不同的结果，需要分别确认。