See how fast your page
really loads.

How to run a page speed test

A page speed test loads one page the way a visitor's browser would, times each stage, and tells you what slowed it down. Test the pages that matter most, not only your homepage: your top landing pages, product pages and best-ranking articles.

1. 1Paste the full URL of the page, path included
2. 2Pick mobile or desktop (start with mobile, since Google indexes the mobile version first)
3. 3Run the test and wait 20 to 40 seconds for Lighthouse to finish
4. 4Read the score, then the core metrics, then the biggest opportunities
5. 5Run it two or three times and go by the typical result, not one number

Why page speed matters

Speed is both a user-experience and an SEO issue. People abandon pages that hang, so a slow site bleeds conversions before anyone reads it. And since Core Web Vitals became part of Google's page-experience signals, a sluggish page can quietly cost you positions too.

The goal isn't a perfect 100, it's clearing Google's "good" thresholds and giving real visitors a fast, stable experience.

Every number in your report, explained

The report has three parts: an overall performance score, six core metrics with a colored dot for each (green good, amber needs work, red poor, graded by Lighthouse's own scoring for the device you picked), and the biggest opportunities.

Performance score

Lighthouse's 0 to 100 score, a weighted blend of five lab metrics: Total Blocking Time 30%, Largest Contentful Paint 25%, Cumulative Layout Shift 25%, First Contentful Paint 10% and Speed Index 10%. 90 and up is labelled Fast, 50 to 89 Needs work, below 50 Slow.

Largest Contentful Paint (LCP)

How long until the biggest thing in view, usually a hero image or headline, has rendered. It's the closest single measure of when a page feels loaded.

Cumulative Layout Shift (CLS)

How much visible content jumps around while the page loads, as a unitless score. Images without set dimensions, late ads and web fonts swapping in are the usual causes.

Total Blocking Time (TBT)

How long, in total, the main thread was blocked by long tasks between first paint and the page becoming usable. It's the lab stand-in for INP and carries the most weight in the score.

First Contentful Paint (FCP)

How long until the first text or image appears, the moment a visitor sees the page is doing something.

Speed Index

How quickly the visible part of the page fills in, measured from a video of the load. Lower is better.

Time to Interactive

How long until the page is reliably usable. It's shown for context but no longer counts toward the score.

Biggest opportunities

Up to five fixes Lighthouse estimates would save more than 0.1 seconds each, largest saving first. The time is Lighthouse's projection, not a guarantee. If no fix clears that bar, the section doesn't appear.

Lab data vs field data

There are two kinds of speed data, and they answer different questions. Lab data comes from one controlled test: Lighthouse loads the page on a simulated device and network and records what happened. It's repeatable and shows you exactly what to fix, which is what this tool gives you.

Field data, also called real-user data, comes from actual Chrome visitors. Google collects it in the Chrome UX Report (CrUX) over a rolling 28 days and reports the 75th percentile of each metric, so three in four visits need to be good for the page to count as good. Field data is what Google uses for its Core Web Vitals assessment and its page-experience signals.

This tool doesn't show field data. To see it, check the top section of Google's PageSpeed Insights report or the Core Web Vitals report in Google Search Console. Pages and sites with little traffic often have none, because there aren't enough visits to report on.

The two often disagree. A lab test is one load on one device, while your real visitors use a mix of phones, networks and cached files. Use field data to know whether you have a problem and lab data to find the cause.

What the Core Web Vitals mean

Google judges page experience on three metrics, each at the 75th percentile of real visits. A page passes the Core Web Vitals assessment only when all three are in the good range.

Interaction to Next Paint replaced First Input Delay (FID) as a Core Web Vital in March 2024. INP needs real taps and clicks, so no lab test can measure it. Total Blocking Time, which this report shows, is the lab metric that tracks it most closely.

Largest Contentful Paint (LCP)

Good is 2.5 seconds or less, needs improvement up to 4 seconds, poor beyond that.

Interaction to Next Paint (INP)

How long the page takes to respond visibly to a tap, click or key press. Good is 200 milliseconds or less, needs improvement up to 500 milliseconds, poor beyond that.

Cumulative Layout Shift (CLS)

Good is 0.1 or less, needs improvement up to 0.25, poor beyond that.

What is a good page speed score?

90 or above is good, 50 to 89 needs work, and below 50 is poor. Most sites score lower on mobile than on desktop, often by a wide margin, and that's expected.

Treat the score as a summary, not the target. A page can score 75 and still pass Core Web Vitals for real visitors, or score 95 in the lab and fail in the field. Fix the metric that's red, then the one that's amber.

Mobile vs desktop results

On mobile, Lighthouse emulates a mid-range phone on a slow 4G connection, so large images and heavy JavaScript cost far more time. On desktop it uses a fast connection and separate, stricter scoring curves: a load time that earns green on mobile can be amber on desktop.

Test both, but fix mobile first. Google indexes the mobile version of your site, and for most sites the majority of visits come from phones.

Why your score changes between runs and between tools

Run the same page twice and you'll usually get two slightly different scores. Network routing, server load, rotating ads, A/B tests and third-party scripts all change from one load to the next. A few points either way is noise.

Different speed test tools disagree for the same reasons, plus a few of their own: a different test location, device, connection speed or throttling method, and different definitions of "load time". Pick one tool, test the same pages under the same settings, and compare results over time.

How to fix each Core Web Vital

Each metric has its own usual suspects. Start with whichever is red in your report.

Slow LCP

Make the main image smaller and in a modern format (WebP or AVIF), don't lazy-load it, and consider a fetchpriority="high" hint on it. Cut render-blocking CSS and JavaScript, and speed up the server response with caching or a CDN.

High CLS

Give every image, video and embed a width and height, or an aspect ratio, so the browser reserves the space. Reserve room for ads and banners, and avoid inserting content above what's already on screen.

High TBT or poor INP

Ship less JavaScript: remove unused code, split bundles, defer what isn't needed at load, and audit third-party scripts like chat widgets and trackers. Break long tasks into smaller ones so the page can respond between them.

Slow server response

If even First Contentful Paint is slow, the delay often starts before the browser gets any HTML. Page caching, a CDN, a faster host or fewer redirects usually help most.

How to speed a page up

Most wins come from a short list: compress and lazy-load images below the fold, cut and defer unused JavaScript, cache aggressively, and reserve space for images and embeds so nothing shifts. Work down the opportunities list, biggest saving first.

1. 1Compress images and serve modern formats (WebP/AVIF)
2. 2Defer or remove unused JavaScript and third-party scripts
3. 3Reserve space for images and embeds to kill layout shift
4. 4Cache assets and use a CDN
5. 5Re-test after each change to confirm the gain

Does page speed matter for AI search?

Probably a little, and mostly indirectly. AI tools that search the web before answering, like ChatGPT search, Perplexity and Google's AI Overviews, tend to cite pages that already rank, and speed is one small input into ranking. A page that times out or loads its text only through heavy JavaScript may also be harder for some AI crawlers to read. No AI company publishes how it picks sources, so treat this as a likely benefit, not a rule.