Google keeps tinkering with these metrics, and this year they’ve rolled out some major changes every self-respecting web dev should know by heart.

The biggest update? First Input Delay (FID) is gone, replaced by something called Interaction to Next Paint (INP). Sounds complicated? Don’t worry—I’ll break it all down and show you how to optimize your site so it runs like a Swiss watch.

What Changed in Core Web Vitals in 2025?

Bye FID, Hello INP

On March 12, 2024, Google officially tossed FID in the trash and swapped it for INP. In 2025, this change is now everywhere - FID is ancient history.

Why did we say goodbye to FID?

• FID only measured the very first click or tap from a user—everything after that didn’t count.

• INP looks at ALL interactions during the whole visit.

• INP gives a much better sense of how frustrating (or smooth) your site feels for real users.

New Metric on the Horizon: Engagement Reliability

Google’s also testing a new metric - Engagement Reliability Score (ER). It’s still experimental, but worth keeping an eye on. ER checks how often users can click around and use your site without running into annoying issues.

The Three Pillars of Core Web Vitals

1. Largest Contentful Paint (LCP) – “When does something actually show up?”

LCP measures how long it takes for the biggest thing on your page (usually a big hero image or a chunky block of text) to fully render.

How to read it:

• Awesome: up to 2.5 seconds 😎

• Needs work: 2.5 to 4 seconds 🤨

• Nightmare: over 4 seconds 😫

Example of LCP-friendly code:

<!-- Hero image with the right attributes -->
<img src="hero-image.webp"
    width="1200"
    height="600"
    fetchpriority="high"
    loading="eager"
    alt="Main hero image">

<link rel="preload" href="hero-image.webp" as="image">
<link rel="preload" href="main-font.woff2" as="font" type="font/woff2" crossorigin>

How to boost your LCP:

1. Optimize your images:

Use tools like TinyPNG or Squoosh, to shrink your images without killing quality. For images that need to show up right away (like your hero image), always use the HTML attribute fetchpriority="high". This tells the browser to grab this image first, and it can cut load times by up to 55%!

2. Lazy load stuff you don’t need immediately:

Lazy loading means images below the fold only load when the user scrolls down. This saves bandwidth and helps the important stuff appear faster. Most browsers support native lazy loading now.

These days, implementing the lazy loading for the images is simple and handled natively by most popular browsers. see the article on MDN that covers exactly this matter.

3. Time To First Byte optimization, or fast server and good cache:

The faster the server response and resource transfer from it, the better loading times and the better LCP.

Use CDN to serve content from your site - there are several services on the market offering free services in this area. Personally, I use Cloudflare, which I use to manage my domains and simultaneously as a proxy with enabled CDN. Thanks to this, resources from my sites automatically land on edge servers, from where they reach users via the shortest route.

mong other free options, there are still Amazon CloudFront and jsDelivr to choose from. Unfortunately, I don't know more, but that doesn't mean they don't exist - if you're currently looking for something for yourself, it's worth looking around. ☺️

4. Fonts that don't block rendering

If we use custom fonts on our site, it's worth adding this line to our CSS declaring their source:

@font-face {
    ...
    font-display: swap;
}

Thanks to this, fonts that load a bit later won't block the rendering of text blocks.

2. Interaction to Next Paint (INP) - how fast something changes when you click

INP looks at how long you have to wait after a user performs an interaction until something in the page's appearance changes. And not just on the first interaction, but every one.

How to evaluate results:

• Great: up to 200 ms 😎

• Average: between 201 and 500 ms 🤨

• Tragedy: over 500 ms 😫

How to improve INP

1. Eliminate time-consuming tasks from the main thread

Take advantage of the benefits of creating asynchronous code in JavaScript to delegate time- and resource-consuming tasks to the asynchronous microtask queue in the Event Loop (I described this more broadly in the post about Event Loop).

Bad:

// ❌ Long task blocking the main thread
function processLargeArray(items) {
    for (let i = 0; i < items.length; i++) {
        // Heavy operations
        processItem(items[i]);
    }
}

Dobrze:

// ✅ Split into smaller tasks:
// each iteration pushed to the microtask queue
async function processLargeArrayOptimized(items) {
    const batchSize = 50;
    for (let i = 0; i < items.length; i += batchSize) {
        const batch = items.slice(i, i + batchSize);  // Process batch
        batch.forEach(item => processItem(item));  // Give control back to the browser
        await new Promise(resolve => setTimeout(resolve, 0));
    }
}

2. Use debounce and throttling techniques

Debounce and throttling are techniques known since the dawn of time for delaying action execution after interaction.

Debouncing involves delaying action execution until the user finishes performing many interactions quickly and in a row. For example: when a user types a phrase in a text field with suggestions, we don't bombard the database with queries after every key press. Instead, we execute the query calmly when they finish typing the phrase, for example after 300 milliseconds from pressing the last key.

Debouncing is easy to implement yourself, but we can use ready implementations e.g. in the lodash library:

