sixty

what it is for

My Lovable app got slow after a change

It was fine yesterday. You asked for one more feature, published, and now a page takes several seconds — or it hangs on the loading spinner and never finishes. Nothing in the editor looks wrong, and asking the agent to "make it faster" changes things that were not the problem.

Why it is hard to see

A Lovable app has no server of its own, so the usual answer — read the server logs — has nothing to read. What actually changed is almost always a query: the agent rewrote a component and, on the way, dropped a filter or moved a fetch inside a list. Both are invisible in the editor and neither one throws.

The other reason it is hard to see is that it was not slow when it was written. Against the handful of rows in your project it is instant. It only becomes slow once there is real data behind it, which is generally a while after the change that caused it.

What Sixty does about it

The browser agent measures every Supabase query the page makes: how many, and how many rows each one hands back. Publish twice and the second publish is compared against the first, so the finding names the version rather than the day.

What you get is a sentence — this query returned 30 rows and now returns 30,000, on this page, since this publish — and the evidence goes to whatever agent you use, so the fix is a diff rather than a guessing game.

What it does not do

The first finding arrives after your next publish, not immediately: there is nothing to compare a single version against. And editing in the Lovable preview is not enough — the preview runs a dev server with no fingerprinted assets, so there is no version to anchor a comparison to.

Related

Find out what your last change did.

Sign in
Why your Lovable app got slow after a change — Sixty