PageSpeed Insights & Core Web Vitals Checker: Causes & Fixes

Test a list of pages on Google PageSpeed Insights and get, for each one, more than a score: does it pass Core Web Vitals for real visitors, why it fails, which fix helps the metric that fails, and whether it is getting better or worse. Mobile and desktop in the same row.

Most PageSpeed tools stop at "LCP 4.1 s, score 62". This one also tells you which element is the LCP, where its time goes (server, load delay, download, render delay), which elements cause layout shift, and which third-party scripts (tag managers, chat widgets, pixels) cost the most.

What you get for every URL

Field	What it tells you
summary	One plain-English verdict per device, ready for a client report: pass or fail, by how much, the main cause, the first fix, and a worsening trend
coreWebVitals	pass, fail or no-data for real Chrome visitors (LCP, INP, CLS at the 75th percentile, last 28 days). This is what Google uses in ranking
fieldUrl	The address the real-user data belongs to. Google looks it up by the address it actually tested, which can differ from the one you gave (a redirect to a mobile or country site)
fieldScope	page, or origin when the page has too little traffic and Google reports the whole site instead. Said openly, never mixed up
failing	Each failing metric with its value, the "good" limit and the gap to close, e.g. LCP 3.4 s, limit 2.5 s, gap 900 ms
lcp	The LCP element (CSS selector and text) and its time breakdown: time to first byte, resource load delay, resource load duration, element render delay. The biggest part is named
layoutShifts	The elements that move while the page loads, with their shift score
thirdParties	Third-party code ranked by main-thread time and size. The site's own CDN on another domain (e.g. ebaystatic.com on ebay.com) is left out: it is not a third party you can remove
labBlocked	true when bot protection showed Google's lab test a check page instead of the site. The real-user verdict still holds; the lab causes do not, and the summary says so
fixes	Lighthouse fixes with estimated savings, the ones that improve your failing metric first, each with fixesFailing
trend	From the Chrome UX Report History: LCP, INP and CLS now versus about 3 months ago, better, worse or stable
lab	Lighthouse performance, accessibility, best practices and SEO scores; LCP, FCP, TBT, CLS, Speed Index, server response time, page weight, requests
failedSeoChecks	Lighthouse SEO checks the page fails
reportUrl	The same test on pagespeed.web.dev

The table view shows the verdict, the failing metrics and the score per device. A second view lists causes and fixes for mobile. The run summary (SUMMARY in the key-value store) counts pages that pass or fail and lists the fixes that come up most often across your list.

Example

Real result for https://www.python.org, run on Apify on 18 October 2026, desktop part shortened:

{
  "url": "https://www.python.org/",
  "summary": "Mobile passes Core Web Vitals for real visitors. Desktop fails Core Web Vitals for real visitors: CLS 0.13 (limit 0.1). The biggest layout shift is body#homepage > div#touchnav-wrapper > div#content (0.122).",
  "mobileCoreWebVitals": "pass",
  "desktopCoreWebVitals": "fail",
  "desktopFailing": "CLS",
  "desktop": {
    "coreWebVitals": "fail",
    "fieldScope": "page",
    "field": {
      "LCP": {
        "p75": 1876,
        "rating": "good"
      },
      "INP": {
        "p75": 17,
        "rating": "good"
      },
      "CLS": {
        "p75": 0.13,
        "rating": "needs-improvement"
      }
    },
    "failing": [
      {
        "metric": "CLS",
        "source": "field",
        "value": 0.13,
        "rating": "needs-improvement",
        "good": 0.1,
        "gap": 0.03
      }
    ],
    "trend": {
      "scope": "page",
      "from": "2026-07-18",
      "to": "2026-10-10",
      "LCP": {
        "then": 2395,
        "now": 2178,
        "changePct": -9,
        "direction": "stable"
      },
      "INP": {
        "then": 14,
        "now": 17,
        "changePct": 21,
        "direction": "stable"
      },
      "CLS": {
        "then": 0.13,
        "now": 0.13,
        "changePct": 0,
        "direction": "stable"
      }
    },
    "lab": {
      "performance": 94,
      "seo": 92,
      "lcpMs": 1030,
      "cls": 0.124
    },
    "lcp": {
      "selector": "li.flex-active-slide > div.slide-code > pre > code",
      "breakdownMs": {
        "timeToFirstByte": 3,
        "elementRenderDelay": 452
      },
      "biggestPart": {
        "part": "elementRenderDelay",
        "ms": 452
      }
    },
    "layoutShifts": [
      {
        "selector": "body#homepage > div#touchnav-wrapper > div#content",
        "element": "Get Started\n\nWhether you're new to programming or an experienced developer, it'…",
        "score": 0.122
      }
    ],
    "thirdParties": [
      {
        "name": "Google CDN",
        "mainThreadMs": 99,
        "transferKb": 110
      }
    ],
    "fixes": [
      {
        "id": "render-blocking-insight",
        "title": "Render-blocking requests",
        "estimate": "Est savings of 570 ms",
        "savingsMs": {
          "LCP": 550,
          "FCP": 550
        },
        "savingsKb": null,
        "fixesFailing": []
      }
    ]
  },
  "reportUrl": "https://pagespeed.web.dev/analysis?url=https%3A%2F%2Fwww.python.org%2F&form_factor=mobile"
}

