PageSpeed Insights Bulk: Core Web Vitals for many URLs

Core Web Vitals and Lighthouse scores for up to 300 URLs per run, straight from Google's own PageSpeed Insights API. Every row pairs the field data real Chrome users produced over the last 28 days with the lab scores and the heaviest fixes Lighthouse found.

You bring your own free Google API key. That is a deliberate choice, not a missing feature: the key stays yours, the quota stays yours, and nobody sits between you and Google.

Two kinds of numbers, and the difference matters

Field data (field... columns) comes from the Chrome User Experience Report: what real visitors experienced over 28 days. This is what Google ranks on. A page with too little traffic has no field data, and then originOverall still tells you how the domain as a whole is doing.

Lab data (lab... columns and the four scores) is a single measurement in a simulated phone, made right now. Always present, good for diagnosis, not what you are ranked on.

A page can score 45 in the lab and still pass Core Web Vitals in the field. Both columns are in every row so you can see that for yourself.

Getting a key (free, about two minutes)

1. Open the Google Cloud console and pick or create a project.
2. In APIs & Services > Library, search for PageSpeed Insights API and enable it.
3. In Credentials, choose Create credentials > API key.
4. Restrict the key to the PageSpeed Insights API. It then cannot be used for anything else.
5. Paste it into the apiKey field. The field is stored encrypted by Apify.

Google's free quota is generous for this kind of work. If you run out, the run returns QUOTA_EXCEEDED rows instead of failing, and the quota resets at midnight Pacific time.

Input

Field	What it does
urls	One page URL per row, up to 300. A missing https:// is added for you.
apiKey	Your own Google API key. Required.
strategy	mobile, desktop or both. both returns two rows per URL and is charged as two.
allCategories	Off by default. On adds two more score columns, but Lighthouse needs about two and a half times longer per URL. Keep those runs under 250 URLs.
locale	Optional language for the wording of the fixes, for example nl.

Input example

{
    "urls": ["https://www.wikipedia.org", "https://www.gov.uk"],
    "apiKey": "AIza...your own key...",
    "strategy": "mobile",
    "allCategories": false,
    "locale": ""
}

Output

One row per URL and device:

• url, finalUrl, strategy, fetchedAt, lighthouseVersion
• performanceScore and seoScore (0 to 100). With allCategories on you also get accessibilityScore and bestPracticesScore; with it off those two columns are not in the output at all, rather than present and empty
• fieldOverall, fieldLcpMs, fieldInpMs, fieldCls, fieldFcpMs, fieldTtfbMs, each with its own ...Rating of FAST, AVERAGE or SLOW
• originOverall: the same verdict for the whole domain
• labLcpMs, labFcpMs, labCls, labTbtMs, labSpeedIndexMs, labTimeToInteractiveMs, labServerResponseMs, totalBytesKb
• topOpportunities: the five heaviest fixes Lighthouse found, largest first, each with the time it would save
• opportunitySavingsMs: what all the fixes together would save

fieldCls is a real layout-shift score such as 0.15. Google's API returns that number multiplied by a hundred; this actor converts it back so the column matches what you see on pagespeed.web.dev.

Error codes: INVALID_URL, INVALID_KEY, QUOTA_EXCEEDED, PAGE_FAILED, FETCH_FAILED. A page Lighthouse cannot load becomes a PAGE_FAILED row and is never charged.

Output example

A real row, measured on 19-09-2026:

{
    "url": "https://www.telegraaf.nl/",
    "finalUrl": "https://www.telegraaf.nl/",
    "strategy": "mobile",
    "fetchedAt": "2026-09-19T16:14:56.226Z",
    "lighthouseVersion": "13.4.1",
    "performanceScore": 30,
    "seoScore": 92,
    "fieldOverall": "AVERAGE",
    "fieldLcpMs": 1418,
    "fieldLcpRating": "FAST",
    "fieldCls": 0.15,
    "fieldClsRating": "AVERAGE",
    "fieldTtfbMs": 855,
    "originOverall": "SLOW",
    "labLcpMs": 14617,
    "labCls": 0.123,
    "labTbtMs": 1565,
    "totalBytesKb": 4571,
    "topOpportunities": [
        "Reduce unused JavaScript: 1.8 s",
        "Reduce unused CSS: 0.5 s"
    ],
    "opportunitySavingsMs": 2200,
    "status": "ok"
}

That row shows the two things people read wrongly, which is why it is here rather than a tidy invented example. fieldCls is 0.15 for this page while originOverall says SLOW for the whole domain: the per-metric columns always belong to the page, the origin verdict never does. And the field columns say FAST where the lab columns are far slower, because the field numbers come from real visitors over the last 28 days on their own devices, and the lab number is one simulated phone on a throttled connection. Both are true and they answer different questions.

Who this is not for

Anyone without a Google API key: this actor runs on your own key, which is free and takes about two minutes to create (see above). We cannot supply one, because Google's terms do not allow reselling access to their API.

It is also not a crawler. It measures the URLs you give it and follows no links, so a whole site means feeding it a URL list, for example from a sitemap. And it is not a monitor: one run is one measurement at one moment. Google's own numbers move between runs, especially the lab columns, so compare the same page over time rather than two pages once.

Speed

Google needs 10 to 40 seconds per URL, and that is outside anyone's control. This actor runs eight in parallel, measured on the same 25 real sites:

Setting	Time for 25 URLs	300 URLs would take
Default (performance and SEO)	118 s	about 24 minutes
allCategories on	293 s	about 59 minutes

Eight in parallel is the measured optimum, not a guess: at twelve, Google starts answering with server errors, the retries pile up and the same run took more than twice as long. A run stops after one hour, so with allCategories on, keep the list under 250 URLs.

Related actors from steadydata

• technical-seo-audit: titles, headings, canonicals and indexability for the same pages
• website-tech-stack: which technologies a site runs on
• sitemap-urls: turn a sitemap into the URL list you feed to this actor

Pricing

Pay per event: one url-audited event per delivered row. No charge for inputs that fail, no separate platform-usage surcharge. Google charges you nothing for the API itself.

Free Apify plan: this actor delivers up to 25 rows per run for accounts on the Apify free plan, and then stops with a message. That limit is set by us, not by Apify. It exists so the actor keeps paying for itself for the people who do pay. Any paid Apify plan runs it at full size, billed per delivered row, with failed rows never charged.

Reviews: if this actor saves you time, a short review on this page is the one thing that helps most. Ratings are what other buyers look at first, and we have no other way to ask.

FAQ

Why do I need my own key? Google's API terms forbid reselling access to their API or the content it returns. An actor that ran on our key and charged per row would fall under both. With your own key you hold the agreement with Google, you use your own quota, and you are buying software rather than Google's data. It is free, and the quota (25,000 requests a day) is far more than this actor needs.

Does my key stay private? The field is marked as secret, so Apify stores it encrypted and it is not visible in the run input. It is used for nothing but the PageSpeed requests.

Why are the field columns empty for my page? Those come from the Chrome User Experience Report: real visitors over the last 28 days. A page without enough traffic has no field data, and Google returns nothing rather than an estimate. The lab columns are always there, because Lighthouse measures those itself.

Why is a score different from what I see on pagespeed.web.dev? Lighthouse is a simulation and repeats are not identical. Run to run, a performance score of a few points apart is normal for the same page. Use the trend over several runs, not one number.

What happens when a page fails to load? It becomes a PAGE_FAILED row with the reason, and it is not charged. A run that hits the hour limit stops early and reports which URLs it did not reach, also uncharged.