How to Check Your Website's Page Speed and Read the Scores
Checking page speed sounds simple: paste a URL into a tool and read the number. In practice the number changes every time you run it, the mobile score is far lower than desktop, field data disagrees with the lab score, and sometimes PageSpeed Insights refuses to run at all. Small businesses often chase a score of 100 while the measurements that actually affect visitors and search go unread. This guide shows you how to check the page speed of a website properly: which tools to use, what the performance score and each timing mean, which numbers Google uses, why results vary from run to run, and what to do when PageSpeed Insights is not working for your page.
- The tools for checking page speed
- Field data and lab data: the key difference
- What the page speed scores and timings mean
- Why your page speed results vary
- When PageSpeed Insights is not working
- Checking speed from the command line and DevTools
- The fix, step by step
- Edge cases worth knowing
- Keeping your page speed checked
- Questions and answers
The tools for checking page speed
There is no single page speed number. Different tools measure different things, and the first step is knowing which one answers your question.
| Tool | What it measures | Best for |
|---|---|---|
| PageSpeed Insights (pagespeed.web.dev) | Field data from real Chrome users plus one Lighthouse lab test | A quick check of any public URL |
| Search Console Core Web Vitals report | Field data grouped across your whole site | Seeing which templates fail for real visitors |
| Lighthouse in Chrome DevTools | A lab test run on your own computer | Testing changes, staging sites and pages behind a login |
| Performance panel in Chrome DevTools | A detailed recording of one page load | Finding exactly what is slow |
| WebPageTest | Lab tests from chosen locations, devices and connections | Comparing runs and seeing a filmstrip of the load |
curl | Server response timings | Checking the server on its own |
For most small sites the right routine is: PageSpeed Insights to check a page, Search Console to see the whole site, and DevTools when you need to find and test a fix. The page speed guide covers the wider picture.
Field data and lab data: the key difference
PageSpeed Insights shows two quite different things on one screen, and confusing them causes most of the frustration.
Field data: what real visitors experienced
The top section, Discover what your real users are experiencing, comes from the Chrome User Experience Report. It covers real Chrome visits over the previous 28 days and reports the 75th percentile, meaning three in four visits were at least that fast. This is the data Google uses for the Core Web Vitals assessment, and it is what counts for search. It changes slowly, so a fix you make today takes weeks to show fully.
You can switch between This URL and Origin, which is the whole domain. A page with too few visits shows no URL data and falls back to the origin, or shows nothing at all.
Lab data: one simulated test
The lower section, Diagnose performance issues, is a single Lighthouse run on Google's servers. On mobile it emulates a mid-range phone on a slow 4G connection with a slowed processor, which is why mobile scores are usually much lower than desktop. The lab test is repeatable enough to diagnose problems, but it is not what your visitors experienced.
What the page speed scores and timings mean
The big number in a circle is the Lighthouse performance score, from 0 to 100. It is a weighted blend of five lab metrics, and it is not used by Google for ranking.
| Performance score | Rating |
|---|---|
| 90 to 100 | Good |
| 50 to 89 | Needs improvement |
| 0 to 49 | Poor |
The timings matter more than the score. These are the thresholds for a good result at the 75th percentile:
| Metric | Measures | Good | Poor | Where |
|---|---|---|---|---|
| Largest Contentful Paint (LCP) | When the main content appears | 2.5 s or less | Over 4 s | Field and lab |
| Interaction to Next Paint (INP) | How quickly the page responds to taps and clicks | 200 ms or less | Over 500 ms | Field only |
| Cumulative Layout Shift (CLS) | How much the layout jumps | 0.1 or less | Over 0.25 | Field and lab |
| First Contentful Paint (FCP) | When anything first appears | 1.8 s or less | Over 3 s | Field and lab |
| Time to First Byte (TTFB) | How quickly the server starts responding | 0.8 s or less | Over 1.8 s | Field |
| Total Blocking Time (TBT) | How long scripts block the main thread during load | Under 200 ms in lab | Over 600 ms | Lab only |
LCP, INP and CLS are the three Core Web Vitals. A page passes the Core Web Vitals assessment when all three are good in the field data. TBT stands in for INP in the lab, because a lab test has no real person tapping the screen. If your page fails, the Core Web Vitals assessment failed guide shows where to start, and the LCP, INP and CLS guides cover each metric.
When people ask for a page's load time, the most useful single answer is its field LCP: the moment most visitors see the main content.
Why your page speed results vary
Run the same URL three times and you may see scores of 62, 71 and 58. That is normal, and the causes are mostly outside the page:
- Server response time changes with load and caching. A page served from a cold cache is slower than one already cached.
- Third-party scripts such as ads, chat widgets and tag managers load different amounts each time.
- Network conditions between the test server and your host vary from run to run.
- Different content, such as rotating banners, A/B tests or cookie notices, changes what is measured.
- Your own computer affects DevTools Lighthouse runs. Browser extensions and other open tabs slow the test, so use an incognito window.
Run a lab test three to five times and use the middle result. Do not compare a single run before a change with a single run after it. Field data does not have this problem, because it already averages thousands of visits, but it reacts slowly.
When PageSpeed Insights is not working
If PageSpeed Insights shows an error instead of results, the message usually tells you what went wrong.
| Message | Likely cause | What to check |
|---|---|---|
| FAILED_DOCUMENT_REQUEST | The page could not be loaded at all | DNS, SSL certificate, server down, firewall |
| ERRORED_DOCUMENT_REQUEST with a status code | The server returned an error such as 403 or 500 | Bot protection, security plugins, server errors |
| NO_FCP | Nothing was painted on screen | A blank page, a page hidden until scripts run, a challenge page |
| NO_LCP | No largest content element was recorded | See the NO_LCP guide |
| Page loaded too slowly to finish within the time limit | The load took longer than Lighthouse allows | Very slow server, endless redirects, scripts that never finish |
| No field data shown | Too few Chrome visits in the last 28 days | Normal for new or quiet pages; use the origin data or lab data |
The most common cause on small sites is bot protection. Firewalls, Cloudflare challenge settings and security plugins can block or challenge the test because it is an automated visitor. Check what the server returns with:
curl -sI -A "Mozilla/5.0 (Linux; Android 11) AppleWebKit/537.36 Chrome-Lighthouse" https://example.com/A 200 is what you want. A 403, 503 or a challenge page means a security rule is stepping in. Relax that rule for testing, or test the page in DevTools Lighthouse from your own browser instead. Also confirm the URL is public, uses https without certificate warnings, and does not redirect in a loop.
Checking speed from the command line and DevTools
To see how long the server takes before the browser does anything, use curl:
curl -o /dev/null -s -w 'dns %{time_namelookup}s\nconnect %{time_connect}s\ntls %{time_appconnect}s\nfirst byte %{time_starttransfer}s\ntotal %{time_total}s\n' https://example.com/The first byte figure is your TTFB from where you are. Run it several times; if it is regularly over about 0.8 seconds, the server is the bottleneck. The high TTFB guide covers server-side fixes.
To run Lighthouse yourself, open the page in an incognito window, open DevTools with F12, choose the Lighthouse panel, select Mobile and the Performance category, and start the page load test. To run it from a terminal with Node.js installed:
npx lighthouse https://example.com/ --only-categories=performance --view
npx lighthouse https://example.com/ --only-categories=performance --preset=desktop --viewPageSpeed Insights also has a free API, useful for checking a list of pages:
curl -s "https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=https://example.com/&strategy=mobile" | jq '.lighthouseResult.categories.performance.score'Regular use of the API needs a free API key from Google Cloud. On WordPress and Shopify, platform-specific causes of slow results are covered in the WordPress page speed and Shopify page speed guides.
The fix, step by step
Step 1
Run PageSpeed Insights on key pages
Open pagespeed.web.dev and test one public URL from each template: home, a product or service page, a category and a blog post. Leave the Mobile tab selected, because Google uses the mobile experience and most visitors are on phones. Wait for both sections to load. Note the Core Web Vitals assessment result at the top and the performance score lower down for each URL. You now have a baseline for every important template to compare against later.
Step 2
Read the field data first
In the top section, check whether the Core Web Vitals assessment says Passed or Failed, then read LCP, INP and CLS at the 75th percentile. Switch between This URL and Origin to see whether the issue is the page or the whole site. If no field data is shown, the page has too few Chrome visits, so rely on Search Console and lab data. Write down which of the three metrics fail on which templates.
Step 3
Check the Search Console report
Open the Core Web Vitals report in Search Console and view the mobile report. It groups similar URLs and shows which groups are poor, need improvement or are good, with the failing metric for each group. Click a group to see example URLs. Compare this with your PageSpeed Insights notes. You know this step is done when you know which templates fail for real visitors across the site, not only on the pages you tested.
Step 4
Run repeated lab tests
For each failing template, run the lab test three to five times, in PageSpeed Insights or in DevTools Lighthouse from an incognito window, and use the middle result. Look at the LCP, TBT and CLS timings rather than the overall score. Record the median values. This gives you a steady lab baseline that you can compare after each change, without being misled by the normal variation between single runs of the same page.
Step 5
Check the server response time
Run curl -o /dev/null -s -w with the time_starttransfer variable against the slow page several times from your own connection, and compare it with the TTFB in the field data. If the first byte regularly takes more than about 0.8 seconds, the server, caching or hosting is the first thing to fix, because every other timing waits for it. Confirm caching is working by checking that repeat requests come back faster.
Step 6
Read the diagnostics
Scroll to the Diagnostics section of the lab report. Expand items such as Largest Contentful Paint element, render-blocking requests, unused JavaScript and image delivery. Each lists the files responsible and an estimated saving. Focus on the items linked to your failing field metric: LCP diagnostics for a slow LCP, long main-thread tasks for poor INP, layout shift sources for CLS. List the top three changes with the biggest estimated savings for that template.
Step 7
Fix a test that will not run
If PageSpeed Insights shows an error such as FAILED_DOCUMENT_REQUEST, ERRORED_DOCUMENT_REQUEST or NO_FCP, check the URL loads publicly over https without a certificate warning. Use curl -sI with a Lighthouse user agent to see the status code. A 403 or challenge page means bot protection is blocking the test; relax the rule or test from DevTools instead. Re-run PageSpeed Insights and confirm the full report loads.
Step 8
Retest after each change
Make one change at a time, clear any server and CDN cache, then repeat the three to five lab runs and compare the median with your baseline. Keep changes that improve the failing metric and undo those that do not. Field data will follow over the next 28 days as new visits are collected. In Search Console, use Validate fix on the Core Web Vitals issue once the lab results are consistently good.
Edge cases worth knowing
- Desktop is green, mobile is red. Expected. The mobile test simulates a slower device and connection. Most visitors to small business sites are on phones, so prioritise mobile.
- Lab score is good, field data fails. Real visitors may be on slower phones, or problems such as INP only show when people interact. Trust the field result.
- Home page is fast, other pages are slow. Test one page per template, especially product and blog pages, which often carry heavier images and scripts.
- Logged-in testing. If you test while logged in to WordPress or Shopify, admin bars and uncached pages make results slower. Test logged out.
- A score of 100 is not the goal. Passing Core Web Vitals in field data is what matters for visitors and search.
Keeping your page speed checked
- Check the Core Web Vitals report in Search Console monthly for URL groups moving to poor or needs improvement.
- After every theme, plugin or app change, run a lab test on one page per template, three times, and compare the middle results.
- Keep a simple log of field LCP, INP and CLS for your main templates so you notice a slow drift.
- Read the page speed fix guide when a template starts failing.
1. How do I check my page speed?
Check page speed by entering the page URL at pagespeed.web.dev, Google's PageSpeed Insights, and reading the mobile results. The top section shows field data from real Chrome visitors, including the Core Web Vitals assessment, and the lower section shows a Lighthouse lab test with a performance score and diagnostics. For your whole site, open the Core Web Vitals report in Search Console. For testing changes or private pages, run Lighthouse from the DevTools panel in Chrome.
2. What is a good page speed score?
A Lighthouse performance score of 90 to 100 is rated good, 50 to 89 needs improvement and 0 to 49 is poor. The score is a lab measure and Google does not use it for ranking. What matters more is passing the Core Web Vitals assessment in field data: LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less for at least three in four visits. A page can score 70 and still pass.
3. Why is PageSpeed Insights not working for my site?
PageSpeed Insights usually fails because it cannot load the page, most often because bot protection, a firewall or a security plugin blocks or challenges the automated test. Other causes are an expired SSL certificate, a server error, a redirect loop or a page that paints nothing until scripts run. The error code points to the cause. Check the URL with curl to see the status code, relax any challenge rule for testing, or run Lighthouse in DevTools from your own browser instead.
4. Why does my page speed score change every time?
Your page speed score changes because each lab run is a single test, affected by server load, caching, network conditions and third-party scripts that load differently each time. Variation of several points between runs is normal. Run the test three to five times and use the middle result, and compare medians before and after any change. Field data in PageSpeed Insights does not jump around in the same way, because it already summarises 28 days of real visits.
5. Why is my mobile page speed score lower than desktop?
Your mobile score is lower because the mobile lab test emulates a mid-range phone on a slow 4G connection with a slowed processor, while the desktop test uses a fast connection and a full-speed computer. The same page therefore takes much longer on the mobile test. This is deliberate, since many visitors use phones on imperfect connections. Focus on the mobile results, because Google uses the mobile experience and most small business traffic now comes from phones.
6. What is a good page load time?
A good page load time is when the main content appears within 2.5 seconds for at least three in four visitors, which is the good threshold for Largest Contentful Paint. There is no single official load time figure, because a page loads in stages: the server responds, content starts painting, the main content appears, and the page becomes responsive. Aim for a first byte under about 0.8 seconds, first content under 1.8 seconds and the main content under 2.5 seconds.
7. Why does PageSpeed Insights show no field data?
PageSpeed Insights shows no field data when the page, or the whole site, has not had enough Chrome visits in the past 28 days for the Chrome User Experience Report to publish figures. This is common for new pages, small sites and pages with little traffic. Try the Origin view for site-wide data, use the lab results to diagnose problems, and check the Core Web Vitals report in Search Console, which groups similar pages together and may have enough data for the template.
The page speed checker on aiwebpageseo.com tests your key pages on mobile and desktop, shows field and lab timings side by side, and points to the files slowing each template, so you know which fix to make first.
Open Page Speed Fixes →