Source Analytics

PageSpeed Insights Data, Delivered to Your Database

Q: Why do lab and field numbers disagree?

They measure different things. Lab data is one Lighthouse run under controlled throttling; field data is a 28-day distribution of real users on their actual devices and networks. Lab tells you what changed today; field tells you what users have experienced lately. The marts store both, labelled, so nobody averages them together by accident.

Q: How many URLs can you track?

The API has a daily quota (25,000 queries per day by default) plus a short-window rate limit, so tracking every URL of a large site daily isn’t realistic — and isn’t useful either. We track a curated set that represents your page types: a template that’s fast for one product page is fast for the rest.

Q: Why did scores shift when nothing changed on the site?

Lighthouse itself changes — new versions adjust metric weights and scoring curves, and single runs vary naturally. The pipeline records the Lighthouse version with every run, so a version-caused shift is visibly different from a regression you shipped.

Q: Do you test mobile, desktop, or both?

Both, as separate series. Mobile and desktop runs use different throttling profiles and produce different numbers by design — and mobile is where Core Web Vitals is usually won or lost. Every mart row carries its device class.

Cleaned, enriched and modeled into ready-to-query mart tables. Currently on BigQuery. We run the pipeline, you own the data.

PageSpeed Insights offers no export and no history — every API call answers only for the moment you make it. Insightlytics runs the API on a daily schedule for a URL set that represents your page types, storing every Lighthouse lab result and CrUX field distribution — mobile and desktop as separate series. What lands is Core Web Vitals history: per URL, per device class, per day, with pass/fail flags and the Lighthouse version recorded; we run the scheduling, the quota pacing and the monitoring. Everything is written to a database you own — BigQuery today, with more warehouses on the roadmap.

Book an architecture review Ask for a sample schema

The problems we solve

A point-in-time API with two kinds of truth in one response — lab and field. These are the problems every performance team hits, and the ones this pipeline is built around.

Why doesn’t PageSpeed Insights have any history?

Every API call answers for right now; yesterday’s answer is gone unless someone stored it. So the question every performance incident begins with — when did the regression actually start? — is one the API cannot answer.

A trend line exists only because the pipeline snapshots on a schedule. With daily runs in your own database you can pin the day a metric moved, line it up against deploys and Lighthouse version changes, and answer with a date instead of a guess.

Why do lab and field Core Web Vitals disagree?

Because they answer different questions. Lab is one synthetic Lighthouse run on a throttled connection; field is CrUX’s 28-day distribution of your real visitors on their real devices. A page can pass in the lab and fail in the field — or the reverse.

It also means a fix shipped today takes weeks to fully register in field data, as old sessions age out of the window. Lab catches the change same-day; field confirms it over the following weeks. The marts store both, labelled, so nobody averages them together by accident.

Why does your page show origin data instead of URL data?

CrUX only reports URL-level data for pages with enough real traffic; below that threshold the API silently substitutes origin-level numbers. Treating those as page measurements is a category error.

The pipeline flags the fallback level on every row, so ‘this template has no field data’ becomes a finding, not a hidden footnote.

How many URLs can you track with the PageSpeed API?

The API allows 25,000 queries per day by default, with a short-window rate limit on top — so monitoring every URL of a large site daily isn’t realistic. It also isn’t useful: a template that’s fast for one product page is fast for the rest.

The honest model is a curated URL set that represents each page type, tracked at URL × device class × day grain. Which URLs make the set is a consulting decision, and it’s the first thing we settle.

Why is your PageSpeed score different every run?

Lab runs are simulations, and simulations vary — server response times, third-party scripts and throttling all wobble between runs, and Lighthouse versions change the scoring itself. Chasing a single score up and down is chasing noise.

Stored daily runs give you medians and trends — the level at which the score actually means something — with the Lighthouse version recorded, so a scoring change is visibly different from a regression you shipped.

How we work with PageSpeed data

There is no export to enable here — the API is the route, and the schedule is what turns it into a dataset.

Each day we run the API for a curated URL set — mobile and desktop as separate series — and store every Lighthouse lab result and CrUX field distribution. The set itself is the consulting decision: the daily quota makes "every URL, every day" unrealistic for large sites and statistically pointless anyway, so we build a set that represents each of your page types and model the results at URL × device class × day grain, with the CrUX fallback level recorded on every row.

The architecture review settles the tracked set and the grain — and there’s nothing to grant on your side, since the API measures public URLs. From there, running the pipeline is our job: scheduling, quota pacing and Lighthouse-version tracking included.

Refresh, backfill and monitoring

Refresh

Daily scheduled runs for the tracked URL set, mobile and desktop as separate series, paced within the API’s quota.

Backfill

None exists — the API has no past. History starts the day monitoring starts and accumulates in your database from there; the earlier it starts, the more it can answer.

Monitoring

Every run is checked for freshness and volume. Metric changes on Google’s side (as when INP replaced FID) arrive as new columns, and the recorded Lighthouse version keeps old and new scores comparable.

Delivered to a database you own

Every table — raw and mart — is written to your own database, under your billing and your access controls. Our access is read-only, and if we part ways, everything stays with you.

BigQuery Marts are built in your own BigQuery project — our access is read-only, and the tables are always yours.

BigQuery is the supported database today. If you run a different warehouse, tell us — the roadmap is driven by requests.

What lands in your database

Not one-off JSON responses — named mart tables at documented grain, refreshed daily and ready to query.

mart_cwv_daily Field Core Web Vitals per URL and device class, per day, with pass/fail flags and the fallback level recorded.
mart_psi_scores_daily Lighthouse category scores per URL per day, with the Lighthouse version that produced them.

The standard marts are the starting point, not the ceiling. When your questions need a different shape — another grain, another split, a join against your Search Console page marts — we define additional marts for your stack as part of the engagement.

What you can run on PageSpeed data

Every capability we ship works on these marts from day one.

Frequently asked questions

If something is still unclear, a discovery call clears it up fast.

Can you backfill Core Web Vitals history?

Not at the URL level — the PageSpeed Insights API has no past; it only answers for the moment you call it. Origin-level monthly aggregates exist in the public CrUX dataset, but URL-level daily history exists only if someone was storing it. That’s the whole argument for starting monitoring early: the series begins the day the pipeline does.

Why do lab and field numbers disagree?

How many URLs can you track?

Why did scores shift when nothing changed on the site?

Do you test mobile, desktop, or both?

Core Web Vitals as history, not snapshots — in a database you own.