The page passes on mobile, but on desktop real visitors see a layout shift of 0.13, above the 0.1 limit. The row names the element that moves (div#content, 0.122 of the 0.124 measured in the lab). Note that the biggest Lighthouse saving (render-blocking requests) is not marked as fixing the failing metric: it speeds up LCP, which already passes. The trend shows CLS has stayed at 0.13 for three months, so it is not a one-off.

Where the data comes from

Only Google's official APIs: PageSpeed Insights API v5 (Lighthouse run on Google's servers, plus real-user data from the Chrome UX Report) and the Chrome UX Report History API for the trend. No scraping, no browser on our side. The same test as pagespeed.web.dev. The Actor has its own Google API key, so you do not need one.

Lab vs field. Lab data is one page load on a simulated device: it shows the causes and moves a few points between runs. Field data is what real visitors experienced over 28 days: it decides pass or fail. A page can score 77 in the lab and still pass for real users, or the other way round, so both are returned. Google only has field data for pages and sites with enough Chrome traffic; for a small site the verdict is no-data and the row falls back to the lab numbers, saying so. Since INP cannot be measured in a lab, Total Blocking Time stands in for it there.

Input

Field	Default
urls	["https://www.python.org"]	Up to 500 pages per run. Bare domains work
devices	both	both, mobile (what Google ranks on) or desktop
trend	true	Add the 3-month trend. No extra charge
apiKey	empty	Optional: your own Google API key, for very large lists

{ "urls": ["https://www.python.org", "https://www.bbc.com/news"], "devices": "both", "trend": true }

Pricing

$0.004 per page test (one page on one device with a complete report). Mobile and desktop for one page is two tests, $0.008. Lower on Bronze, Silver and Gold plans. The trend and the run summary are free. Pages Google cannot load, rate limits and timeouts are not charged; the row says why.

1,000 pages on mobile cost about $4. Google takes 10 to 60 seconds per test; the Actor runs up to 8 tests at a time.

Use it for

• SEO audits and client reports: paste the summary into the report; the fixes with fixesFailing are the to-do list.
• Prospecting: run a list of sites, keep the ones that fail Core Web Vitals, and open with the exact cause.
• Before and after a change: the trend shows whether a redesign, a new host or a plugin clean-up moved real-user numbers.
• AI agents: one call, structured JSON with a verdict sentence and ranked fixes. Available through the Apify MCP server.

API

curl -X POST "https://api.apify.com/v2/acts/crawlwise~pagespeed-core-web-vitals/run-sync-get-dataset-items?token=<YOUR_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{"urls":["https://www.python.org"],"devices":"mobile"}'

FAQ

Why does my score differ from pagespeed.web.dev by a few points? Every Lighthouse run is a fresh load; scores move between runs on Google's own site too. Use the field verdict and the failing metrics for decisions.

Why is the verdict no-data? Google publishes real-visitor data only for pages and sites with enough Chrome traffic. The lab numbers and causes are still there.

Why is there no trend? Same reason: the history needs enough traffic. When the page has none, the trend uses the whole site and says scope: origin.

Why does the summary say the lab test got a bot-check page? Some sites (with DataDome, for example) answer Google's lab browser with a captcha. The real-visitor data is unaffected, so the pass or fail verdict and the trend are right, but the element, shift and fix details would describe the captcha page, so they are not presented as causes.

A page came back with an error. Google could not load it (site down, blocking Google, not a web page). The reason is in errorMessage, and it was not charged.

Also from Crawlwise

Website SEO Audit Tool & SEO Checker with AI Search Check: title, meta description, H1, canonical, noindex, JSON-LD, and whether ChatGPT, Claude and Perplexity bots can read the page. Run both on the same list for a full technical check.

Found a problem or need a field? Open an issue on the Issues tab.