Source Analytics

PageSpeed Insights

Core Web Vitals and Lighthouse scores recorded daily, so page performance has a history instead of a screenshot.

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.

Talk to us Ask for a sample schema

What we ingest

There are no export tables here. PageSpeed Insights is an API with no memory, so what we ingest is what we record — on a schedule, for a URL set decided with you.

Lighthouse lab results API

Category scores and the individual audits behind them — LCP, CLS, TBT and the rest — kept per run rather than collapsed into a headline number.
CrUX field data API

Real-user Core Web Vitals distributions for the URL and its origin, when Chrome UX Report has enough traffic to report them. The fallback level is recorded on every row.
Lighthouse version API

Stored on every run, because Google changes how scores are calculated. Without it, a genuine regression and a methodology change look identical.
Tracked URL set Your decision

Which URLs, and mobile versus desktop as separate series. Not a platform artifact but a scoping decision — the daily quota makes “every URL” unrealistic on a large site.

None of this exists until it is scheduled. How the tracked set gets chosen and paced is covered further down, in how we work with PageSpeed data.

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 data models 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 discovery call 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.

Delivered to a database you own

Every table — raw and modeled — 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 Your data models 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.

How current the data stays

Data models rebuild every day. Where a platform restates recent numbers after the fact, we re-read those days rather than freezing the first version we saw.

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.

What lands in your database

Not raw API responses — data models: named, documented tables at a stated grain, rebuilt every day and ready to query. Each one has its own page.

The shipped data models are the starting point, not the ceiling. When your questions need a different shape — another grain, another split, a join against another source — we build additional models for your stack as part of the engagement.

What you can run on PageSpeed data

Every capability we ship works on these data models from day one.

Every day you wait is a day of performance history you can’t get back.

The API has no past — history starts when monitoring starts. Tell us which URLs matter, and we’ll size the daily run against the quota before anything is scheduled.