How to run PageSpeed Insights on localhost

You cannot point PageSpeed Insights at a local address, and no setting will change that. Here is why, the four options that actually work, and the accuracy each one costs you.

Updated 3 September 2026 · Lighthouse v13

Short answer

PageSpeed Insights cannot audit localhost. It is a hosted service: you submit a URL and Google's servers fetch it from Google's own network, where localhost means Google's loopback interface, not your machine. What you can do instead is run the same Lighthouse engine locally, through the Chrome DevTools Lighthouse panel, the Lighthouse CLI, or a local console such as LightAudit Score. A tunnel will make PSI work, but it distorts the numbers.

Why PageSpeed Insights cannot reach your machine

PageSpeed Insights is two things stitched together: a hosted run of Lighthouse, and a lookup against the Chrome UX Report. Both halves are the reason localhost fails.

When you submit a URL, nothing is fetched by your browser. The request goes to Google, and a machine in Google's infrastructure opens the page. That machine resolves localhost and 127.0.0.1 against its own network stack, so it is looking at itself, not at you. There is no tunnel between the PSI form and your laptop, and there is no option to create one.

The same applies to every address that is only meaningful inside your network:

localhost:3000, 127.0.0.1 and [::1]
Private ranges such as 192.168.1.20 and 10.0.0.5
.local hostnames published over mDNS or Bonjour
A staging host that only resolves inside your VPN
An intranet application with no public DNS record
Any URL behind an authentication wall that Google's fetcher cannot pass

You will see the address rejected as invalid, or a Lighthouse failure such as ERRORED_DOCUMENT_REQUEST. It is not a misconfiguration on your side.

Four options that work

All four give you Lighthouse lab data for a local page. They differ in what they cost you: setup, accuracy, or the work of building the parts around the audit yourself.

Option 01

The Chrome DevTools Lighthouse panel

The fastest route, and the right first answer for most people. Open the page in Chrome, open DevTools, choose the Lighthouse panel, pick a device and categories, then click Analyze page load. It runs the same engine PSI runs, in your own browser, so anything the tab can open it can audit: localhost, a VPN host, a page behind a login you are already signed in to.

What it costs youOne page per run and one run per click, so no median and no way to see through Lighthouse's run-to-run noise. No history: close the tab and the result is gone. Browser extensions inject scripts into the page and can move the Performance score by double digits, so audit in a Guest or Incognito profile with extensions disabled.

Option 02

The Lighthouse CLI

The same engine as a command, which makes it scriptable and puts the full JSON on disk.

$ npx lighthouse http://localhost:3000 --view

# desktop preset, performance only, JSON on disk
$ npx lighthouse http://localhost:3000 \
    --preset=desktop \
    --only-categories=performance \
    --output=json --output-path=./report.json

# headless, for a script or a CI step
$ npx lighthouse http://localhost:3000 \
    --chrome-flags="--headless=new"

What it costs youEverything around the audit is yours to build. Batching a list of URLs, repeating each one and taking the median, storing results so you can compare next week, and turning the JSON into something a colleague will read are all your problem.

Option 03

A tunnel, so PSI genuinely can reach you

If you specifically need PageSpeed Insights itself, expose the port publicly and give PSI the public URL.

$ ngrok http 3000
# or
$ cloudflared tunnel --url http://localhost:3000

Paste the resulting HTTPS address into PageSpeed Insights and it will audit normally.

What it costs youAccuracy, in a way that is easy to miss. Every request now travels from Google's fetcher to the tunnel provider's edge, through the tunnel, to your machine, and back. That round trip sits on the critical path, so time to first byte is inflated and both First Contentful Paint and Largest Contentful Paint read worse than the same build would score in production. The result is a valid audit of a badly served page. Use it as a smoke test, never as a baseline you optimise against.

Option 04

A local console: LightAudit Score

Runs the Lighthouse engine on your machine, like the DevTools panel, but with the parts option 01 and option 02 leave you to build. Paste a list of URLs or crawl a site, audit every page in one batch, repeat each URL and report the median, and keep the history on disk so you can diff today against last week. It also calls PageSpeed Insights for the public URLs where PSI genuinely adds something, so lab and field data end up in the same table.

