Monitoring Core Web Vitals with the PageSpeed Insights API and n8n

A one-off performance audit says nothing about what happens between two checks: a newly added plugin, an uncompressed image pushed live on a Friday night, or a new third-party banner can silently degrade a page's Core Web Vitals for weeks before anyone notices. This guide shows how to query the PageSpeed Insights API directly from n8n, log the scores to Supabase, and trigger an alert the moment a regression crosses a threshold — the same principle as the site uptime monitoring already covered on this blog, applied here to performance rather than plain HTTP status.

Why performance deserves continuous monitoring

Core Web Vitals — LCP (Largest Contentful Paint, how fast the main content renders), INP (Interaction to Next Paint, responsiveness to interactions), and CLS (Cumulative Layout Shift, visual stability) — aren't just technical metrics: they directly shape visitor behavior. A foundational study in human-computer interaction, Fiona Fui-Hoon Nah's A study on tolerable waiting time: how long are Web users willing to wait? (Behaviour & Information Technology, 2004), shows that a user's tolerance for waiting drops sharply past a few seconds, with a measurable effect on task abandonment. On related ground — the causal impact of latency on user behavior rather than mere correlation — Shubho Sengupta Krishnan and Ramesh K. Sitaraman's study, Video Stream Quality Impacts Viewer Behavior: Inferring Causality Using Quasi-Experimental Designs (IMC 2012), uses a quasi-experimental design to establish that degraded latency does cause higher abandonment, not the other way around. Together, these findings justify treating a performance regression as a real incident, one to detect and fix as quickly as a server outage.

Understanding the PageSpeed Insights API

Google's PageSpeed Insights API v5 accepts a plain HTTP GET request with the URL to test and an API key:

https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=https://example.com/&key=YOUR_KEY&strategy=mobile&category=performance

The JSON response contains two distinct blocks:

• loadingExperience — field data from the Chrome UX Report (CrUX): what real Chrome visitors actually experienced, available only if the page gets enough traffic;
• lighthouseResult — a simulated lab audit (the Lighthouse engine), always available, with raw LCP and CLS values plus a performance score out of 100.

The API key is created for free in the Google Cloud Console (enable the "PageSpeed Insights API" on a project). The free quota — 25,000 requests per day, 240 per minute — is far more than enough to monitor a catalog of pages several times a day without ever getting close to it.

Building the n8n workflow

The pipeline breaks down into five steps, reusing building blocks already covered on this blog:

1. Schedule Trigger — runs every 4 to 6 hours; see our guide on the Schedule Trigger node and time zones to line up the timing with your traffic (avoid testing in the middle of the night if you want CrUX data representative of peak hours).
2. Set node — a static list of URLs to monitor (homepage, pack pages, checkout page), or a read from a Supabase table if the catalog changes often.
3. Loop Over Items — iterating over each URL, with a short delay between calls to stay well within quota limits; see the dedicated n8n loops guide for configuring batch processing.
4. HTTP Request — calling the PageSpeed Insights API for each URL, using strategy=mobile (mobile remains the most demanding and representative baseline); check our guide on the HTTP Request node, retries, and timeouts to absorb the API's sometimes high latency (a Lighthouse audit can take 15 to 30 seconds per page).
5. Code node — extracting the useful metrics (lighthouseResult.audits['largest-contentful-paint'].numericValue, cumulative-layout-shift, performanceScore) and writing them to a dedicated Postgres/Supabase table, keyed by date and URL.

Logging scores to catch a regression, not just a bad number

A single Lighthouse score isn't very actionable on its own: variance between two consecutive runs, even with zero changes to the site, can span several points. What matters is the trend. The Code node compares each new measurement against the moving average of the last 5 to 10 stored runs (the same logic described in our article on detecting SEO traffic content decay, applied here to performance instead of traffic):

• LCP rising more than 20% above the moving average;
• CLS crossing the recommended 0.1 threshold after previously staying under it;
• Overall performance score dropping by more than 10 points.

These thresholds, deliberately wider than a single one-off dip, filter out Lighthouse's natural measurement noise while staying sensitive to a real, sustained regression.

Alerting with an LLM that prioritizes, not just notifies

Sending a raw alert ("LCP increased on /packs/pack-assistant-rag") leaves the interpretation work to the team. An AI node downstream of the regression check can do better: starting from the detailed Lighthouse audit (which already lists improvement opportunities — unoptimized images, render-blocking JavaScript, unpreloaded fonts), a summarization prompt produces a message that's directly actionable in Slack, following the same pattern as the human approval via Slack workflow already documented:

"LCP for /packs/pack-inbox-ia went from 1.8s to 3.4s since yesterday. Most likely cause per the Lighthouse audit: a 2.1MB hero image added without compression (hero-inbox-v2.png). Recommendation: compress to WebP and add fetchpriority="high"."

That level of detail turns a monitoring alert into an actionable ticket, without anyone needing to reopen the full audit by hand.

Connect this monitoring to your other SEO signals

Performance is just one factor among several in organic visibility. This pipeline pairs naturally with the weekly Search Console SEO report (to cross-reference a ranking drop with a performance regression that happened around the same time) and with the automated accessibility audit, since many fixes (missing image dimensions, contrast, visible focus) improve both accessibility and CLS at once. Both workflows can write to the same Supabase tables for a single technical health dashboard.

Common pitfalls

• Testing desktop only: Google indexes and ranks overwhelmingly mobile-first; if only one device can be monitored, make it mobile.
• Treating missing CrUX data as an error: a new or low-traffic page simply won't have a loadingExperience field — that's not a workflow bug, just insufficient traffic volume; fall back to Lighthouse-only data in that case.
• Alerting on every single run without smoothing: without a moving average, Lighthouse's natural variance (±5 to 10 points depending on Google's audit server load) generates constant false positives and eventually gets real alerts ignored.
• Forgetting the upcoming API change: Google plans to remove CrUX data from the PageSpeed Insights API in favor of the dedicated CrUX API; keep the HTTP Request node isolated in a sub-workflow so you can switch endpoints without touching the whole pipeline, as recommended in our guide on sub-workflows.

Going further

This monitoring pipeline — scheduled API calls, Supabase logging, contextualized AI alerts — reuses the exact architecture already shipped in the Compliance & Audit Pack (149 €), whose AI summary report workflow can be adapted without a rewrite to summarize performance audits instead of compliance audits. If your immediate priority is shoring up internal communications before tackling web performance, the Inbox AI Pack (79 €) remains the fastest starting point.