const searchInput = document.getElementById('search');
const debouncedSearch = debounce(searchInDatabase, 300);
searchInput.addEventListener('input', debouncedSearch);

Throttling, on the other hand, is a technique that "lets through" interactions only once per X time. Imagine a gate that opens and lets through one ball per second, stopping all the rest - only in the next second will the next ball be let through.

Throttling is worth using if we introduce interactions related to scrolling, mouse movement, window or viewport size changes on our site. Then we can limit code execution e.g. once per 16 milliseconds (which equals 60 frames per second - a commonly accepted value ensuring smooth animations and interactions).

The throttle function is also available in the lodash library, similar to debounce:

// console.log will execute ONLY once per 100 ms,
// regardless of how long the user scrolls
const throttledScroll = throttle(
    () => {
        console.log('Scroll position:', window.scrollY);
    },
    100
);
window.addEventListener('scroll', throttledScroll);

These techniques are the basis of performance optimization - they help avoid unnecessary function calls and improve page reactions to user actions.

3. Cumulative Layout Shift - so the page doesn't jump and break your legs

CLS measures how much page elements move around the screen during loading. You've surely tried to click some button on a page - for example the X on an annoying ad - only for the entire ad to move a few pixels down a fraction of a second before clicking? That's exactly because of bad CLS.

How to evaluate:

• Great: below 0.1 😎

• Average: between 0.1 and 0.25 🤨

• Tragedy: over 0.25 😫

Stable image loading

To prevent elements from "jumping" on the page, our images should always have clearly defined dimensions in HTML code, even before they start loading. Popular CMS provide dimension information for the frontend, along with its URL.

Bad:

<!-- image will initially take zero pixels width,
    will cause "jump" after loading -->
<img src="image.jpg"  alt="Opis" />

Dobrze:

<!-- clearly defined dimensions and optionally aspect ratio -->
<img src="image.jpg"
     width="400"
     height="300"
     style="aspect-ratio: 4/3;"
     alt="Opis obrazu" />

Stable font loading

Here we act exactly like with LCP optimization in point 1. above.

Core Web Vitals Testing Tools

Google PageSpeed Insights

This is your main friend when it comes to measuring CWV - it measures and shows real data (based on real user experiences) and lab data (from own tests). Best for general assessment of our site's performance.

Google Lighthouse

Fastest in daily use because it's built into Chrome DevTools. Great for debugging while coding the page. Shows only raw lab data, but you can test live.

Google Search Console

Measures and shows data from the last 28 days from real users. Data from this tool is most important when we're perfecting our SEO, because this is exactly the data Google takes into account in its page ranking.

Why do results differ between tools?

It's normal that different tools show different results. This happens because of:

• Different test servers located in different places on Earth - one in America, another in Europe, a third somewhere in Asia.

• Different power of test devices - tools can test on real computers and phones, or simulated and virtual ones.

• Different versions of Chrome and Lighthouse.

As users and clients of these platforms, we can safely assume that their provider does everything to make our results reliable and as close to reality as possible. Test results between tools may differ, but they will probably never be dramatic differences.

Core Web Vitals Impact on Business - Specific Numbers

Impact on conversions

Research doesn't lie - Core Web Vitals have a completely real impact on the results of our products and websites:

• Pages that load faster have 60% more page views and 35% lower bounce rate - a metric checking what percentage of users leave the site before thoroughly familiarizing themselves with the offer.

• 53% of users flee from the site if it loads longer than 3 seconds.

• Increasing page or application response delay by 100-400 milliseconds decreases the number of searches by 0.2-0.6%.

Success example - numbers speak for themselves

SiteCare company conducted a comprehensive Core Web Vitals optimization project for a WordPress website of one of their clients - a non-profit foundation working for early childhood education, whose priority was key user and financial indicators. Below are details of actions and measurable effects.

Initial state and problem diagnosis

Before starting work (February-March 2023), Core Web Vitals indicators looked as follows:

• LCP - 4.6s (2.1s above the "Great" threshold),

• FID - 420ms (320ms above threshold)

• CLS - 0.08 (within normal range)

• INP - 230 ms (threshold exceeded)

Additional performance metrics:

• TBT (Total Blocking Time, total page rendering blocking time): 7.3 s

• Page size: 5.33 MB (including 3 MB of JS code alone)

• Fully Loaded Time: 28.9 s

Optimization plan

The SiteCare team implemented a set of technical actions:

• Removed JS code blocking rendering (plugin replacement, Google Tag Manager cleanup),

• Optimized DNS and early loading and resource loading order,

• Introduced CSS and JS code minification and bundling,

• Implemented local font hosting with fallbacks,

• Used WebP format images and optimized them through Cloudflare Polish & Mirage,

• Removed unnecessary third-party scripts,

• Migrated to lighter plugin versions (HelloBar, ConvertPro instead of SUMO).

Core Web Vitals results after optimization

