Test your website speed
See how your website performs, why it’s slow, and how to optimize it — full Lighthouse report with Core Web Vitals, top issues and a speed filmstrip.
Analysis runs on Google’s Lighthouse engine and takes 20–40 seconds.
What Core Web Vitals actually measure
Google grades your page on three metrics, and each one measures a different kind of pain a real visitor feels. Largest Contentful Paint (LCP) is how long until the biggest visible element — usually your hero image or headline block — finishes rendering. Under 2.5s is good, 2.5s to 4s needs work, over 4s is poor. This is the metric most publishers fail, and it is almost always an image problem.
Cumulative Layout Shift (CLS) measures how much your content jumps around while loading. Under 0.1 is good, 0.1 to 0.25 needs work, above 0.25 is poor. If a reader taps a link and an ad injects itself above it a half-second later, that shift is what CLS is counting.
Interaction to Next Paint (INP) measures how long your page takes to visibly respond after someone taps or clicks. Under 200ms is good, 200ms to 500ms needs work, over 500ms is poor. INP can only be measured from real interactions, so Lighthouse cannot report it directly. Instead it gives you Total Blocking Time (TBT) as the lab proxy — the total time the main thread was jammed and unable to answer input. High TBT in the lab reliably predicts bad INP in the field. Chase TBT down and INP follows.
Lab data and field data disagree, and field data wins
The performance score at the top of your report is lab data: one simulated page load, on a throttled connection, on a mid-tier phone, in a data centre somewhere. It is a controlled experiment, not a measurement of your actual audience.
The CrUX section is field data: the 75th percentile of real Chrome users who visited your page over the trailing 28 days, on their real phones and their real networks. That is the number Google uses as a ranking signal. Lab data is a diagnostic tool that tells you why you are slow. Field data tells you whether you are slow.
This is also why your score bounces — run the test three times and you might see 71, 84, and 68. Nothing changed on your site. Network variance, CDN cache state, which ad creative happened to serve, and CPU contention on the testing machine all move the number by 10 to 15 points on a normal day. Do not celebrate or panic over a single run. Run it three times, take the middle, and only trust a change of 10 points or more as real.
What actually makes your page slow
In rough order of how much damage they do:
- Oversized images. The single biggest offender. A 2400px-wide, 1.8MB JPEG hero displayed at 800px is the classic LCP killer. Serve WebP or AVIF, size it to the container, and lazy-load everything below the fold — but never lazy-load the LCP image itself.
- Render-blocking JavaScript and CSS. Every synchronous script in your
<head>stops the browser from painting anything. Defer what is not critical, inline the CSS that is. - Third-party scripts. Ad tags, analytics, chat widgets, heat mapping, embedded fonts, social buttons. Each one is a DNS lookup, a connection, and main-thread work you do not control. Five of these will cost you more than your entire theme does.
- Slow server response (TTFB). Anything over 800ms means the clock is already running before a single byte of HTML arrives. Usually cheap hosting or an uncached database query.
- No caching or CDN. Free to fix, and the fix is often worth 300 to 600ms on repeat views.
- Unsized images and ad slots. Pure CLS. Every image needs explicit width and height attributes, and every ad slot needs reserved space.
Why this matters for AdSense approval and revenue
Speed hits AdSense from both ends. Before approval, a reviewer landing on a page that takes six seconds to paint sees a site that is not ready. After approval, the maths gets uglier: if a visitor bounces at 3s and your ad units have not rendered yet, that impression never existed. No impression, no viewability, no RPM. Slow pages do not earn less — they earn nothing on the sessions that quit early. If you want the fundamentals right before you apply, work through how to get AdSense approved alongside your speed fixes.
The uncomfortable part is that ad scripts are themselves a leading cause of bad Core Web Vitals. AdSense injects content asynchronously, which is exactly the behaviour CLS punishes. The fix is to reserve fixed height on every ad container in CSS so the slot occupies its space before the ad arrives. An empty reserved box costs you nothing; a shifting one costs you a ranking signal. Placement decides whether that trade is worth making — see ad placement best practices for where units actually pay, and how AdSense pays for how viewability feeds your earnings.
How to use this report without wasting a week
Fix mobile first. Your desktop score is nearly always 20 to 30 points higher and it is not where your traffic is. Mobile is throttled, mobile is where Google measures you, and mobile is where the money is.
Then ignore the score and open the Opportunities list. Find the single biggest number in seconds saved, fix that one thing, and re-test. One 1.9MB image compressed properly will move you further than a week of micro-tuning. Chasing the composite score directly leads you into deferring a 4KB stylesheet while a 900ms third-party script sits untouched.
And stop at good enough. A 100 is a vanity number that usually requires stripping out the ads paying your bills. Get LCP under 2.5s, CLS under 0.1, TBT low enough that INP stays under 200ms, and go write another article. A green field score at 85 beats a lab score of 98 on a site nobody reads.
How this test measures your page
When you run a URL through this tool, it hands the address to Google’s PageSpeed Insights engine, which is Lighthouse under the hood. That engine loads your page the way a real visitor would, but on a deliberately unflattering setup: a throttled mid-tier mobile profile, slower CPU, and a constrained network. The point is not to punish you. Most of your traffic arrives on exactly that kind of phone, so measuring on a fast laptop over office fibre would tell you nothing useful.
During that load it records the metrics that matter: LCP (when your largest content element paints), a Total Blocking Time figure that stands in as a lab proxy for INP, and CLS for layout shifting. It also captures a filmstrip of the render, frame by frame, so you can literally watch what your visitor stares at while the page assembles itself. When enough real Chrome users have visited your URL, it pulls the CrUX field data too. You are seeing the same engine Google itself uses to judge your page, not a third-party approximation of it.
A worked example: reading a real report
Say your report comes back with a mobile score of 62. That is a middling result, and the individual metrics tell you why. LCP lands at 3.4 seconds, flagged as “needs improvement,” and the diagnostics trace it to a hero image that ships at full desktop resolution with no compression. CLS sits at 0.18, well into the red, caused by an ad slot that has no reserved height, so the page jumps down the instant the ad fills in. TBT is high, and the culprit is a third-party chat widget loading its whole bundle before anything else can run.
Fix the CLS first. Reserving a fixed height for that ad slot is a one-line change and it kills the most visible, most annoying problem your visitors feel. Then compress and correctly size the hero image, which drags LCP down toward two seconds without touching your layout. The chat widget goes last: defer it, or load it only after the page is interactive. You just moved three metrics with three edits, none of which required rebuilding the site.
Limitations of a single speed test
One lab run is a snapshot, not a verdict. Run the same URL three times and the score can swing 10 to 15 points, because the network varied, your CDN cache was warm on one try and cold on the next, or a different ad happened to serve. None of that means your page changed. It means a single measurement carries noise.
Treat the lab result as a diagnostic that points at problems, and treat the field data as the truth about whether real people are suffering. If CrUX says your visitors are getting good LCP but a lab run flags it, believe your visitors. And remember what this test cannot do: it points, it never fixes. The score is a thermometer, not medicine. Reading it ten more times will not lower your temperature.
Related tools and next steps
Speed is one pillar of a page Google is willing to approve and rank. Once you have the metrics moving in the right direction, work through the rest:
- Hunt down broken links. Dead internal links and 404s waste crawl budget and read as neglect to a reviewer. Run the link checker and clear them before you apply.
- Run the full readiness audit. Speed and links are necessary, not sufficient. The complete AdSense readiness check looks at content depth, required policy pages, navigation, and the other signals a human reviewer weighs.
Do the speed pass, fix the two or three things this report actually flags, then move on. Chasing a perfect 100 while your site has thin content and no privacy policy is effort spent on the wrong wall.
Frequently asked questions
What does the page speed test measure?
It runs a full Google Lighthouse analysis on your URL and reports a performance grade, Core Web Vitals (Largest Contentful Paint, Total Blocking Time, Cumulative Layout Shift), a speed filmstrip, the biggest issues slowing your page down, and — when available — real-user CrUX field data.
How is this different from GTmetrix?
Both GTmetrix and this tool are built on Google Lighthouse, so the metrics line up closely. This test runs through Google's official PageSpeed Insights engine. It doesn't include a full request-by-request waterfall or saved test history — for those, a dedicated paid service like GTmetrix is still useful.
Why does page speed matter for AdSense?
Slow pages frustrate visitors and reduce ad viewability and revenue. Google also uses Core Web Vitals as a ranking and quality signal. A fast site is easier to get approved for AdSense and earns more once approved.
Mobile or desktop — which should I test?
Test both. Most traffic is mobile, and mobile scores are usually lower because of slower CPUs and networks. Desktop shows the best-case experience. Fix mobile first.