How fast is your website, really?
Run a full Lighthouse audit on any public URL. You'll get Core Web Vitals from real visitors, lab metrics from a controlled run, and a prioritised list of what to fix first — in under a minute, free, no signup.
Two kinds of data, one report
Speed tools disagree because they measure different things. This report shows both sources side by side so you can tell a real problem from a noisy measurement.
Field data — what your visitors felt
Pulled from the Chrome UX Report: anonymised measurements from real Chrome users over the last 28 days. It's the data Google uses to assess Core Web Vitals, so it's the number that matters for search. It only exists once a page gets enough traffic.
Lab data — a controlled, repeatable run
Lighthouse loads your page in a headless Chrome on emulated hardware with a throttled network. Every run uses identical conditions, which makes it the right tool for checking whether a change actually helped.
- 1
Paste a URL
Any public page. Pick mobile or desktop — Google ranks on mobile, so start there.
- 2
We run Lighthouse
Google's servers load the page, throttle it, and score around 50 audits.
- 3
Fix the top items
Opportunities are sorted by estimated time saved. Start at the top and re-run.
What each number actually means
Core Web Vitals come first — they're the three metrics Google uses as a ranking signal. The rest explain how you got there.
Largest Contentful Paint
LCPHow long until the biggest thing on screen — usually a hero image or headline — has rendered. This is the metric visitors experience as 'the page loaded'.
Good: under 2.5s
Interaction to Next Paint
INPHow quickly the page responds when someone taps or clicks. High INP almost always means too much JavaScript running on the main thread.
Good: under 200ms
Cumulative Layout Shift
CLSHow much the layout jumps while loading. Caused by images without dimensions, late-loading fonts, and ads injected above existing content.
Good: under 0.1
First Contentful Paint
FCPWhen the first text or image appears. It tells the visitor something is happening, even if the page isn't finished.
Good: under 1.8s
Total Blocking Time
TBTHow long the main thread was blocked and unable to respond during load. It's the lab stand-in for INP, and the single best predictor of a sluggish-feeling page.
Good: under 200ms
Time to First Byte
TTFBHow long your server took to start responding. Slow TTFB delays everything after it, so fix this before optimising anything on the front end.
Good: under 800ms
