Skip to main content
Continuous monitoring

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.

Scheduled PageSpeed / Core Web Vitals monitoring requires a paid Team, Agency, or Compliance plan. Free, Starter, and the no-card 14-day trial do not include it.

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.

Performance scorethe Lighthouse 0–100 headline score
LCPLargest Contentful Paint — how fast the main content lands
CLSCumulative Layout Shift — how much the page jumps around
TBTTotal Blocking Time — the lab proxy for input responsiveness
FCPFirst Contentful Paint — time to first visible render
TTFBTime To First Byte — how fast your server answers

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?

Scheduled PageSpeed / Core Web Vitals monitoring requires a paid Team, Agency, or Compliance plan. Free, Starter, and the no-card 14-day trial do not include it. The public PageSpeed checker is free without an account. Moving from Free to Starter does not add scheduled performance monitoring; upgrading to Team or higher lets you enable it for your assets. The no-card trial does not unlock this feature, and an expired trial becomes read-only unless you upgrade.

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. Available on paid Team plans and higher.

Track performance over time with Team

Scheduled PageSpeed / Core Web Vitals monitoring requires a paid Team, Agency, or Compliance plan. Free, Starter, and the no-card 14-day trial do not include it.

One-off PageSpeed tests remain free, with no signup. For free account monitoring, start with SSL and DNS checks instead.