PageSpeed & Vitals

Summary#

PageSpeed & Vitals runs a genuine Google Lighthouse audit on any URL and renders the complete PageSpeed Insights report inside Metric Vault: Performance, Accessibility, Best Practices and SEO scores, all six lab metrics, the real-user Core Web Vitals field data, and every failing audit with its estimated saving. It costs no credits.

Purpose#

Speed is a ranking signal and a conversion signal, and both Google and your visitors judge it on specific, published thresholds. Guessing whether a page is "fast enough" is not useful; knowing that its Largest Contentful Paint is 4.1 seconds against a 2.5-second target is.

This tool exists so you never have to leave the workspace to answer that question, and so the speed evidence sits alongside the rest of your technical audit. The decision it helps you make is which specific asset, script or image to fix next, and how much time it will buy you.

Overview#

You give it a URL. Metric Vault calls Google's PageSpeed Insights API, which runs Lighthouse on Google's own infrastructure with all four categories enabled. The first run is Mobile — the profile Google indexes and ranks from. The full Lighthouse result is returned and rendered as the same report you would see on pagespeed.web.dev, with device tabs at the top.

Clicking Desktop runs a second Lighthouse audit and caches it, so switching back and forth afterwards is instant. Both runs are free.

Two things worth knowing about timing. A Lighthouse run is genuinely slow — Google's runner takes 10-15 seconds for a trivial page and up to 75 seconds for a heavy commercial site — so the tool waits patiently rather than failing early. And a successful result is cached for 6 hours, so re-running the same URL inside that window returns instantly.

Benefits#

• The real Lighthouse report, not a summary of it — every audit, every details table, the screenshot filmstrip and the stack-pack hints.
• Field data included. Real-user Core Web Vitals from the Chrome User Experience Report, which lab tests cannot give you.
• Mobile and Desktop side by side, each a separate real run, both free.
• Free on every plan, with no credit cost at all.
• Cached for 6 hours, so repeated checks during a fix session are instant.

Use Cases#

• Diagnosing a Core Web Vitals failure. Search Console flags a URL group; this tells you which metric fails and which resources cause it.
• Proving a performance fix worked. Run before, deploy, wait out the cache, run again.
• Comparing against a competitor. The in-report Compare button prompts for a competitor URL and runs it in the same view.
• Building the case for engineering time. The estimated savings on each opportunity convert directly into "this change saves 1.2 seconds".
• Checking a landing page before a campaign. A slow page wastes paid clicks as surely as it wastes organic ones.

Requirements#

• A signed-in Metric Vault account.
• Any plan, including Free.
• A publicly reachable URL that Google's crawler can load. Private, internal and loopback hosts are refused, and pages behind a login cannot be measured.
• No credits and no integration.

Permissions#

No role restriction applies. See Roles and what each can do.

Cost#

0 credits. The button reads Run Lighthouse · FREE. Neither the Mobile run nor the Desktop run touches your monthly credit allowance. Both count toward the fair-use limit of 100 light-tool calls per hour shared across the zero-credit tools. See How credits work.

Because it is free there is no "You already ran this" prompt. A successful result is stored for 6 hours and re-served during that window; if Google is unavailable or over quota, a previously stored result up to 30 days old is shown rather than an error.

Navigation Path#

Dashboard → Site Health → PageSpeed & Vitals

Inputs#

Step-by-Step Guide#

1. Open Dashboard → Site Health → PageSpeed & Vitals.
2. Optionally click See example to view a stored sample report at no cost.
3. Paste the page URL into the field marked e.g. https://nike.com.
4. Click Run Lighthouse · FREE, or press Enter in the field.
5. Wait. Analyzing… this can take a few seconds for live data. can stay on screen for up to about 80 seconds on a heavy page. Do not re-click.
6. Read the Mobile report. Click Desktop when you want the second profile — an overlay reads "Running Lighthouse on Desktop…" and "A fresh audit takes 15-30 seconds."
7. Use Schedule in the report toolbar for a recurring audit, or Compare to run a competitor URL.
8. Export from the row at the top of the screen: Export PDF, Export Excel, Export CSV, Export JSON or Share public link. See Exporting results.

Reading the Results#

The report is laid out exactly like Google's own, top to bottom.

Device tabs. Mobile and Desktop, with the analyzed URL on the right. Mobile is the one that matters for ranking — Google indexes mobile-first. A page that scores 92 on Desktop and 38 on Mobile has a mobile problem, not a good score.

Discover what your real users are experiencing. This is field data: what actual Chrome users measured on your page over the last 28 days. It carries a Passed or Failed — Core Web Vitals Assessment badge, and where enough data exists you get This URL and Origin scope tabs — the origin tab is useful when a single URL has too little traffic to report.

Six metrics appear, each with its value, a colored distribution bar and the share of visits that were good, needs-improvement or poor:

If the page is new or low-traffic you will see instead: "The Chrome User Experience Report does not have sufficient real-world speed data for this page." That is not a failure — it means too few real visits, and the lab section below still applies.

