Achieving a Perfect 100% Core Web Vitals Score: Our Success Story

How did chetaru.com reach a perfect Core Web Vitals score?

Chetaru.com reached a perfect Core Web Vitals result by methodically fixing the three metrics Google measures, after our score had spent a long time stuck between 95 and 99 on both mobile and desktop. Rather than accept the usual explanations, we audited every part of the site’s performance and made targeted improvements to loading, interactivity, and visual stability until we passed all three. This is the story of how we did it and why it was worth the effort.

Key Takeaways

• Our site sat at 95 to 99 for a long time; closing the last gap to a perfect pass took deliberate, metric-by-metric work.
• Core Web Vitals are three metrics: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS), with good thresholds of 2.5 seconds, 200 milliseconds, and 0.1 (web.dev).
• Note: in March 2024 Google replaced First Input Delay (FID) with INP as the responsiveness metric (web.dev).
• Passing Core Web Vitals supports rankings, user experience, and conversions, and it’s genuinely achievable.

Getting from “nearly there” to a clean pass is the hardest part of Core Web Vitals work, because the easy wins are already done and what remains is detail. Our experience was that the final improvements came from understanding our own site deeply rather than from any single quick fix. The rest of this post walks through what Core Web Vitals are, the specific changes we made for each metric, and what reaching a perfect result actually delivers.

What are Core Web Vitals?

Core Web Vitals are the three metrics Google uses to measure real-world page experience: how fast the main content loads, how quickly the page responds to interaction, and how visually stable it is as it loads. They’re measured at the 75th percentile of real users, and Google sets a “good” threshold for each (web.dev). Passing all three is what counts as a good Core Web Vitals assessment.

The three metrics are Largest Contentful Paint (LCP), which should be 2.5 seconds or less; Interaction to Next Paint (INP), which should be 200 milliseconds or less; and Cumulative Layout Shift (CLS), which should be 0.1 or less (web.dev). One important change to note: in March 2024, Google replaced the old First Input Delay (FID) metric with INP, which measures responsiveness across the whole visit rather than just the first interaction (web.dev). The work we describe below maps to these current metrics.

The reason these specific metrics matter is that they capture what actually frustrates users: waiting for content, tapping something that doesn’t respond, and watching the layout jump as it loads. Google’s core ranking systems are built to reward good page experience, so improving these metrics serves both your users and your search visibility. For a fuller primer, see our guide to Core Web Vitals and how to improve them.

What did we do to improve Largest Contentful Paint?

We improved Largest Contentful Paint, the time it takes for the largest visible element to load, by attacking what slows that element down: image weight and render-blocking resources. LCP is usually dominated by a large image or block of content above the fold, so getting it under the 2.5-second threshold meant making that content appear faster.

The specific changes we made were:

1. Modern image formats. We converted images to modern formats like WebP, which are far smaller than older formats at the same quality, so the largest image loads faster.
2. Lazy loading. We implemented lazy loading to delay loading offscreen images until they’re needed, so the browser isn’t held up fetching things the user can’t yet see.
3. Minified CSS. We minimised our CSS to speed up rendering, since bloated or render-blocking stylesheets delay when the main content can paint.

Together these cut the time to the largest contentful paint, which was a meaningful part of closing our gap to a perfect result. Image and CSS optimisation tends to be where the biggest LCP wins live, which is why we started there, and it overlaps heavily with general website speed optimization.

What did we do to improve interactivity (INP)?

We improved interactivity, now measured by Interaction to Next Paint (INP), by reducing the work the browser’s main thread had to do, so the page responded quickly when users interacted with it. At the time of this work the metric was called First Input Delay (FID); Google has since replaced it with INP, which measures responsiveness across the whole visit, but the fixes that helped then are the same ones that help INP now.

The changes we made were:

1. Deferring non-essential JavaScript. We reduced JavaScript execution time by deferring scripts that weren’t needed for the initial interaction, freeing the main thread to respond to the user.
2. Web workers. We used web workers to run suitable scripts in the background, off the main thread, so heavy work didn’t block the page from responding.
3. Faster server responses. We optimised backend processes to improve server response times, since a slow response delays everything that follows.

Interactivity problems almost always come down to too much JavaScript running at the wrong time, so cutting and deferring that work is the core of the fix. These changes made the site feel snappier to use, which is exactly what INP is designed to capture, and they remain the right approach under the newer metric.

What did we do to improve visual stability (CLS)?

We improved Cumulative Layout Shift, which measures how much the page unexpectedly moves as it loads, by removing the causes of those shifts. CLS frustrates users when a button or link jumps just as they go to tap it, usually because something loaded later and pushed the content down. Getting CLS under 0.1 meant reserving space for everything before it arrived.

The changes we made were:

1. Explicit size attributes. We ensured images and ads had defined dimensions, so the browser reserves the right space and content doesn’t jump when they load.
2. Reserved space for dynamic content. We added reserved space for elements like banners that load after the initial render, so they appear in a slot rather than shoving other content aside.
3. Better font loading. We improved our font loading practices to avoid the shift that happens when a custom font swaps in and changes text size or spacing.

Visual stability is often the most overlooked of the three metrics, but it’s also one of the most fixable once you know what causes the shifts. Reserving space for anything that loads late, images, ads, embeds, and fonts, is the heart of it, and it’s what took our CLS to where it needed to be.

Why does a perfect Core Web Vitals result matter?

A perfect Core Web Vitals result matters because the metrics measure real user experience, which feeds both search rankings and how people behave on your site. Passing all three isn’t a vanity badge; it reflects a site that loads fast, responds quickly, and stays stable, exactly the experience that keeps visitors engaged.

The benefits we’d point to are:

• Better search performance. Google’s core ranking systems are designed to reward good page experience, so strong Core Web Vitals support your visibility, alongside good content.
• Better user experience. Faster loads and smoother interactions keep people on the page longer and reduce the frustration that drives them away.
• More conversions. A smooth, fast experience makes visitors more likely to act, whether that’s enquiring, buying, or signing up, since friction and delay are conversion killers.

The wider lesson from our experience is that a perfect result is achievable, not just aspirational. The last few points from 95-99 to a clean pass took detailed, deliberate work, but the techniques are repeatable and the payoff, in experience and visibility, is real.