Core Web Vitals for an AI-built app: what to fix first

Core Web Vitals are three measurements Google uses to judge how a page feels to real visitors: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. A page passes when, at the 75th percentile of real visits, LCP is 2.5 seconds or less, INP is 200 milliseconds or less, and CLS is 0.1 or less. Apps generated with AI tools tend to miss them for the same few reasons, and most of those reasons are fixable without a rewrite.

This guide explains each metric in plain terms, where to find your real numbers, the usual culprits in a React app built with Lovable, Bolt, v0 or Cursor, and how to confirm a fix worked.

What do LCP, INP and CLS actually measure?

• LCP is the time until the biggest thing in the first screen (usually a hero image, a heading or a large block of text) appears. It answers "when does the page look loaded?"
• INP looks at clicks, taps and key presses across the whole visit and reports one of the slowest delays between the input and the next frame being drawn. It answers "does the page react when I touch it?" INP replaced First Input Delay as a Core Web Vital in 2024.
• CLS adds up unexpected movements of content while the page is open. It is the button that jumps just as you tap it.

The 75th percentile matters: you are judged on the experience of your slower visitors, separately for mobile and desktop. A fast laptop on office Wi-Fi tells you little about a mid-range phone on a train.

Where do I find my real numbers?

There are two kinds of data, and you need both.

1. Field data comes from real Chrome users. Look at PageSpeed Insights (the top section, "Discover what your real users are experiencing") and the Core Web Vitals report in Google Search Console. A new or small site may not have enough traffic to show field data yet.
2. Lab data is a single simulated load. Lighthouse in Chrome DevTools and the lower part of PageSpeed Insights give you this. Lighthouse can't measure INP, because nobody is clicking; it shows Total Blocking Time as a stand-in.

If field data is missing, you can collect your own with Google's small web-vitals JavaScript library and send the values to your analytics.

Why do AI-built apps often fail Core Web Vitals?

Most apps from these tools are client-rendered React. The browser downloads an almost empty HTML page, then a large JavaScript bundle, then runs it, then fetches data, and only then draws the content. Each step adds delay, and the tools add a few habits on top:

• One big bundle. Every page, chart library, icon set and date library ships on the first load, including code for the admin screens.
• Full-size images. A 4000-pixel photo uploaded straight from a phone and displayed at 600 pixels wide.
• Images without dimensions. No width and height, so the layout jumps when they arrive.
• Web fonts swapped in late, shifting text after it has already rendered.
• Data fetched in a chain. The page loads the user, then their team, then the projects, each waiting for the previous one.
• Heavy work on every keystroke. Filtering a long list or re-rendering a whole table on each input.

How do I improve LCP?

1. Find the LCP element. In Chrome DevTools, open the Performance panel and record a page load; the LCP marker tells you which element it was.
2. If it's an image, make sure the browser can see it in the initial HTML or preload it, add fetchpriority="high", and never lazy-load it. Serve it at the size it's displayed, in WebP or AVIF. Our guide to optimizing images in your web app goes through this.
3. If it's text, the delay is usually JavaScript and data. Prerendering or server-rendering public pages puts the text in the HTML from the start (see SEO for React single-page apps).
4. Cut the server response time. Serve static files from a CDN and keep the first data request fast; slow database queries show up here too.

How do I improve INP?

INP problems mean the main thread is busy when the user interacts.

• Split the bundle with route-based code splitting (React.lazy and import()), so the first page doesn't parse code it doesn't need.
• Break up long tasks. If a click triggers heavy work, show feedback first (a spinner, a disabled button) and do the heavy part after the next paint.
• Debounce search inputs and filter large lists on the server, or render only the visible rows (list virtualisation).
• Audit third-party scripts. Chat widgets, tag managers and session-recording tools often account for a large part of main-thread time. Load them after the page is interactive, or drop the ones you don't use.

How do I improve CLS?

• Give every image and video width and height attributes (or a CSS aspect-ratio), so space is reserved before they load.
• Reserve space for banners, cookie notices and ads instead of pushing content down when they appear.
• Use font-display: swap with a fallback font of similar size, or preload the main font file.
• Don't insert content above what the user is already reading, unless it's a response to their action.

How do I know a fix worked?

Lab tools react straight away: rerun Lighthouse with the same device setting and compare. Field data takes longer. The Search Console report and PageSpeed Insights use a rolling 28-day window, so a real improvement appears gradually over the following weeks. In Search Console you can mark an issue as fixed and start a validation, which tracks the affected URLs.

Keep a short record of what you changed and when. If the numbers move, you'll know why; if they don't, you won't repeat the same change.

Quick answers

Do Core Web Vitals affect Google rankings? Google uses page experience signals, including Core Web Vitals, as part of ranking, but relevant content matters more. Treat them as a tie-breaker and as a direct effect on conversions.

Why is my Lighthouse score good but Search Console says "poor"? Lighthouse is one simulated load on your setup; Search Console reflects real visitors on real devices and networks over 28 days.

Which metric should I fix first? The one marked "poor" on mobile, since that's where most AI-built apps struggle and where most visitors are.

Can I fix Core Web Vitals without leaving Lovable or Bolt? Many fixes (image sizes, dimensions, lazy loading, fewer scripts) can be prompted in the tool. Bundle splitting and prerendering usually need direct work in the code.

Want someone to look at it?

The free health check gives you an outside view of your app in a couple of minutes. If the problem goes deeper than images and scripts, our maintenance and support plans cover performance work along with ongoing fixes, or contact us and describe what you're seeing. Google's reference for the thresholds is the Web Vitals overview on web.dev.