Get paged when your Core Web Vitals regress.
Your Lighthouse score was great the day you launched — then came the tag manager, the chat widget, the hero video. Merlonix re-runs PageSpeed Insights on a schedule and alerts you when the score or a vital genuinely gets worse, with the before → after numbers.
How it works
01
Turn it on for an asset
Enable performance monitoring on any monitored asset (Team plan and up). No script tag, no agent — the measurement runs from Google’s infrastructure against your public page.
02
We run Lighthouse on a schedule
Merlonix calls Google PageSpeed Insights for your page on a scheduled cadence (up to once per day per asset) and records the performance score plus the lab Core Web Vitals: LCP, CLS, TBT, FCP and TTFB.
03
We compare against your last run
Each run is diffed against the previous one using the standard CWV buckets (good / needs-improvement / poor). Noise-level wiggle and improvements are recorded silently — they never page anyone.
04
You get an alert on a real regression
A score drop of 10+ points, or any vital crossing into a strictly worse bucket, fires one warning with the before → after numbers — so you can connect it to the deploy, script, or image that caused it.
What we track
The score, plus every lab vital.
Recorded on every run, so you get a history — not just a number from the one day you remembered to check.
Why continuous beats a one-time test
Performance regressions ship silently
Nobody notices the marketing tag, the hero video, or the A/B-test script that added 800 ms of blocking time — the page still “works.” A scheduled re-measure catches the regression the day it ships, while the diff is still small enough to pin to a change.
Vitals are a ranking signal
Google uses page experience signals, including Core Web Vitals, in ranking. A vital that quietly slides from good to poor doesn’t just annoy visitors — it erodes the organic traffic you worked for, compounding weekly until someone happens to re-run a test.
Regression-only alerting, honestly bucketed
Lab scores naturally fluctuate a few points between runs. We alert only on a 10+ point score drop or a bucket transition (good → needs-improvement → poor) — the same thresholds Google uses to grade vitals — so an alert from us is worth interrupting your day for.
What we promise — and what we don’t
We measure and compare. We don’t inflate.
Merlonix runs Google’s own Lighthouse measurement against your page up to once a day, records the score and lab vitals, and alerts only on a genuine regression — a 10+ point score drop or a bucket transition. These are lab metrics, not field data; a failed run is recorded as failed, never guessed. Fixing the regression — the script, the image, the render-blocking change — happens on your side; we make sure you find out the day it ships, with numbers you can act on.
Common questions
What exactly gets measured?
Each run calls Google PageSpeed Insights — the same Lighthouse engine behind pagespeed.web.dev — and records the performance score plus the lab Core Web Vitals: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), Total Blocking Time (TBT), First Contentful Paint (FCP), and Time To First Byte (TTFB).
Are these lab metrics or real-user (field) data?
Lab metrics: a controlled, repeatable synthetic run from Google’s infrastructure. That’s the right tool for regression detection — consistent conditions mean a change in the number reflects a change in your page, not in who happened to visit. It is not CrUX field data, and we don’t pretend otherwise.
When do you alert — and when do you deliberately stay quiet?
One warning fires when your performance score drops by 10 or more points versus the previous run, or when any vital crosses into a strictly worse bucket (good → needs-improvement, needs-improvement → poor). Small run-to-run fluctuations, improvements, and a first run with no baseline never alert. A failed or over-quota measurement is recorded honestly as such — also never an alert.
What does the alert tell me?
The before → after values for the score and each worsened vital (for example “score 0.94 → 0.71, LCP 1,800 → 4,200 ms”), so you can immediately correlate the regression with what shipped that day.
How often does it run?
On a scheduled cadence of up to once per day per asset. Performance regressions are a daily-granularity problem — they ship with deploys and content changes, not by the minute — and daily cadence keeps the measurement well inside Google’s free API quota.
Which plans include it?
PageSpeed / Core Web Vitals monitoring is available on Team plans and up — see the pricing page for the full per-plan comparison.
Your next regression ships this quarter. Catch it same-day.
Turn on Core Web Vitals monitoring and get the before → after numbers the day performance slips. Start the full-workspace trial — 14 days, no card.