Core Web Vitals: What to Fix First on a Business Website

The three metrics, briefly

You do not need the documentation restated. You need enough to act.

Largest Contentful Paint (LCP) measures how long until the biggest visible element finishes rendering, usually a hero image or a headline. Good is under 2.5 seconds. Cumulative Layout Shift (CLS) measures how much the page jumps around while loading. Good is under 0.1. Interaction to Next Paint (INP) measures how long the page takes to visibly respond after a tap or click. Good is under 200 milliseconds.

One detail matters more than the definitions: all three thresholds are measured at the 75th percentile of real visits, not the average. Three quarters of your visitors have to pass. An average that looks fine can still fail.

Fix LCP first

LCP is where business sites fail, and it is the cheapest of the three to repair.

There are three usual causes and each has a distinctive signature. Oversized images show up as a large LCP element with a huge transfer size in the report. Render-blocking resources show up as a long gap between the page responding and anything painting, usually stylesheets or scripts in the head. Slow server response shows up as a high time to first byte before anything else has even started.

The reason to start here is not just that it is common. It is that these causes are shared. An unoptimized hero image hurts LCP and then causes a layout shift when it finally lands. A render-blocking script delays paint and adds main-thread work that hurts interaction. Fix LCP properly and the other two metrics often improve without being touched.

Our own worst page was a 3.5 MB about page

In June 2026 we ran a technical audit of this site. The finding that mattered was not on the homepage, which we had been watching. It was /about.

Three team photos were being served as unoptimized PNGs at roughly 1.2 MB each, about 3.5 MB total, displayed at 380 by 475 pixels. We estimated that page in the 40 to 55 range for performance against roughly 70 to 80 for the homepage. Those were estimates derived from reading the code, not measured Lighthouse runs, and the audit said so explicitly, because a number you cannot reproduce is not evidence.

The fix was migrating those images to Astro's asset pipeline, which emits WebP and AVIF at multiple densities at build time, and correcting the loading attributes so the LCP image is not lazy-loaded. One root cause, five separate audit findings closed. The lesson generalizes: on business sites the single largest performance win is almost always images that nobody optimized because the page looked fine on the designer's laptop.

CLS is second, and it is nearly always the same bug

Cumulative Layout Shift has a reputation for being mysterious. In practice, on a business site, it is one of two things.

Elements inserted without reserved space. An image without width and height attributes, an ad slot, an embedded video, a cookie banner. The browser lays out the page, the element arrives, everything below it jumps. The fix is to reserve the space up front with explicit dimensions or an aspect ratio.

Fonts swapping late. Your text renders in a fallback font, then the real font arrives with different metrics and the text reflows. Preloading the font used by your LCP element removes the visible swap, and it is usually a two-line change.

INP is last, and often not your code

Most business sites pass INP without doing anything, because most business sites are not applications. There is not much to interact with.

When one does fail, the cause is usually a third-party script rather than your own JavaScript: a chat widget, a tag manager loading half a dozen tags, a heatmap recorder, a marketing pixel. Each one runs on the same main thread that has to respond to your visitor's tap.

This is worth saying plainly because INP failures often trigger a rewrite of application code that was never the problem. Check what third parties you load before you refactor anything.

Field data and lab data disagree on purpose

This is the confusion that wastes the most time, so it is worth being precise.

A green Lighthouse score with a failing Search Console report is not a contradiction. It usually means your visitors are on slower devices or networks than your test machine, or that a template you rarely open yourself is dragging the aggregate down. Use Lighthouse to debug a change; use field data to decide whether you have a problem.

Where this meets AI search

Performance is not a separate project from being cited by AI assistants.

Crawlers work on time and resource budgets. A page that is slow to respond gets fetched less often and less completely, and a page whose content only appears after JavaScript runs may not be read at all, because most AI crawlers do not render. If you want to check that specific failure mode, we wrote a walkthrough of the four checks that decide whether ChatGPT can read your site.

That is the argument for treating the build layer and search as one discipline rather than two budgets. The same fixes serve both.

Keeping it fixed

A one-time optimization pass decays. Someone adds a hero video, a marketing tool gets installed, an image goes up at full resolution because the CMS accepted it.

The durable version is a budget enforced automatically before code ships, so a regression fails the build rather than surfacing in Search Console a month later. That is what we do on every web build, and it is the reason this site's own regression showed up in an audit we ran on ourselves rather than in a client complaint.

If you want to know where your site stands right now, start with the field data in Search Console rather than a Lighthouse run. It is the number Google is actually using.