Vibe-coded the app. Now make it fast — with AI.

AI will write your entire app in an afternoon. It will not make it load fast — and Google ranks you on speed.

That gap is where most vibe-coded projects stall. The features work, the design looks right, and the Lighthouse score is a red 40-something. The good news: the same AI that wrote the slow code is very good at fixing it, if you hand it evidence instead of vibes.

Here is the workflow that took one of my Next.js builds to a perfect 100.

First — what Google actually grades

Three numbers decide your Core Web Vitals. Everything below is aimed at one of them.

Metric	What it measures	Good
LCP	How fast your main content loads^[1]	under 2.5s
INP	How fast the page reacts to a tap^[2]	under 200ms
CLS	How much the layout jumps while loading^[3]	under 0.1

Step 0 — Let AI read the audit

Do not ask AI to "make my site faster." Ask it to interpret a real report. Run Lighthouse or PageSpeed Insights first, then paste the whole thing:

Here's my Lighthouse report: [paste]. Scores: LCP 4.1s, INP 320ms, CLS 0.24.
List the exact issues causing each, ranked by impact, with the file to fix.

The ranking is the valuable part. Performance work has a long tail of tiny wins — you want the two or three changes that move the number, not a checklist of forty.

Fix 1 — What blocks the first paint

The cause: a heavy hero image and one giant CSS file. The browser cannot paint until it has parsed your entire stylesheet, and your largest element is usually an unoptimised image.

Here's my hero component and global CSS: [paste]. It's my LCP element.
Serve AVIF/WebP with a fallback, add width & height, preload it, and inline
the critical above-the-fold CSS while deferring the rest — in Next.js.

The fix: AVIF/WebP with explicit dimensions, preload the hero, lazy-load everything below the fold, and inline the critical CSS so the first paint never waits on the full stylesheet.^[4]

Fix 2 — What blocks interaction

The cause: too much JavaScript, and third-party scripts you forgot you added. Analytics, a chat widget and two embeds will happily eat your main thread while a user is trying to tap a button.

Here's my bundle analysis and my third-party scripts (analytics, chat, embeds): [paste].
Which are heaviest, which can I defer or load on interaction, and how do I
code-split the rest in Next.js?

The fix: code-split by route, dynamic-import the heavy components, then tame the third parties — async/defer them, delay the non-essential ones until after load, and self-host or preconnect whatever you cannot drop.

Third-party scripts are usually the single biggest INP win, and the one people skip because the code "isn't theirs." Audit them first.

Fix 3 — What makes it feel slow

The cause: layout jumps and a slow server response. Both are felt rather than measured — the page arrives, then rearranges itself under the reader's thumb.

My CLS is 0.24 and TTFB is 1.4s on Vercel. Here's my markup and data-fetching: [paste].
Find every element that can shift on load, and show me how to cache, add a CDN,
and switch to static / ISR.

The fix: set dimensions on images and embeds, reserve space for banners and ads, use font-display: swap — then cache behind a CDN and pre-render pages as static or ISR so the server answers immediately.^[5]

The result

LCP under 2.5s
INP under 200ms
CLS under 0.1

100 / 100 / 100. Faster load, lower bounce, better rankings.

Why these prompts work

Every prompt above has the same shape: real numbers, real code, one specific question.

"Make my site faster" gets you a listicle you could have found yourself. A pasted Lighthouse report with your actual LCP, plus the component that causes it, gets you a diff. The model is not short on performance knowledge — it is short on knowing which of the forty possible problems is yours. Evidence is what closes that gap.

Run the audit, fix in the order the report ranks, re-audit. Three rounds is usually all it takes.

Building something and want it fast from day one? Get in touch — that is most of what we do.