PageSpeed & Core Web Vitals Checker

PageSpeed & Core Web Vitals Checker runs a real Google Lighthouse audit on every URL in your list, on mobile and desktop, the same engine that powers PageSpeed Insights. For each URL you get:

• the performance score (0 to 100) for mobile and desktop;
• lab Core Web Vitals and timings: LCP, TBT (the lab stand-in for INP), CLS, FCP, Speed Index, time to interactive and server response time (TTFB);
• page size and number of requests, split by type (scripts, images, fonts, third parties);
• the top 5 fixes with estimated savings in milliseconds and KB;
• optionally the accessibility, best practices and SEO scores;
• optionally the real-user Core Web Vitals from the Chrome UX Report (p75 LCP, INP, CLS, FCP, TTFB and pass or fail), with your own free Google API key.

US$ 0.036 per device audit, so US$ 0.072 per URL on mobile and desktop (US$ 72 per 1,000 URLs). No monthly fee, no start fee. Pages that do not load are free.

At a glance

• Price per URL: US$ 0.072 for mobile + desktop, US$ 0.036 for one device
• Price per 1,000 URLs: US$ 72 on both devices, US$ 36 on one
• Engine: Lighthouse 13 with Chrome, simulated throttling like PageSpeed Insights
• Google API key: Not needed. Optional, only for real-user CrUX data
• Per URL: Scores, LCP, TBT, CLS, FCP, Speed Index, TTFB, page size, requests, top 5 fixes
• Speed: One audit at a time, about 50 seconds each
• Failed pages: Free, with an errorCode

What it fixes

• A real bulk list, not one URL per run. Paste hundreds of pages; each one is a row with mobile and desktop side by side.
• No Google API key and no shared quota. Lighthouse runs inside the Actor, so there is no 429 quota exceeded and no key to create. A key is only needed for the optional real-user data.
• Failed pages cost nothing. A page that does not load, an invalid link or a Lighthouse crash gives a free row with an errorCode, never an empty run or a charge for nothing. If Lighthouse itself breaks on every URL, the run fails loudly instead of finishing "succeeded".
• Scheduled monitoring with alerts. Turn on monitoringMode and each row brings the previous run's scores, the drops (regressions) and hasRegression; add a webhook and you get one alert with every page that got slower.
• The full Lighthouse report when you need it. saveHtmlReport stores the same HTML report you know from Chrome DevTools, one link per audit.

Switching from another PageSpeed or Lighthouse actor? Your existing input works

Paste the input you already use. These names and values are read as they are:

You may already send	Read as
url (one link, or several, one per line), urlsA + urlsB, startUrls, websites, domains	urls
strategy or device: mobile, desktop (also both)	devices
categories: performance, accessibility, best-practices, seo	the categories scored (performance is always included)
apiKey (a Google Cloud key)	googleApiKey, used only for the real-user Chrome UX Report data
concurrency	maxConcurrency
throttling: simulated, devtools, none	the same
saveHtmlReport, monitoringMode, regressionThreshold, alertWebhookUrl	the same

When you send strategy: "desktop" and leave this form's devices at the default, you get (and pay for) desktop only.

One real row

https://www.python.org, audited on 2026-09-30 in the Apify cloud (desktop block and lists shortened):