After implementing optimizations in the period from June to October 2023, new Core Web Vitals results were measured and reported:

• LCP: 2.3 ms ✅

• FID: 57 ms ✅

• INP: 133 ms ✅

• CLS: 0 ‼️ ✅

• Total Blocking Time: 0.3 s (7 seconds drop‼️)

• Fully Loaded Time: 3.4 s (improvement by 1000%!)

• Downloaded files size: 602 KB (improvement by 800%!)

Google Search Console automatically validated all client site URLs as "Good" from September 8, both on computers and mobile devices.

Traffic and engagement growth

Comparison of results six months before and six months after CWV optimization:

• Users (sessions):

  • February-June 2023: 645 thousand

  • June-October 2023: 820 thousand (+27.1%)

• Search impressions:

  • February-June 2023: 28.2 million

  • June-October 2023: 36.6 million (+29.8%)

• Search clicks:

  • February-June 2023: 513 thousand

  • June-October 2023: 628 thousand (+22.4%)

Business conversion effect

Restored site performance translated directly into increased traffic and donations. Thanks to increased traffic and better CWV indicators, foundation partners noted an increase in the number and value of donations, meeting financial forecasts, and the client confirmed that thanks to SiteCare's work, their communication with donors regained effectiveness.

The result of comprehensive optimization was restoring the site to a leadership position in search results, and traffic statistics growth reached as much as 25%.

Mobile vs Desktop - Different Approaches

What to pay attention to with mobile devices?

When optimizing for mobile devices, remember certain details:

• Google treats mobile and desktop as separate entities

• Phones typically have less power than computers (processor, memory, internet)

• Touch-supporting UI elements are crucial

• CLS on mobile is often worse by about 10 percentage points than on desktops

Desktop optimization:

• Larger screens and resolutions may require using larger images (and heavier = greater impact on LCP)

• ...but at the same time, provide more system resources and simply faster hardware

• Different user behaviors wanting to perform multiple tasks simultaneously, which isn't always possible on phones

• Greater internet connection stability

Most Common Optimization Mistakes

1. Only considering Lighthouse results

Many teams focus only on Lighthouse results, ignoring real user experiences. We can read more appropriate results in Search Console.

2. Optimizing only for desktop

Google uses a mobile-first approach to evaluate how to assess and index a given page on the Internet, so the mobile version must be the priority.

3. Lack of space reservation for dynamic elements

The already mentioned technique of giving images specific width and height values in advance will help here, instead of relying on loading. We can do the same with text blocks - if we know roughly how much space they'll take, during loading we can use so-called skeletons, which are (often animated) placeholders that can partially prevent content shifting and affecting LCP, and also let the user know what they can expect in a specific place on the page. The possibility of optimizing performance and CWV results, while simultaneously improving user experience - that's something it would be a sin not to use.

4. Inappropriate use of lazy loading

We should use lazy loading techniques exclusively for below the fold content - that is, content the user will see only after intentionally scrolling down. Using it for above the fold content, i.e., the first part of the page they'll see right after loading, can unnecessarily delay its loading and rendering, ultimately negatively affecting CWV metrics.

5. Too many third-party scripts

If we must use scripts from outside - let's make sure we load them using lazy loading and delay their loading wherever possible. Thanks to this we'll avoid their impact on rendering and downloading page files.

Core Web Vitals Optimization Checklist

LCP optimization

• Optimize the largest element (image or text) within the viewport.

• Use the fetchpriority="high" attribute for the most important images that should be visible immediately after initial page loading.

• Implement preloading for key resources.

• Optimize server (TTFB below 600 ms).

• Use CDN for static resources (images, scripts, HTML files).

• Minify CSS and JS.

• Remove unused code.

INP

• Divide long JS tasks and delegate the most complex ones to asynchronous tasks.

• Use debounce/throttling.

• Use code splitting and lazy loading of resources that aren't needed immediately.

• Move heavy operations and calculations to Web Workers.

CLS

• Remember to set image and video element dimensions in advance, don't rely on dynamic adjustment.

• Reserve specific places with predetermined space for ads.

• Use font-display: swap.

• Don't inject content above existing elements.

• Test CSS animations.

• Use skeletons to reserve space for text and other elements.

Monitoring

• Configure Google Search Console and use it to test Core Web Vitals in production.

• Regularly test PageSpeed Insights.

• Implement Real User Monitoring.

• Test on real devices, not just simulated modes in browser on computer.

Summary

Core Web Vitals in 2025 aren't some fad. It's the absolute foundation of successful Internet activities. Replacing FID with INP means that now Google takes into account the entire duration of a user's visit to the site, not just the initial few dozen seconds during first loading and rendering.

The key to success? Optimize all three most important metrics, remember the differences between mobile and desktop, monitor continuously and avoid typical mistakes.

Companies that seriously approach CWV gain an advantage not only in Google, but also in users' hearts and their business results. A fast site means satisfied users, and satisfied users mean more cash flowing into pockets.