Lovable monitoring: re-check your app's speed from the Lovable chat after every change

What you'll set up

A loop with four moves: you build in Lovable, you publish, you ask Lovable to run Relvato's Core Web Vitals monitor on the published app, and Lovable reads the result and fixes what regressed. The numbers come from Relvato loading your page in a real Chrome browser, on a throttled phone and on desktop — not from Lovable guessing.

You need a Relvato account (the free plan works: runs you start from the chat are manual runs, and the free plan includes 100 a month), a Lovable account on any plan (custom MCP servers are available on all Lovable plans, including Free), and a published app. Relvato measures the published address — the lovable.app subdomain or your custom domain — never the editor preview, because that is what visitors load.

If “MCP server” is greyed out when you get to Step 2, a workspace admin has turned off custom MCP servers for your Lovable workspace; ask them to allow it.

Step 1 — Create a Relvato API key for Lovable

In Relvato, open the account menu → API access. Give the key a name you'll recognise later, such as “Lovable”. Under What the key may do, choose Full access: a read-only key can read results but can't run a monitor, and running one is the point of this setup.

Click + Create API key and copy the key straight away — Relvato shows it only once. It starts with rlv_. You can revoke it from the same page at any time, which cuts Lovable off without touching anything else.

Step 2 — Add Relvato as a chat connector in Lovable

In Lovable, open Connectors (from the dashboard sidebar, or inside a project), select the + button at the top right of the catalog and choose MCP server. Fill in Server name: Relvato, and Server URL with the address below. For authentication, choose Bearer token or API key, paste your rlv_ key and click Add server.

The connection is personal: you signed in with your own key, only you can use it, and it never becomes part of the app you publish — your visitors can't reach Relvato through it. Teammates who want the same loop add Relvato themselves, with their own key.

https://app.relvato.com/api/mcp

Step 3 — Add your app to Relvato, from the same chat

If the app is already in Relvato, skip ahead. Otherwise you don't need to leave Lovable. Ask: “Use Relvato to add my app https://your-app.lovable.app as a site (platform: other).” Relvato answers with a verification tag that proves the site is yours, like the line below.

Ask Lovable to put that tag in the page's head (in index.html for apps built before May 2026, or in the root layout for newer ones), publish with Publish → Publish changes, then ask “Verify my site in Relvato.” Once Relvato finds the tag, the site is ready. If the app has a custom domain, add that address instead of the lovable.app one: it's the one your visitors use, and Lovable only redirects the others to it temporarily.

<meta name="relvato-site-verification" content="…">

Step 4 — Add the Core Web Vitals monitor

Ask: “Add Relvato's Core Web Vitals monitor to my site.” Lovable calls Relvato's add_checks tool with the web-vitals monitor. It measures one page — the homepage unless you choose another in the monitor's settings in Relvato.

Each run loads the page three times on a phone with throttled network and CPU (the same Slow 4G and 4× CPU profile PageSpeed uses) and three times on desktop, and keeps the median: Largest Contentful Paint, Cumulative Layout Shift, Time to First Byte, First Contentful Paint, Total Blocking Time and a lab estimate of Interaction to Next Paint, plus a 0–100 score per device.

Step 5 — After each publish, ask for a run

Make it a habit: publish first (Publish → Publish changes), then send a prompt like “Run Relvato's Core Web Vitals monitor on my site, wait until it finishes, and compare LCP, CLS and TTFB on mobile with the previous run.” Lovable starts the run with trigger_scan, then reads it with get_run until it's done — usually about a minute.

Lovable asks before it uses an MCP tool unless the server marks the tool as read-only. Relvato marks its reading tools that way (site_overview, list_runs, get_run, get_fix_prompt), so only starting a run or changing something asks first: choose Always allow for trigger_scan if you don't want the prompt each time.

Every run counts toward your Relvato plan's monthly runs, and Lovable counts tool calls toward your credits like any other connector use.

Step 6 — Let Lovable fix what got slower

The run details tell Lovable why a number moved, not only that it did: the element that was the Largest Contentful Paint and how long each phase of it took, the elements that shifted the layout, the scripts that blocked rendering, oversized images and how much of the JavaScript went unused. That is enough for Lovable to change the right line instead of guessing.

Try: “Use the details of that Relvato run to fix the mobile LCP regression, then publish and run the monitor again.” For a run that failed outright, “Get Relvato's fix brief for this run” returns the same brief Relvato's Suggest a fix uses. Review Lovable's change as you would any other, publish, and let the next run confirm the fix.

Older Lovable apps: what the browser actually waits for

Lovable apps created from 13 May 2026 render on the server. Older ones are client-rendered single-page apps: the browser receives an almost empty page and waits for the JavaScript bundle before it can paint the main content. Lovable serves a pre-rendered copy only to verified search crawlers, so scanners that just fetch the HTML can see an empty page.

Relvato doesn't fetch the HTML — it loads the page in Chrome the way a visitor does, so its LCP includes that wait for the bundle. If an older app's mobile LCP is high and the LCP element only appears after the JavaScript runs, the bundle is the thing to shrink, and splitting it is a change Lovable can make for you.

Make it run without asking (optional)

Chat runs happen when you ask. To have Relvato re-run every enabled monitor on its own whenever the code changes, connect the GitHub repository Lovable syncs to — see connect your site to GitHub. That trigger needs Relvato's Pro plan or higher.

One caveat: Lovable pushes to GitHub as you edit, which can be before you publish, so a push-triggered run may measure the version that's still live. The run you start from the chat after Publish changes measures exactly what you shipped.