{
  "type": "page",
  "url": "https://www.python.org/",
  "mobilePerformance": 65,
  "desktopPerformance": 92,
  "lcpMs": 4419,
  "tbtMs": 531,
  "cls": 0.003,
  "pageSizeKb": 523,
  "requests": 26,
  "mobile": {
    "performanceScore": 65,
    "largestContentfulPaintMs": 4419,
    "totalBlockingTimeMs": 531,
    "cumulativeLayoutShift": 0.003,
    "firstContentfulPaintMs": 3156,
    "speedIndexMs": 3156,
    "serverResponseTimeMs": 1,
    "pageSizeKb": 523,
    "requests": 26,
    "requestsByType": { "stylesheet": { "requests": 4, "kb": 156 }, "script": { "requests": 8, "kb": 133 } },
    "domElements": 884,
    "opportunities": [
      { "id": "render-blocking-insight", "title": "Render-blocking requests", "estimatedSavingsMs": 2050, "estimatedSavingsKb": null },
      { "id": "unused-css-rules", "title": "Reduce unused CSS", "estimatedSavingsMs": 900, "estimatedSavingsKb": 129 },
      { "id": "unused-javascript", "title": "Reduce unused JavaScript", "estimatedSavingsMs": 300, "estimatedSavingsKb": 59 }
    ],
    "lighthouseVersion": "13.5.0"
  },
  "desktop": { "performanceScore": 92, "largestContentfulPaintMs": 1359, "totalBlockingTimeMs": 95, "cumulativeLayoutShift": 0.112 },
  "fieldDataStatus": "NO_API_KEY",
  "scrapedAt": "2026-09-30T23:55:55Z"
}

In the same run, https://www.wikipedia.org scored 97 on mobile and 100 on desktop.

What you can do with it

• SEO audits: check the speed of every important page of a site, not only the home page.
• Agency reporting: schedule a monthly run on your clients' pages and track scores and LCP.
• Before and after a release: audit the same URLs before and after a deploy and compare.
• Competitor benchmarks: compare your pages with competitors on the same machine and settings.
• Lead generation: find slow websites in a list of prospects and offer a speed fix.

Input

Field	What it does
urls	Pages to audit, one per line. example.com is read as https://example.com
devices	mobile, desktop or both (default). You pay only for the audits that run
includeOtherCategories	Also score accessibility, best practices and SEO. Same price
saveHtmlReport	Also save the full Lighthouse HTML report of each audit (link in htmlReportUrl). Same price
throttling	simulated (default, like PageSpeed Insights), devtools or none
googleApiKey	Optional: your own Google Cloud API key with the Chrome UX Report API enabled, for real-user data
maxConcurrency	Leave empty: one audit at a time per 4 GB of memory
monitoringMode	Compare every URL with the previous run (for scheduled runs)
regressionThreshold	Points a score must drop to count as a regression (default 5)
alertWebhookUrl	Optional: one JSON POST with all regressions at the end of the run

{ "urls": ["https://www.python.org", "https://www.wikipedia.org"], "devices": ["mobile", "desktop"] }

Schedule it: get told when a page gets slower

Create a schedule (daily or weekly) with this input:

{ "urls": ["https://www.python.org", "https://www.wikipedia.org"], "devices": ["mobile"], "monitoringMode": true, "regressionThreshold": 5, "alertWebhookUrl": "https://hooks.slack.com/services/your/webhook" }

The first run saves the scores. From the second run on, each row has previousRun (the last scores for that URL and device), regressions (for example { "device": "mobile", "category": "performance", "from": 72, "to": 61, "drop": 11 }) and hasRegression, and the webhook gets one POST with every page that dropped. The history lives in a key-value store of your own account named pagespeed-core-web-vitals-history. Lab scores move a few points between runs, so a threshold of 5 or more avoids noise.

Output fields

Top level, for the table and CSV: url, input, finalUrl, mobilePerformance, desktopPerformance, lcpMs, tbtMs, cls, pageSizeKb, requests (these five from the mobile audit, or desktop when only desktop runs; labDevice says which), coreWebVitalsMobile (pass or fail from real users, when there is CrUX data), fieldDataStatus, deviceErrors, scrapedAt.

Per device (mobile and desktop): performanceScore, accessibilityScore, bestPracticesScore, seoScore, largestContentfulPaintMs, totalBlockingTimeMs, cumulativeLayoutShift, firstContentfulPaintMs, speedIndexMs, timeToInteractiveMs, serverResponseTimeMs, maxPotentialFidMs, pageSizeKb, requests, requestsByType, domElements, opportunities (id, title, displayValue, estimatedSavingsMs, estimatedSavingsKb), warnings, lighthouseVersion.

