PageSpeed & Core Web Vitals Test
Enter a page address. The test runs Google's PageSpeed Insights engine for mobile and desktop at the same time and shows the scores, the Core Web Vitals, the element that decides your LCP, and what to fix first.
FreeNo sign-upRuns in your browser: your data is not uploaded
What the test measures
The report is produced by Google's PageSpeed Insights API, the same Lighthouse engine behind pagespeed.web.dev, run twice: once as a mid-range Android phone on a slow 4G connection (mobile) and once as a desktop browser. Two things come back:
- Lab data: a fresh load of the page under controlled conditions. The Performance score (0-100) is computed from five metrics: First Contentful Paint, Largest Contentful Paint, Total Blocking Time, Cumulative Layout Shift and Speed Index. Accessibility, Best practices and SEO scores come from the same run.
- Field data (Core Web Vitals): what real Chrome users experienced on that page over the last 28 days, at the 75th percentile. It appears only for pages with enough traffic; a new site shows "no field data" until Google has collected it. This is the data Google's ranking systems use.
Core Web Vitals thresholds
| Metric | Good | Needs improvement | Poor | What it means |
|---|---|---|---|---|
| LCP | ≤ 2.5 s | 2.5-4.0 s | > 4.0 s | When the largest image or text block above the fold is painted |
| INP | ≤ 200 ms | 200-500 ms | > 500 ms | How long the page takes to react to taps and clicks (field only) |
| CLS | ≤ 0.1 | 0.1-0.25 | > 0.25 | How much the layout jumps while loading |
| TBT | ≤ 200 ms | 200-600 ms | > 600 ms | Lab stand-in for INP: time the main thread was blocked by scripts |
How to read the fixes
The "What to fix" list is sorted by the time and bytes each item would save, so start at the top. Each entry names the audit Lighthouse ran, the files or elements involved, and in plain words what usually causes it on a PHP, WordPress or Laravel site. The LCP element line shows the exact HTML element that decided your Largest Contentful Paint; nine times out of ten the fix is to get that image into the HTML early (not injected by JavaScript, not loading="lazy"), preload it, and serve it at the size it is displayed.
Scores vary by a few points between runs; Google says so on every report. Judge a change by the metrics, and run the test two or three times before deciding. If the page is generated on every request (PHP, WordPress without a cache), the first run after a change can hit a cold server and read low; run it again.
Before you optimise
- Test the pages that earn traffic, not only the home page: a blog post or product page often has different problems.
- Fix in this order: LCP (image discoverability, render-blocking CSS, server response), then CLS (image dimensions, fonts, injected banners), then TBT/INP (third-party scripts, long tasks).
- Third-party scripts (analytics, ads, chat widgets) are usually the bulk of unused JavaScript; load them after the page is interactive.
- After fixing the lab metrics, wait a few weeks for the field data to follow; the field numbers are what count for ranking.
FAQ
Is this the same as Google PageSpeed Insights?
Why is my mobile score so much lower than desktop?
Why do I get a different score each time?
What does "no field data" mean?
Does the PageSpeed score affect Google rankings?
Can I test a page that needs a login?
Link to this tool
Found it useful? Put a link in your docs, README or forum answer so others can use it too:
<a href="https://headsntail.com/tools/page-speed-test">PageSpeed & Core Web Vitals Test</a> (free, by HeadsNTail)
[PageSpeed & Core Web Vitals Test](https://headsntail.com/tools/page-speed-test)
Share: X LinkedIn Reddit WhatsApp
Need a website, HR or business system? HeadsNTail builds websites, HR and payroll apps and business tools. See services or ask a question.