How Core Web Vitals (LCP and CLS) Directly Impact Google Ads Quality Score and Cost Per Click

Performance work loses budget arguments because it is framed as a technical virtue. "Improve Core Web Vitals" competes badly against "launch the new campaign." The framing changes completely once you connect it to the number performance marketers actually defend: cost per click.

Google Ads Quality Score has three components — expected click-through rate, ad relevance, and landing page experience. That last third is assessed partly on how your page performs and behaves, and Quality Score feeds directly into Ad Rank, which determines both whether you show and what you pay.

The mechanism, briefly

Ad Rank is roughly your bid multiplied by your quality signals plus contextual factors. Because the auction charges you based on what is required to beat the advertiser below you, a higher quality score means you can win the same position at a lower price — or a better position at the same price.

The practical consequence is the part worth internalising: two advertisers bidding identically on identical keywords pay different amounts, and the difference is largely quality. One of the few levers you fully control there is the landing page.

What to actually model

Rather than a generic multiplier, run the arithmetic on your own account. The structure:

Then model two effects separately, because they compound and people usually count only one:

1. The CPC effect. If improved landing page experience moves average CPC from ₹38 to ₹35, the same ₹4,00,000 buys 11,428 clicks instead of 10,526 — about 900 extra clicks a month for no additional spend.
2. The conversion effect. Faster pages convert better on mobile largely because fewer people leave before seeing anything. If conversion rate moves from 2.4% to 2.7%, that is roughly 308 conversions instead of 253 on the higher click volume.

In that illustration the combined effect is a 20%+ increase in conversions from the same budget. Your numbers will differ. The point is that the calculation is available to you and is far more persuasive internally than a Lighthouse score.

LCP: why the first paint decides the session

Largest Contentful Paint measures when the biggest above-the-fold element finishes rendering. Under 2.5 seconds is "good". On paid traffic it functions as a filter: a visitor who clicked an ad has low commitment and high alternatives, and a blank screen for four seconds on a mid-range Android on mobile data is where most of the loss happens.

The usual causes, in the order worth checking:

• An unoptimised hero image. A 2MB JPEG where a 180KB WebP would do. Almost always the single biggest win, and the cheapest.
• Render-blocking resources. Stylesheets and synchronous scripts in the head that delay the first paint. Defer anything not needed for above-the-fold rendering.
• Slow TTFB. If the server takes 1.5s to respond, you start the race 1.5s behind. This one is infrastructure, not front-end — see the TTFB and DNS guide.
• Client-side rendering. If the hero only exists after a JavaScript bundle executes, LCP includes the download and parse of that bundle.
• Web fonts blocking text. Without font-display: swap, text stays invisible while the font loads.

<!-- Preload the hero and mark it high priority -->
<link rel="preload" as="image" href="/hero-1200.webp"
      imagesrcset="/hero-600.webp 600w, /hero-1200.webp 1200w"
      imagesizes="100vw">

<img src="/hero-1200.webp"
     srcset="/hero-600.webp 600w, /hero-1200.webp 1200w"
     sizes="100vw"
     width="1200" height="630"
     fetchpriority="high" decoding="async" alt="">

The width and height attributes are not decoration — they reserve the space so the image cannot shift the layout when it arrives, which is the CLS half of the same problem.

CLS: the metric that costs you the click you paid for

Cumulative Layout Shift measures how much content moves during load. Under 0.1 is "good". On a landing page it maps to a specific, visible failure: the visitor reaches for the CTA, a banner loads above it, the button moves, and they tap the wrong thing. You paid for that click.

Four causes cover nearly all of it:

/* Reserve the space so nothing below can be pushed down */
.hero-media { aspect-ratio: 16 / 9; width: 100%; }
.promo-banner { min-height: 56px; }

@font-face {
  font-family: 'Inter';
  src: url(/fonts/inter.woff2) format('woff2');
  font-display: swap;
}

Measure the field, not your laptop

A lab test on a fast machine on office wifi will tell you the page is fine. Your traffic is not on that machine. Two rules:

• Use field data (CrUX) where you have enough traffic — it reflects real devices and real networks.
• When running lab tests, throttle to a mid-tier mobile CPU and a 4G profile. The gap between that and an unthrottled desktop run is routinely three to four seconds.

Also check the specific URLs you are sending paid traffic to. Site-wide averages hide the campaign landing page, which is frequently the heaviest page on the site because it was built fast by a different team.

How to sequence the work

Compress the hero image first. It is an afternoon of work, it usually moves LCP more than anything else, and a visible win makes the rest of the budget conversation easier. Then set explicit dimensions on every image — that is CLS mostly solved. Then defer non-critical scripts.

Only after that does it make sense to argue about rendering architecture or a CDN migration. Those are real projects with real risk, and you want the cheap wins banked and measured before you ask for them.

Set a baseline before you start, so the improvement is attributable. Run the audit, note LCP and CLS on the campaign URL, make the change, re-run. That before-and-after pair is what funds the next piece of performance work.