Common Core Web Vitals Mistakes Developers Make (And How to Fix Them)

Most developers assume Core Web Vitals is a checklist you clear once and move on from. That assumption is the first mistake. Core Web Vitals is a field-measured, continuously evaluated signal that reflects real user sessions, not a score you earn in a lab and keep forever. A page that passes today can fail next month after a new hero image, a third-party tag, or a layout change ships without anyone re-checking the numbers.

What follows is a beginner-versus-advanced breakdown of the mistakes that show up most often across LCP, INP, and CLS. Each metric gets a look at the surface-level misinterpretation and the deeper implementation problem underneath it. The goal is not to list every possible cause, but to give you a mental model you can apply the next time a metric drifts out of the “good” range.

LCP: The Metric Most Often Misdiagnosed

Largest Contentful Paint measures when the largest visible element in the viewport finishes rendering. It is the metric most developers think they understand, and the one they most often fix in the wrong place.

Beginner mistake: optimizing the wrong element

A common starting assumption is that LCP is about total page weight or overall load time. In practice, LCP is about one specific element. If you optimize your JavaScript bundle by 40% but the LCP element is a late-discovered hero image, the metric barely moves.

How to fix it: Identify the LCP element first. In Chrome DevTools, run a Performance trace, look for the “LCP” marker in the timings track, and click it to see which node was selected. You can also query it programmatically:

new PerformanceObserver((entryList) => {
  const entries = entryList.getEntries();
  const lastEntry = entries[entries.length - 1];
  console.log('LCP candidate:', lastEntry.element, lastEntry.startTime);
}).observe({ type: 'largest-contentful-paint', buffered: true });

Once you know the element, the fix is usually one of three things: preload it, serve it in a modern format, or remove whatever is delaying its discovery in the HTML.

Advanced mistake: treating LCP as a single number

Advanced developers often know to optimize the LCP element but stop there. LCP is composed of four sub-parts, and each has a different fix:

• Time to First Byte (TTFB): server and network latency
• Resource load delay: time between TTFB and when the browser starts fetching the LCP resource
• Resource load time: how long the resource takes to download
• Element render delay: time between the resource finishing and the element painting

If your LCP is 3.5 seconds and 2.8 of those seconds are resource load delay, no amount of image compression will save you. The browser did not start fetching the image early enough. This is where <link rel="preload"> and fetchpriority="high" matter:

<link rel="preload" as="image" href="/hero.avif" fetchpriority="high">
<img src="/hero.avif" alt="Hero" width="1200" height="600">

Trade-off to watch: Preloading too many resources defeats the purpose. Each preload competes for bandwidth with everything else on the critical path. Preload the single LCP image, not every image above the fold. And do not preload images that are already discovered early in the HTML — you will double-fetch them in some browsers.

INP: The Metric Beginners Ignore and Advanced Developers Break

Interaction to Next Paint replaced First Input Delay in March 2024. It measures the latency of all user interactions across the page lifetime, not just the first one. This change caught a lot of teams off guard, because FID was trivially easy to pass and INP is not.

Beginner mistake: assuming a fast FID means INP is fine

FID only measured input delay up to the point the event handler started. INP measures the entire round trip: input delay, processing time, and presentation delay. A page with a 20ms FID can easily have a 400ms INP if an event handler does heavy synchronous work.

How to fix it: Long tasks are usually the culprit. Open the Performance panel, record an interaction, and look for tasks longer than 50ms on the main thread that overlap with the interaction window. Every one of those is a candidate.

Advanced mistake: breaking up work without yielding control

An advanced developer might split a long function into smaller chunks, which is the right instinct. But if those chunks run back-to-back in the same task, nothing improves — the main thread is still occupied end to end.

The correct approach uses scheduler.yield() or setTimeout to return control to the browser between chunks:

async function processAll(items) {
  for (const item of items) {
    processItem(item);
    if (navigator.scheduling?.isInputPending?.()) {
      await scheduler.yield();
    }
  }
}

isInputPending() lets you check whether a user interaction is queued before deciding to yield. This matters because yielding unnecessarily adds its own overhead. If no input is pending, keep working.

When NOT to do this: Do not apply yielding to work that must complete before the next paint anyway. If you are computing something that needs to be visible immediately, breaking it up just delays the paint. Yielding is for background work that has a deadline softer than “right now.”

CLS: The Metric That Rots Quietly

Cumulative Layout Shift measures unexpected movement of visible content. The beginner mistake is easy to describe and hard to catch, because CLS rarely shows up in local development — it shows up in production, on slow connections, with real content.

Beginner mistake: reserving space only for images

Setting width and height on <img> tags solves a large share of CLS problems. It does not solve all of them. Fonts swapping, ads injecting content, cookie banners sliding in from the top, and dynamically injected elements all contribute to CLS and none of them are fixed by image dimensions.

How to fix it: Use font-display: optional or swap with size-adjust on the fallback font to minimize layout shift during font loading. Reserve space for ad slots with explicit min-height. Avoid inserting content above the fold after initial render.

Advanced mistake: dismissing shifts from user-initiated actions

The CLS specification does not count layout shifts that occur within 500ms of a user interaction. This is usually a feature — it means clicking a “read more” button and having content expand does not count against you.

The mistake is assuming any movement after a click is forgiven. If a user clicks a button and your app takes 800ms to fetch data, then shifts the layout when the response arrives, that shift counts. The 500ms exclusion window has passed.

How to fix it: Show skeleton placeholders at the target size before the fetch resolves, so the content slots into an already-reserved layout. Or debounce the shift by rendering a spinner in place of the eventual content, keeping the container dimensions stable throughout.

Where Beginner and Advanced Intersect: Measurement Discipline

Both groups tend to make the same meta-mistake: they check Core Web Vitals in the wrong place.

Lighthouse is a lab tool. It runs on a simulated connection with simulated throttling. It is useful for catching regressions and comparing builds. It is not what Google uses to rank pages. Google uses field data from the Chrome User Experience Report (CrUX), which aggregates real sessions over a 28-day window.

That means:

• Lighthouse score of 100 does not guarantee a passing Core Web Vitals assessment in Search Console.
• Search Console field data is delayed by up to 28 days and is segmented by URL group, not individual URLs.
• Web Vitals extension in Chrome is field-flavored but per-session, so it can disagree with CrUX for low-traffic pages.

The practical rule: use Lighthouse to catch regressions before they ship, and use CrUX (via Search Console or the CrUX API) to know whether you are passing. If the two disagree, trust CrUX.

A Comparison at a Glance

None of these fixes are exotic. They are standard techniques that show up in the Chrome documentation and in the tooling itself. What separates teams that pass Core Web Vitals from teams that keep chasing the score is the discipline of measuring in the right place, diagnosing the right sub-part, and re-verifying after each ship. The metric will drift again. The question is whether your process catches it before your users do.