Page Speed and Core Web Vitals Checker
Run a free website speed test on the PageSpeed Insights API. Real-user Core Web Vitals and the Lighthouse lab run, kept honestly separate, with fixes tied to the actual elements and resources slowing the page down.
Calls the official Google PageSpeed Insights API directly from your browser: the tested URL goes to Google, never to DevDome, and nothing is stored. Without a key the API uses a free quota shared by your whole network, so busy networks can hit it.
Reliability: use your own free Google API key
The shared anonymous quota can run out. A free API key from the Google Cloud console (enable the PageSpeed Insights API, create an API key) gives your tests a dedicated quota. The key is saved only in this browser and sent only to Google.
Google is loading and measuring the page, this takes 20 to 60 seconds.
0s elapsed
Core Web Vitals thresholds: what counts as good
Google grades every metric in three bands: good, needs improvement and poor. For the three Core Web Vitals it applies the thresholds at the 75th percentile of real Chrome visits over the previous 28 days, meaning at least three out of four visitors must hit the good mark. This table is the reference this core web vitals checker uses to rate your results.
| Metric | Good | Needs improvement | Poor | What it measures |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | 2.5 s or less | 2.5 to 4 s | over 4 s | How quickly the largest visible element, usually the hero image or headline, finishes rendering. |
| INP (Interaction to Next Paint) | 200 ms or less | 200 to 500 ms | over 500 ms | How quickly the page responds when a visitor taps, clicks or types. Only measurable from real users. |
| CLS (Cumulative Layout Shift) | 0.1 or less | 0.1 to 0.25 | over 0.25 | How much the layout jumps around while the page loads. |
| FCP (First Contentful Paint) | 1.8 s or less | 1.8 to 3 s | over 3 s | How quickly the first text or image appears on screen. |
| TTFB (Time to First Byte) | 0.8 s or less | 0.8 to 1.8 s | over 1.8 s | How quickly your server sends the first byte of the page. Experimental supporting metric in CrUX. |
| TBT (Total Blocking Time, lab) | 200 ms or less | 200 to 600 ms | over 600 ms | Lab-only diagnostic: how long scripts block the main thread during load. Related to responsiveness problems but it is not INP and does not replace it. |
LCP, INP and CLS are the three Core Web Vitals Google uses as a ranking signal. FCP and TTFB are supporting diagnostics. TBT exists only in lab tests: it measures main-thread blocking during load, which often correlates with responsiveness problems, but it is not INP and a lab run can never produce a Core Web Vitals assessment.
A one-off page speed test vs continuous monitoring
A speed test is a snapshot. It tells you how the page performed during one visit, on one network, at one moment. Real sites drift: a plugin update ships extra JavaScript, marketing adds a tag, a hero image gets swapped for a 4 MB original, and the score you screenshotted last month quietly stops being true. The sites that stay fast are the ones that keep measuring after the fix.
Speed is also only one axis of site health. A page that scores 95 but sits behind an expired SSL certificate or a down server is still losing every visitor. DevDome Site Health watches uptime and site health around the clock, probing your site every 15 minutes and running daily audits, so you find out about problems before your visitors do.
Page speed and Core Web Vitals FAQ
What is a good page speed score?
Google grades the performance score in three bands: 90 to 100 is good, 50 to 89 needs improvement, and 0 to 49 is poor. The score comes from a single lab test, so treat it as a diagnostic, not a grade carved in stone. Aim for 90 plus on desktop and as high as you can get on mobile, where throttled hardware and network make every page slower. A score of 100 is not required for a good user experience.
What are Core Web Vitals?
Core Web Vitals are three user-experience metrics Google measures from real Chrome users: LCP (Largest Contentful Paint) for loading speed, INP (Interaction to Next Paint) for responsiveness, and CLS (Cumulative Layout Shift) for visual stability. Google uses them as a search ranking signal, evaluated at the 75th percentile of your real visitors over the previous 28 days.
What is the difference between field data and lab data?
Field data comes from the Chrome User Experience Report (CrUX): real visits by real Chrome users over the previous 28 days. Lab data comes from a single simulated page load run by Lighthouse on Google servers. Field data is what Google actually assesses, but it only exists for pages with enough traffic. Lab data is available for any public URL and is best for debugging. This tool keeps the two in strictly separate panels, because a lab estimate is not a Core Web Vitals assessment.
Why does it say the data is for the whole origin, not my page?
CrUX needs a minimum number of real visits per URL before it publishes page-level numbers. When your specific page does not have enough traffic, Google falls back to origin-level data: the aggregate of every page on the site. This tool labels that fallback prominently, because origin numbers are real measurements of your site but they are not a measurement of that exact URL.
Why is my page speed score different every time I run the test?
Lab tests have natural variance: your server load, network routing, third-party scripts, ads and A/B tests all change between runs, and Lighthouse simulates a throttled connection on shared Google infrastructure. Swings of 5 to 10 points are normal. Run the test two or three times and watch the trend. The field data section does not have this problem because it aggregates 28 days of real visits.
Why did my test fail with a quota error?
Without an API key, the PageSpeed Insights API applies a shared free quota per network, and on busy networks it can be exhausted by other users. The fix is the Reliability option above: paste your own free Google API key (created in a minute in the Google Cloud console) and your tests run on your own dedicated quota. The key is stored only in your browser and sent only to Google.
Does page speed affect SEO?
Yes. Core Web Vitals are a confirmed Google ranking signal, measured from field data. The bigger effect is usually indirect: slow pages get abandoned before they load, which hurts conversions, ad quality scores and crawl efficiency. Fixing LCP and INP problems tends to pay for itself in revenue before it pays in rankings.
Is this the same as Google PageSpeed Insights?
It uses the official PageSpeed Insights v5 API for the same Lighthouse lab run and the same CrUX field data, called directly from your browser so DevDome never sees the URL. It is not identical to pagespeed.web.dev: this tool requests the performance category only, renders the metrics, evidence and fixes in its own layout, and ranks fixes by a published rule instead of Google’s ordering. For the full raw report, pagespeed.web.dev is one click away.
More free tools: Image Compressor · WebP & AVIF Converter · Image Resizer · Broken Link Checker · Security Headers Checker