What it costs youYou run it yourself. It needs Node.js 24 or later and Google Chrome, and the first start builds once. It is free and open source under MIT, with no account.

What no tool can give you for localhost

This is the part that catches people out, and it is worth being blunt about.

PageSpeed Insights shows two separate things. Lab data is a single controlled Lighthouse run in a simulated environment, and it is fully reproducible on your own machine by any of the four options above. Field data comes from the Chrome UX Report: real measurements from real Chrome users who opted in, aggregated at the 75th percentile over a rolling 28 days.

Field data for a local URL does not exist

CrUX only publishes an origin or a URL once enough real users have visited it to be statistically meaningful. Nobody visits your laptop. So there is no Core Web Vitals field data for localhost, there never will be, and any tool that appears to show you some is showing you origin-level data for a different host. Lab data is the whole of what is available locally, from anything.

That is not a reason to skip local auditing. Lab data is exactly what you want while you are changing code, because it is controlled and repeatable in a way field data never is. Just do not expect a local run to tell you what users experience, and do not compare a local score against a production PSI score and conclude something regressed.

The four options side by side

Capability	DevTools panel	Lighthouse CLI	Tunnel + PSI	LightAudit Score
Audits localhost	Yes	Yes	Indirect only once it is public	Yes
Numbers undistorted by transport	Yes	Yes	No tunnel latency inflates TTFB and LCP	Yes
Many URLs in one run	No one page per click	Scripted you write the loop	No one URL per run	Yes paste a list or crawl a site
Median of repeated runs	No	Manual run it and take the median yourself	No	Yes default 3, isolated Chrome per run
History you can compare against	No gone when the tab closes	Files if you keep the JSON	No	Yes local SQLite, trends and a two-run diff
Real-user field data for the local URL	No	No	No a tunnel URL has no real users	No impossible for any tool
Setup required	None	Node.js	Tunnel account	Node.js 24+, Chrome

Frequently asked questions

Can PageSpeed Insights test a localhost URL?

No. PageSpeed Insights is a hosted service: you submit a URL and Google's servers fetch it from Google's own network. On that network, localhost and 127.0.0.1 mean Google's own loopback interface, not your machine, so there is nothing for it to audit. The same applies to any private address, including 192.168.x.x, 10.x.x.x, a .local hostname, a staging box behind a VPN, and an intranet host.

What error does PageSpeed Insights give for a localhost URL?

You will usually see the URL rejected outright as invalid, or a Lighthouse error such as ERRORED_DOCUMENT_REQUEST or FAILED_DOCUMENT_REQUEST. Both mean the same thing: Google's fetcher could not retrieve a document at that address. It is not a bug or a misconfiguration on your side, and no setting in PageSpeed Insights will change it.

Is the Chrome DevTools Lighthouse panel the same as PageSpeed Insights?

They run the same Lighthouse engine, so the lab audits and the Performance score are calculated the same way, but they are not the same tool. The DevTools panel runs in your browser on your CPU and your network, so it can reach localhost. PageSpeed Insights runs on Google's hardware from a fixed location, and adds real-user field data from the Chrome UX Report, which the DevTools panel does not have.

Does exposing localhost through a tunnel give accurate PageSpeed scores?

It gives you a working audit, but not an accurate one. A tunnel such as ngrok or cloudflared routes every request from Google's fetcher to the tunnel provider's edge and then down to your machine, which adds a round trip to the critical path. Time to first byte is inflated, and First Contentful Paint and Largest Contentful Paint read worse than the same build would score in production. Treat tunnel numbers as a smoke test, never as a baseline.

Can I get Core Web Vitals field data for localhost?

No, and no tool can provide it. Field data in PageSpeed Insights comes from the Chrome UX Report, which aggregates measurements from real Chrome users who opted in, and only publishes an origin or URL once it has enough traffic to be statistically meaningful. A local address has no real users, so there is no data to report. Lab data is the only thing any tool can give you for localhost.

Audit the pages Google cannot see

LightAudit Score runs Lighthouse and PageSpeed Insights from one local console: localhost, staging and VPN hosts, whole sites in one batch, median-of-N runs, and history that survives a restart. Free, open source, no account.

See what it does