The four gauges. Performance, Accessibility, Best Practices and SEO, each 0-100, with the legend 0–49 (red), 50–89 (orange), 90–100 (green). Click a gauge to jump to its section. Aim for 90+ on Accessibility, Best Practices and SEO — those are largely fixable with markup. Performance is the hard one, and 50-89 is a normal, workable position for a real commercial site.

Performance. The lab metrics, measured in Google's simulated environment: First Contentful Paint, Largest Contentful Paint, Total Blocking Time, Cumulative Layout Shift, Speed Index and Time to Interactive, each with a green, orange or red marker. A footnote reads "Values are estimated and may vary. The performance score is calculated directly from these metrics."

Below them, the final rendered screenshot and a filmstrip of load frames with their timings — the fastest way to see when your page becomes useful.

Then Diagnostics: every failing performance audit, sorted by estimated saving, largest first. Each row expands into Google's own details table with the specific files, elements and byte counts. This is the actionable part of the whole report; work down it from the top.

Accessibility, Best Practices and SEO. Each has a gauge and its failing audits grouped by theme, with the same expandable detail tables. SEO failures here overlap with On-Page SEO Checker and are usually the cheapest points on the page.

The folds. At the bottom of each category: "N passed audits", "N not applicable" and, for accessibility, "N manual checks to conduct". Open the manual list before you claim a page is accessible — those are the checks a machine cannot do.

Report footer. "Captured at time · Emulated Moto G Power (or Desktop) · Lighthouse version · locale", plus any detected platform hints ("Detected: WordPress") that add framework-specific advice to the audits.

What good looks like: a passed Core Web Vitals Assessment with LCP under 2.5 s and CLS under 0.1. What bad looks like: a failed assessment, or a Performance score under 50 with several multi-second savings in Diagnostics.

Examples#

Screenshots#

Tips#

• Always read Mobile first. It is what Google ranks from.
• Field data beats lab data when the two disagree — field data is your real users; lab data is a simulation.
• Wait out the 6-hour cache before re-testing a deploy, or you will be shown the pre-fix result and think nothing changed.
• Use Compare to run a competitor's equivalent page and set a realistic target rather than chasing 100.
• Test the page type, not just the home page. Checkout and product pages are usually the slowest and the most valuable.

Best Practices#

• Fix in Diagnostics order. The list is already sorted by the time each change saves.
• Treat CLS separately from speed — layout shift is usually a missing width or height attribute, not a slow network.
• Re-run after each deploy and keep the exports; a series of reports is the only way to show progress.
• Use Schedule for pages that matter commercially, so a regression surfaces by email rather than in a ranking drop.
• Pair with Site Audit for the site-wide view and Responsiveness for layout behavior across screen widths.

Common Mistakes#

• Testing only the home page. It is rarely representative and rarely the page that earns money.
• Chasing a Performance score of 100. Real commercial pages with real third-party scripts do not reach it. Passing Core Web Vitals is the goal.
• Treating "no field data" as a failure. It means too few real visits, not a slow page.
• Re-running immediately after a deploy. The 6-hour cache will return the old result.
• Ignoring Accessibility because it is not SEO. It is the cheapest score to raise and it overlaps heavily with usability.

Limitations#

• One URL per run, and one device profile per run. Desktop is a second run, triggered by its tab.
• Google's daily quota applies. PageSpeed Insights is a Google service with a per-project daily cap; when it is exhausted the tool says so explicitly.
• Heavy pages can time out. The tool allows about 75 seconds for one Lighthouse run and about 82 seconds in total; beyond that it reports a timeout rather than hanging.
• Pages that block automated requests cannot be measured, and pages behind a login are out of scope.
• Field data is not always available, and where it is, it lags by up to 28 days.
• Lab metrics are simulated. They are consistent and comparable, but they are not what any individual user experienced.

Troubleshooting#

FAQs#

Is this the same as pagespeed.web.dev? Yes, in substance. It calls the same Google PageSpeed Insights API, runs the same Lighthouse audits, and renders the same report — with device tabs, export and scheduling added.

Does it cost credits? No. Both the Mobile and Desktop runs are free on every plan, including Free. See What you get on Free.

Why is my Desktop score so much better than Mobile? Mobile Lighthouse emulates a mid-range phone on a throttled connection; Desktop does not throttle. The gap is normal. Mobile is the number that affects ranking.

Why do the lab and field numbers disagree? Lab data is one simulated load from Google's infrastructure. Field data is what real Chrome users measured over 28 days, on their own devices and connections. When they disagree, trust the field data and use the lab data to find the cause.

How often can I run it, and will it always be fresh? As often as you like within the 100-per-hour fair-use limit, but a successful result is reused for 6 hours. To measure a change, wait out that window.

Can I schedule it or get alerted on a regression? Yes. Schedule in the report toolbar sets up a recurring audit. Scheduling requires a paid plan. See Scheduled reports.