Bulk PageSpeed & Lighthouse Checker: Core Web Vitals from CSV
Pricing
from $3.50 / 1,000 page tests
Bulk PageSpeed & Lighthouse Checker: Core Web Vitals from CSV
Google PageSpeed Insights (Lighthouse) scores, Core Web Vitals and top speed fixes for every URL in an Apify dataset, CSV or Google Sheet, keeping every original column. Inputs: datasetId or fileUrl, strategy. Charged per completed report. Agent-ready: x402, MCP.
Pricing
from $3.50 / 1,000 page tests
Rating
0.0
(0)
Developer
Adam Pearce
Maintained by CommunityActor stats
0
Bookmarked
2
Total users
1
Monthly active users
2 days ago
Last modified
Categories
Share
Bulk PageSpeed & Lighthouse Checker (Dataset, CSV or Sheet)
How fast is every website on this list, does it pass Google's Core Web Vitals, and what would fix it?
Pasting sites into PageSpeed Insights one at a time is a browser tab and a minute of waiting per page. This takes the list you already have, a dataset, a CSV, an Excel file or a Google Sheet, and adds Google's own PageSpeed Insights (Lighthouse) results to every row: the performance, accessibility, best practices and SEO scores, the speed timings, the real-visitor Core Web Vitals verdict, and the top fixes ranked by how much time they would save.
Every original column comes back untouched, so nothing has to be matched up by hand afterwards.
Who uses this
- Agencies and freelancers finding prospects. Run a scraped list of local businesses, keep only the sites scoring under 50, and every row already says what is wrong ("Reduce unused JavaScript, Est savings of 1,520 KiB"). That is the opening line of the pitch.
- Client reporting. Test every client site each week with a schedule and append to one named dataset, so you have a speed history per client without opening PageSpeed once.
- SEO audits of a whole site. Feed it a list of page URLs (paths are kept) and see which templates are slow, which fail Core Web Vitals and which have SEO checks failing.
- Checking before and after a change. Run the same list before and after a redesign, a new host or a plugin clean-up, then compare with Diff & Change Detector.
Where the data comes from
From Google PageSpeed Insights, Google's own official API, which runs Lighthouse on Google's servers. This is the same test as pagespeed.web.dev, not an imitation of it. No scraping and no browser on our side. The Actor includes its own Google API key, so you do not need one.
There are two kinds of result, and both come back:
- Lab data: Google loads the page once on a simulated phone (or computer) and times it. This gives the 0 to 100 scores and timings such as LCP (how long until the main content shows). Lab scores move a few points between runs of the same page; that is normal Lighthouse variation, not an error.
- Field data: how the page actually performed for real Chrome visitors over the last 28 days, from Google's Chrome UX Report. This is what the Core Web Vitals pass or fail verdict is based on, and it is what Google uses in search ranking. It only exists for pages or sites with enough traffic; for a small site the field columns are empty rather than estimated, and
FieldDataScopesays whether the data is for the exact page or the whole site.
What you get on every row
Columns are prefixed with the device (mobile, and desktop too if you test both), so the two sit side by side:
| Column | What it is |
|---|---|
mobilePerformanceScore | 0 to 100. Google's bands: 90+ good, 50 to 89 needs improvement, under 50 poor. mobilePerformanceRating says which |
mobileAccessibilityScore, mobileBestPracticesScore, mobileSeoScore | The other three Lighthouse scores, 0 to 100 |
mobileLcpSeconds, mobileFcpSeconds, mobileSpeedIndexSeconds, mobileTbtMs, mobileCls | Lab timings: main content, first content, visual speed, blocking time, layout shift |
mobileServerResponseMs, mobilePageWeightKb | How long the server took to answer, and how heavy the page is |
mobileCoreWebVitals | pass or fail for real visitors (LCP, INP and CLS all good), empty when Google has no field data |
mobileFailingVitals | Which vitals failed and by how much, e.g. CLS 0.13 (needs improvement) |
mobileFieldLcpMs, mobileFieldInpMs, mobileFieldCls | The real-visitor 75th percentile values |
mobileTopFixes | Google's suggested fixes, biggest estimated saving first |
mobileFailedSeoChecks, mobileFailedAccessibilityChecks | The pass/fail checks the page failed, e.g. Document does not have a meta description |
testedUrl, finalUrl, redirected | What was tested and where it ended up. A redirect, even just to www., costs load time and is flagged |
pageSpeedStatus, mobileStatusDetail | ok, or why there is no report (see below) |
pageSpeedReportUrl | A link to open the same test on pagespeed.web.dev |
The same page listed twice (bbc.co.uk and https://bbc.co.uk/) is tested and charged once, and both rows get the result, the second marked isDuplicate.
Example
Real output for python.org on mobile, from a run on 23 September 2026:
{"company": "Python","website": "https://www.python.org/","testedUrl": "https://www.python.org/","pageSpeedStatus": "ok","redirected": false,"mobilePerformanceScore": 77,"mobilePerformanceRating": "needs_improvement","mobileAccessibilityScore": 75,"mobileBestPracticesScore": 96,"mobileSeoScore": 92,"mobileLcpSeconds": 4.98,"mobileCoreWebVitals": "pass","mobileFieldDataScope": "page","mobileFieldLcpMs": 1211,"mobileTopFixes": "Render-blocking requests (Est savings of 2,510 ms); Reduce unused CSS (Est savings of 128 KiB); Reduce unused JavaScript (Est savings of 59 KiB)","mobileFailedSeoChecks": "Links do not have descriptive text"}
Notice the page passes Core Web Vitals for real visitors while scoring 77 in the lab. That is common, and it is why both are returned: the lab score shows what to fix, the field verdict shows what Google ranks on.
The run summary (PAGESPEED_SUMMARY in the key-value store) adds the average score per category, the ten slowest pages, and the fixes that come up most often across the whole list, which is usually the fastest way to see what a set of sites has in common.
Input
- Dataset, File URL (CSV, TSV, Excel, JSON, JSON Lines, or a Google Sheet shared as "anyone with the link") or inline data.
- URL field: the column with the website. Detected automatically in most lists. Bare domains, full URLs and paths all work.
- Device: mobile (what Google ranks on, the default), desktop, or both.
- Scores to include, Fixes to list per page, Rows to keep (all, slow only, fast only, failing Core Web Vitals only, problems only) and the slow threshold (default 50).
- Google API key: optional, only if you want your own daily allowance for very large lists.
- Exports: CSV and/or Excel files, a named dataset to append to, and a webhook for the run summary.
What it costs
$0.005 per page tested per device, which is $5.00 per 1,000 tests at the standard rate and less on Bronze, Silver and Gold. Testing both mobile and desktop is two tests. Files are $0.01 each, a webhook delivery is $0.02.
You are charged for a report, not for an attempt. A page Google could not load (the site is down, blocks Google, or never paints), a value that is not a web address, a rate limit and a timeout are all free, and each row says why.
Filtering happens after testing, so keeping only the slow rows does not make the run cheaper.
A 1,000-site list on mobile costs about $5. Google takes 10 to 90 seconds per test and the Actor runs 8 at a time, so 1,000 sites take roughly one to two hours; set it off and come back, or schedule it overnight.
FAQ
Is this allowed? Yes. PageSpeed Insights is Google's public API, provided for exactly this. Nothing is scraped.
Why is my score a few points different from pagespeed.web.dev? Every Lighthouse run is a fresh page load, so lab scores move a little between runs, on Google's own site too. For a decision, look at the rating band and the field verdict rather than a two-point difference.
Why are the Core Web Vitals columns empty? Google only publishes real-visitor data for pages and sites with enough Chrome traffic. Most small business sites have none, and this Actor will not invent it. The lab scores are still there.
Why did a site come back page_failed? Google's own servers could not load it: the domain does not resolve, the server refused, or the site blocks Google. The reason is in mobileStatusDetail, and it was not charged. That is useful on its own for a prospect list.
I am seeing rate_limited. Lower Concurrency, or add your own free Google API key for your own daily allowance.
Can I feed last week's output back in? Yes, that is how a weekly check works. Any PageSpeed column already in your rows is replaced with this run's result (and the run tells you it did), so an old score is never left looking current.
Do I need a Google API key? No. Add one only if you run many thousands of pages a day.
The rest of the toolkit
The natural pair is Tech Stack Detector, Domain WHOIS & Age Checker and Website Contact Finder: run them on the same list, or chain them with the Pipeline Runner, to get every company's site speed, tech stack, domain age and business inbox in one table.
For the data itself: Dataset Cleaner & Exporter, Filter & Transform, Join & Merge, Aggregate, Group By & Pivot, Diff & Change Detector, AI Enrich, Charts & Report, to Postgres, Supabase & MySQL, to REST API, and Actor Pipeline Runner to chain them in one call.
If this saved you pasting a few hundred sites into PageSpeed Insights one at a time, a review on the Store page helps a lot. If something looks wrong, open an issue on the Issues tab and I will answer personally.