Real users (fieldData, only with your key): per device, source (url, or origin when the page itself has too little traffic), lcpP75Ms, inpP75Ms, clsP75, fcpP75Ms, ttfbP75Ms, passesCoreWebVitals, collectionPeriod.

With monitoringMode: previousRun, regressions (device, category, from, to, drop) and hasRegression. With saveHtmlReport: htmlReportUrl in each device block. With a throttling other than simulated, the device block says which one ran.

fieldDataStatus is OK, NO_API_KEY, NO_FIELD_DATA (Google has no real-user data for the page or its origin), INVALID_KEY or QUOTA.

Error codes (never charged)

errorCode	Meaning
INVALID_URL	Not an http or https website link
PAGE_NOT_LOADED	The page did not load: DNS error, HTTP error (like 403 from a bot wall), crash or hang
AUDIT_TIMEOUT	The audit took more than 150 seconds
AUDIT_FAILED	Lighthouse did not finish
NOT_REACHED, UNEXPECTED	The run timeout arrived, or something unforeseen broke; only that URL is lost

When one device works and the other fails, the row keeps the device that worked, you pay for that one only, and deviceErrors explains the other.

Pricing

Event	Price
Lighthouse audit delivered (one URL on one device)	US$ 0.036

1,000 URLs on mobile and desktop cost US$ 72; on mobile only, US$ 36. Duplicates in the input are audited once, failed audits are free, and there is no Apify compute bill on top.

FAQ

Why are my scores lower than PageSpeed Insights? Lighthouse scores depend on the machine. This Actor uses the same Lighthouse settings as PageSpeed Insights (a Moto G Power on slow 4G for mobile, simulated throttling), but it runs on a cloud CPU that is slower than Google's own servers. Heavy JavaScript pages take longer to run, so TBT and LCP come out higher and the score can come out lower, mostly on mobile. Light pages (like wikipedia.org, 97 on mobile) are barely affected. Every URL runs on the same settings, so the numbers work for comparing pages, competitors and releases; like in PageSpeed Insights, a heavy page can move a few points between runs. Use the optional real-user data (CrUX) when you need the numbers Google uses for ranking.

Why not the PageSpeed Insights API? Google's API terms do not allow a service to resell access to its APIs with its own key, and the API without a key is rate-limited to almost nothing. So this Actor runs Lighthouse itself, open source (Apache 2.0), and only calls Google's Chrome UX Report API with your own key, when you give one.

How do I get the real-user Core Web Vitals? Create a free API key in the Google Cloud console, enable the "Chrome UX Report API" on it and paste it in googleApiKey. It is free, with 150 queries per minute. Real-user data exists only for pages and sites with enough Chrome traffic.

Why one audit at a time? Running several Lighthouse audits on the same CPU makes each one slower and the scores unstable. One at a time, about 50 seconds per audit, gives stable numbers. To go faster, give the run more memory: each extra 4 GB adds one audit at a time.

What is TBT and where is INP? INP needs real user clicks, so a lab test cannot measure it. Total Blocking Time is Google's lab stand-in for INP. The real INP comes in fieldData when you give your key.

Limitations

• Lab scores come from a cloud CPU and can differ from PageSpeed Insights (see the FAQ).
• Some sites block cloud data centers and answer 403; those rows come back as PAGE_NOT_LOADED and are free.
• Pages behind a login cannot be audited.
• Real-user data needs your own Google API key and exists only for pages with enough traffic.
• Lighthouse is an open source project by Google. This Actor is not affiliated with Google.

Changelog

• 2026-10-08, 0.1: input of other PageSpeed and Lighthouse actors works as is (url, strategy, device, categories, apiKey, concurrency, urlsA/urlsB); monitoring mode with previous scores, regressions and an alert webhook; full HTML report; throttling choice; the run fails loudly if Lighthouse breaks on every URL.
• 2026-09-30, 0.1: first release. Lighthouse 13 audits on mobile and desktop, lab Core Web Vitals, page size, requests, top 5 fixes, optional accessibility, best practices and SEO scores, optional real-user CrUX data with your own key, free error rows.