Core Web Vitals Bulk Auditor (Lighthouse)

Runs the open-source Lighthouse engine on a list of public URLs and returns compact, LLM-ready JSON: lab Core Web Vitals (LCP, CLS, and TBT as a stand-in for INP), performance, accessibility, best-practices and SEO scores, the top fixes ranked by estimated savings, and an optional Markdown summary. No API key needed.

This is an independent tool built on Lighthouse; it is not affiliated with or endorsed by Google. Results are lab measurements from an emulated device, not real-user field data.

Input

• urls (required): pages to audit.
• strategy: mobile (default), desktop or both (two audits per URL).
• runsPerUrl (1–5, default 1): run Lighthouse several times per URL and device and report the median run, plus metricsMedian, metricsRange and scoresRange (min/max). Each completed run is charged as one lighthouse-audit.
• categories: subset of performance, accessibility, best-practices, seo.
• includeMarkdown: add a short readable report per result.
• blockMedia (default off): don't download video and audio files during the audit. See Memory below.
• respectRobotsTxt / ownSiteConfirmed: robots.txt is always respected unless you confirm you own the sites.

Output

One dataset item per URL per device with scores, metrics, coreWebVitalsLab, opportunities, failedAudits, mediaBlocked and error (null on success). Every item, error items included, and the run summary record mediaBlocked. A run summary is saved as OUTPUT_SUMMARY in the key-value store.

Memory

The default 2048 MB covers most pages; very heavy news pages (CNN-class) can use about 85% of it. How memory is kept down:

• Each run gathers in a short-lived process (Node heap capped at 640 MB) with its own Chrome, which this Actor launches and always kills, then computes the audits in a second process after Chrome has closed (heap capped at 768 MB). Memory is returned between runs, and each page's JavaScript heap is capped at 512 MB.
• No full-page screenshot or filmstrip, and the trace leaves out the categories Lighthouse records only for the DevTools Performance panel (script-source rundown, frame and latency events). On CNN that halves the trace (35 to 16 MB) and gives identical scores and metrics on the same recording. Screenshots in the trace stay, because Speed Index needs them.
• blockMedia (off by default) skips video and audio: every request Chrome marks as media, plus URLs whose path ends in a media extension (.mp4, .webm, .m3u8, .mp3 and similar), with or without a query string. Patterns match the whole URL, so a web app manifest (site.webmanifest) or an image such as a.mov.jpg still loads. Images, video posters, scripts, CSS and fonts load, so LCP and CLS are measured on the real layout; page weight leaves media out. It saves only a little memory, so it isn't a fix for very heavy pages.

Peak memory (PSS of the whole run, local tests by QA and the developer, 2 Nov 2026; CNN re-measured 5 Nov 2026 with and without the guard proxy, Lighthouse runs one at a time, default 2048 MB):

Page (mobile)	Peak memory	Share of 2048 MB
CNN homepage, all categories, default (media loaded)	1718 to 1747 MB (3 runs, with --disk-cache-size=1 / --media-cache-size=1)	up to 85%
CNN homepage, all categories, blockMedia on	1373 to 1567 MB (4 runs)	up to 77%
CNN homepage, performance only, media loaded	1389 to 1468 MB (5 runs)	up to 72%
CNN homepage, performance only, blockMedia on	1230 to 1448 MB (5 runs)	up to 71%
BBC homepage, performance only, media loaded	773 to 835 MB (6 runs)	up to 41%

These are local measurements; the first cloud run confirms them.

Very heavy news pages (CNN-class) can use about 85% of 2048 MB. For big batches of them, set the run's memory to 4096 MB. That doubles the compute charged to your Apify account per run, because Apify bills compute by allocated memory.

Tried and left out: Chrome's --renderer-process-limit=1 and --disable-site-isolation-trials put ad iframes in the page's own renderer. They didn't lower memory (1625 to 1658 MB without the lean trace, 1484 to 1558 MB with it) and changed the results (LCP 10 to 14 s instead of about 47 s, TBT up by about 1.5 s), so audits would no longer match a normal Lighthouse run. --disable-dev-shm-usage is on (Docker's /dev/shm is only 64 MB).

Pricing

Pay per event: one lighthouse-audit per completed Lighthouse run, i.e. per URL, device and run (runsPerUrl, default 1). Failed or blocked audits are not charged. The price is $20 per 1,000 runs ($0.020 each); one mobile audit of 50 URLs costs $1.00. Very heavy pages can occasionally time out: Lighthouse reports PAGE_HUNG when a page stops responding, and you get a free item with errorCode: lighthouse-error. Failed audits aren't charged.

Compliance

Audits run one at a time with at least a second between audits of the same host (longer if robots.txt sets a Crawl-delay), robots.txt is honoured, and no logins, captchas or proxies are used.

• robots.txt is fetched with the Actor's own User-Agent (WebVitalsAuditor/0.1 (+https://apify.com; robots-aware)), and Lighthouse page loads send Lighthouse's device User-Agent with the same WebVitalsAuditor/0.1 token appended. Some sites serve different content to identified tools, so scores can differ slightly from an anonymous Lighthouse run.
• If robots.txt can't be fetched because of a server error, 429 or network error, the host is treated as fully disallowed (RFC 9309) and you get a free item with errorCode: robots-unavailable. A 404 robots.txt means no restrictions.
• Private, loopback, link-local and other reserved network addresses are never audited (errorCode: blocked-private). If a page redirects to such an address, or to a host whose robots.txt disallows it, the result is discarded and not charged.