PageSpeed Lighthouse Audit - Bulk Core Web Vitals & SEO Score

Give it a list of URLs and get one clean row per page with the Google Lighthouse scores you know from PageSpeed Insights: performance, accessibility, best practices and SEO (0-100), the Core Web Vitals lab metrics (LCP, CLS, TBT, with good / needs-improvement / poor ratings), and the top fixes with their estimated savings. Lighthouse 13 runs in its own Chrome inside the Actor, so there is no API key and no PageSpeed Insights quota to run out of.

Turn on monitor mode and schedule it: you only get the pages whose score really moved. Lighthouse performance scores move on their own between runs (in our runs the same page ranged 10 to 16 points), so a move is only reported when a second audit confirms it, and it has to be bigger than the range that page has shown before.

Pages this Actor cannot audit (robots.txt says no, sign-in pages, check pages, 404s, PDFs) come back as a free row that says why, and a run that cannot audit any page is not charged at all, not even the start fee.

What you get per page

Column	What it is
performanceScore, accessibilityScore, bestPracticesScore, seoScore	Lighthouse category scores, 0-100 (agenticBrowsingScore when you ask for Lighthouse 13's agentic-browsing category)
largestContentfulPaintMs, cumulativeLayoutShift, totalBlockingTimeMs	Core Web Vitals lab metrics. TBT is the lab stand-in for INP: Interaction to Next Paint needs a real user interaction, so a page-load audit cannot measure it (the same is true on PageSpeed Insights' lab section)
lcpRating, clsRating, tbtRating, fcpRating	good / needs-improvement / poor (LCP 2.5 s / 4 s, CLS 0.1 / 0.25, TBT 200 ms / 600 ms, FCP 1.8 s / 3 s)
firstContentfulPaintMs, speedIndexMs, timeToInteractiveMs, serverResponseTimeMs	Other Lighthouse timings
totalByteWeight, requestCount, domElements, mainThreadWorkMs, javascriptExecutionMs	Page weight and main-thread cost
opportunities	Performance improvements that did not pass (Lighthouse insights and diagnostics), biggest estimated saving first: id, title, displayValue, score, savingsLcpMs, savingsFcpMs, savingsTbtMs, savingsCls, savingsMs, savingsBytes
failedAudits	Accessibility, best-practices and SEO checks that failed: category, id, title, displayValue, itemCount
strategy, formFactor, throttlingMethod, cpuSlowdownMultiplier	How the page was audited (mobile or desktop, simulated throttling)
benchmarkIndex, slowHostCpu	Lighthouse's own CPU benchmark of the machine that ran the audit, and whether Lighthouse would call it slow (1,000 or less). Performance scores depend on CPU, so this is here for you to see, not hidden
lighthouseVersion, browserVersion, runWarnings, auditedAt	Lighthouse 13.5.0, Chrome version, Lighthouse's warnings (for example "The page loaded too slowly to finish within the time limit")
url, finalUrl, redirects, httpStatus, lighthouseFinalUrl	The URL you gave, where it ended after redirects
changeType, changedScores, previousCheckedAt, confirmedByRuns, watchName	Monitor mode (see below)
status, note	ok for an audit. Any other status is a free row, and note says why

If Apify moves a long run to another server in the middle, pages already returned are not audited or charged again.

Scores and metrics that Lighthouse did not produce are null, never 0 or a guess. If Lighthouse could not score a category you asked for, the page is a free audit-incomplete row instead of a charged audit.

Input

Field	Default	What it does
urls	(example: github.com/apify/crawlee)	1 to 500 URLs. Without http(s)://, https:// is added. Duplicates are audited once
strategy	mobile	mobile, desktop or both (two rows per URL, each charged as one audit)
categories	performance, accessibility, best-practices, seo	Also agentic-browsing. Fewer categories do not change the price
maxOpportunities	10	How many performance fixes to list (0 to 30)
pageLoadTimeoutSecs	45	Lighthouse's maxWaitForLoad (15 to 90)
onlyChanges	false	Monitor mode: return only pages whose score moved
watchName	(empty)	Name of the watch list, so separate schedules do not mix
performanceChangeThreshold	10	Smallest move of the performance score, in points, that counts as a change
changeThreshold	5	Smallest move of the accessibility, best-practices, SEO (and agentic-browsing) scores that counts as a change
resetMonitoringState	false	Forget the remembered scores of this watch

Example:

{
  "urls": ["https://github.com/apify/crawlee", "https://developer.mozilla.org/en-US/"],
  "strategy": "both",
  "categories": ["performance", "seo"]
}

Monitor mode: only real score changes

Schedule the Actor (for example daily) with onlyChanges: true and a watchName:

1. First run: every page is audited twice and returned once as changeType: "first-check" (the two audits give the page's usual score and how much it wobbles).
2. Later runs: each page is audited once and compared with its usual score (the median of up to 8 earlier audits). A category counts as moved only if it moved by at least its threshold (performanceChangeThreshold, default 10, for performance; changeThreshold, default 5, for the others) and by more than the range that page has already shown. Otherwise the page comes back as a free no-change row with its current scores (and the move that would have been needed), charged as one url-checked event.
3. If a category did move, the page is audited again straight away. Only when both audits moved the same way is it returned as changeType: "changed" with changedScores, for example {"performance": {"previous": 57, "current": 36, "delta": -21, "firstAudit": 35, "requiredMove": 18}}. If the second audit does not confirm it, it is treated as noise and not returned. If the second audit could not finish at all, the page comes back as a free unconfirmed row with the first audit's scores (never as "no change"), nothing is remembered, and the next run checks it again.

Why: in our own runs the same page scored 40 and then 26 a few minutes later, and another 29 and then 15; over 5 to 6 audits, python.org ranged 72 to 82, MDN 74 to 86 and a Wikipedia article 64 to 76. Selling those wobbles as "changes" would be noise you pay for.

Pricing (pay per event)

• Audit returned: one row with Lighthouse scores for one URL on one device.
• Run start: once per run that returned at least one audit (in monitor mode: that finished at least one comparison).
• URL checked (monitor mode only): a page that was audited and compared but did not move. You get a free no-change row with its current scores.

Not charged: robots.txt refusals, sign-in pages, check pages, pages that do not exist or are not HTML, pages Lighthouse could not audit, input errors, and anything left when the run reaches your maximum charge or its timeout. A run whose maximum total charge has no room for the start fee plus one audit audits nothing and is charged nothing.

Measured

Our own runs on Apify (September 2026, 4,096 MB, Lighthouse 13.5.0, mobile):

Input	Time	Result
The example URL only ({})	63 s for the whole run	1 audit (github.com/apify/crawlee: performance 32, accessibility 97, best practices 100, SEO 100)
11 URLs of all kinds	171 s	5 audits; robots.txt refusal, sign-in redirect, 404, check page (HTTP 403), PDF and an unknown domain answered as 6 free rows without starting Chrome
16 well-known sites, 5 categories	740 s	11 audits; 2 refused by the site (HTTP 403), 1 robots.txt refusal, 2 pages Lighthouse could not finish (never stopped loading) as free rows

• One audit takes about 10 s (example.com) to 65 s (heavy pages), about 30 s on average, so roughly 60 to 120 pages fit in an hour.
• Peak memory 2.1 GB (16 pages in one run).
• Lighthouse's CPU benchmark of the machine (benchmarkIndex) was about 950 to 2,600 at 4,096 MB. At 2,048 MB it was 756 to 904 (below Lighthouse's own "slow machine" line of 1,000) and the same pages scored 20 to 30 points lower (python.org 49 and 59 against 79 and 72; MDN 57 and 66 against 83 and 86), so this Actor runs at 4,096 MB by default. Keep it there.
• Checked against a browser: for 10 audited pages (python.org, MDN, a Wikipedia article, example.com, gov.uk, bbc.com/news), the SEO and accessibility checks in failedAudits (meta description, html lang, document title, image alt text) and the final URL were compared with the same pages opened in Chromium: 49 of 50 agree. The one difference: on bbc.com/news the browser showed 8 grey lazy-loading image placeholders without alt text that Lighthouse's check did not count at the moment it ran.

How it works

1. Preflight with a plain HTTP request (no browser): robots.txt of the site (RFC 9309, prefix match), redirects one hop at a time, sign-in redirects, check pages, 404s and non-HTML. These are answered in a few seconds without starting Chrome.
2. Lighthouse 13 audits the page in headless Chrome with Lighthouse's default settings for the device (simulated throttling: Moto G Power, slow 4G, 4x CPU slowdown for mobile). Pages are audited one at a time, because Lighthouse's own guidance is not to run audits in parallel on one machine: they compete for CPU and the performance score drops.
3. A failed audit that can be temporary (Chrome crashed, no first paint, HTTP 5xx or 429) is retried once. A clear answer (404, DNS failure, not HTML) is not, and neither is a page that never stops loading (Lighthouse's PAGE_HUNG, or an audit still running after the page load limit plus 90 seconds): those come back as a free audit-failed row instead of costing you twice the time.
4. The run stops starting new audits shortly before its timeout, so audits already done are delivered and charged, and the rest are listed in a free time-limit row.

Limits

• Lab data, not field data. These are Lighthouse lab numbers, like the "Diagnose performance issues" part of PageSpeed Insights. The Chrome UX Report field data (real users' 28-day LCP / INP / CLS) is not included.
• Scores can differ from PageSpeed Insights by a few points, as they do between any two machines: Lighthouse's performance score depends on the CPU. Each row carries benchmarkIndex so you can see the machine's speed. Compare a page with itself over time (monitor mode) rather than with another tool.
• robots.txt is respected. A site whose robots.txt disallows the page (for example a staging site with Disallow: /) is not audited.
• No sign-in, no CAPTCHA solving, no proxies to get around a refusal.
• One audit takes about 10 to 65 seconds (roughly 60 to 120 pages per hour). Raise the run timeout for long lists.

Support

Something wrong or missing? Open an issue on the Issues tab with the run ID and we will look at it.