Website speed testing measures how a page loads under the conditions of a particular test. Runner AI’s site audit can include Lighthouse checks and display available mobile and desktop results alongside crawl findings. Start with a published storefront and an eligible SEO target. Use the saved evidence to request a bounded correction, not to assume that a score proves every shopper’s experience or automatically changes your store.
Start website speed testing with a reachable storefront
Open your store project and go to Grow, then SEO. If Runner shows the initial setup checklist, complete its publication requirement and initial analysis before expecting a report. A card marked as sample data is illustrative, not a measurement of your store. Confirm that the public storefront opens at the address you intend to assess before interpreting any result.
Open the Site health card and enter the site-audit view. Start New Audit opens the settings rather than editing the store. Choose an appropriate maximum-page limit, enable Include Lighthouse, and select Run audit. The page limit controls the crawl; it does not mean every crawled URL receives a separate mobile and desktop Lighthouse test. Check the analyzed URL shown with the Lighthouse results.
Wait for the report instead of treating a started audit as a completed measurement. Keep the target address and the storefront changes made since the previous check in your review notes. The broader ecommerce website audit helps organize technical and customer-journey findings. This page focuses on the optional speed evidence within that workflow, not on load testing concurrent shoppers or monitoring uptime continuously.
Read mobile and desktop results without filling in missing values
When Lighthouse results are available, Runner presents separate mobile and desktop cards. They show the available performance, accessibility, best-practice, and SEO scores, followed by reported metrics. Review the device and analyzed address before comparing runs. A good desktop result does not establish that the mobile experience is equally good, and an overall score does not explain every source of delay.
The metric grid can include First Contentful Paint, Largest Contentful Paint, Total Blocking Time, Speed Index, Time to Interactive, Cumulative Layout Shift, Interaction to Next Paint, and Time to First Byte. Values depend on what the provider returned. A dash means the value is missing; it is not zero delay, a passing result, or a reason to invent an estimate. Timing values and layout-shift values also measure different things.
Read these results as evidence from a particular analysis rather than a census of real shoppers. Lab measurements, field measurements, and a browser preview answer different questions. Use website optimization tools to choose complementary evidence when you need deeper diagnostics or real-user context. Do not claim a conversion increase, a ranking improvement, or a guaranteed loading time merely because an audit score changed.
Turn one verified finding into a storefront correction
Use the crawl’s Issues and Pages views to locate the affected URL and inspect the saved findings. A page’s response time is useful context, but it is not interchangeable with the time its main visual content takes to appear. Open the public page and reproduce the customer task that feels slow. Record the route, device, starting state, expected result, and observed delay without sending credentials or private customer details.
Choose Fix with Runner on an appropriate issue to open a conversation with the selected evidence and a correction request. Fix all with Runner starts a broader conversation. Neither action applies an edit or publishes the storefront by itself. Keep the request narrow enough to review, and ask Runner to preserve product facts, navigation, purchase controls, and unrelated content while it investigates the affected page.
For example, if a product page’s main image appears late, identify that page and the observed behavior. Ask Runner to investigate before prescribing removal of every image or script. A third-party dependency or operating constraint may require a decision outside a storefront edit. A separate ecommerce website accessibility review helps ensure that an attempted speed correction does not remove labels, focus behavior, or information shoppers need.
Retest the published change and distinguish an unavailable check
Inspect the proposed correction in Preview and repeat the original customer task. Confirm that product selection, navigation, cart interactions, and the affected content still work. A preview review does not update the public storefront. Publish only the work you approve, open the public address again, and then compare a new audit with the earlier evidence for the same analyzed URL and device.
Keep website speed testing comparisons bounded. If the content, target, or test conditions changed, record that difference instead of attributing every score movement to the edit. Repeat a suspicious result before drawing a conclusion, and retain the specific metric or visible behavior you wanted to improve. A higher score is not a substitute for checking that the shopper can complete the original task.
Runner distinguishes Lighthouse that was not requested from Lighthouse that is unavailable. If it was not included, request an audit with the option enabled. If it is unavailable, inspect the crawl findings that completed and retry the optional check later. For a failed crawl, confirm the public URL is reachable and consider a smaller audit. Missing evidence remains an unresolved check, not proof that the store is fast. The Runner AI feature catalog covers related storefront improvement workflows.
Website speed testing FAQ
Does Runner AI test every page with Lighthouse?
Do not assume so. The maximum-page setting limits the technical crawl, while the Lighthouse result identifies its analyzed URL. Inspect that address and the available mobile and desktop cards before applying the result to a product, collection, or checkout route. Website speed testing evidence should stay attached to the page and conditions it actually describes.
Does a missing metric mean the page passed?
No. A dash means no value is available for that metric. It does not mean zero milliseconds or a passing Core Web Vitals result. Keep missing values separate from reported scores, and use an appropriate additional measurement when that metric matters to your decision. Do not turn incomplete provider data into a performance claim.
Does Fix with Runner automatically make the store faster?
No. It opens a conversation with evidence and a request for work. Review the proposed correction, inspect the preview, and make a separate publication decision. Then repeat the affected task and measure the public result. Neither a new conversation nor an accepted code change proves a loading improvement or a conversion increase.
What if Lighthouse is unavailable but the crawl completed?
Use the crawl results that are available and keep the optional check marked as unresolved. Confirm the intended public target and retry Lighthouse later. Do not replace an unavailable result with sample data or an invented score. A completed crawl and a successful website speed testing result are different outcomes.