Quick Summary

In this article, we look at how work with Core Web Vitals has changed in 2026: why Google replaced FID with the INP metric, which threshold values are now considered green, and which practical steps can help speed up a website’s response to user actions.

Who will find this article useful:

• SEO specialists and internet marketers who want to improve behavioral metrics and increase a website’s visibility in Google.
• Website owners and administrators who monitor loading speed, Core Web Vitals, and conversion rates.
• Developers responsible for frontend performance and JavaScript optimization.

Since 2021, Google has been rolling out the Page Experience update, which evaluates how user-friendly a page is. At its core is a set of Core Web Vitals metrics that describe the speed, stability, and responsiveness of the interface. In 2024–2026, the focus shifted from FID to the new INP metric, but the basic optimization principles have remained the same.

What matters is not only the overall page loading speed, but also how the key stages of that loading process perform. Core Web Vitals include the following metrics:

• layout stability while elements are loading — CLS.
• the rendering speed of the largest visible element on the page — LCP.
• interface responsiveness and the page’s reaction speed to interactions — first this was measured by FID, and since 2024 the main metric has become INP (Interaction to Next Paint).

In this material, we explain how FID and INP are connected, which thresholds matter in 2026, and what needs to be done to improve website responsiveness without losing search traffic.

What Are FID and INP in SEO (Core Web Vitals 2026)

FID, First Input Delay is a historical Core Web Vitals metric that described the delay in a page’s response to the user’s first action after load. It measured only the event processing delay, but not the time spent on the processing itself.

How quickly a page responds to a user’s first click or scroll affects their first impression of the site’s speed. If the needed section is already visible in the menu, but the browser takes a long time to react to the click, the user perceives the site as slow and is more likely to leave.

INP, Interaction to Next Paint is the new primary responsiveness metric in Core Web Vitals, which officially replaced FID in March 2024. Unlike FID, INP takes into account not just the first action, but almost all user interactions on the page and measures the full cycle: from the click to the next noticeable visual update.

For a user seeing the site for the first time, one small delay may not be critical. But when the interface regularly hesitates while clicking buttons, opening filters, or submitting forms, it directly reduces trust, conversion rates, and the site’s search rankings.

What FID and INP values are considered normal

For FID, it was historically considered that a good value was a delay of up to 100 milliseconds. Today, FID is no longer used as a primary ranking signal, and in Google Search Console reports it has been replaced by INP, but the principles remain similar: the lower the delay, the better.

Recommended Core Web Vitals 2026 thresholds for INP:

• INP < 200 ms — good, the page is considered responsive.
• INP 200–500 ms — needs improvement, users can already feel the interface is lagging.
• INP > 500 ms — poor, there is a high risk of losing traffic and conversions.

FAQ on FID, INP, and Core Web Vitals

Should you keep looking at FID in 2026?

No, in Google reports it is no longer a key metric. It is much more important to focus on INP, but all FID optimization approaches are still useful for improving responsiveness.

Does INP affect Google rankings?

Yes, INP is officially part of the Core Web Vitals set and is included in page quality evaluation through Page Experience, which can affect a site’s rankings.

If I improve INP, will other metrics improve too?

Often yes: optimizing JavaScript and reducing blocking tasks help not only INP, but also LCP, while careful interface work has a positive effect on CLS.

How to Optimize INP and FID for Core Web Vitals

The main cause of poor FID and INP scores is the difficulty of executing large amounts of JavaScript on the main thread. While the browser is busy with heavy scripts, it can’t respond quickly to clicks, scrolling, form input, and other user interactions.

Optimizing the parsing, compilation, and execution of JavaScript on a page directly reduces both FID and INP. The less code the browser has to execute, and the more often you free up the main thread, the faster the interface responds to user actions.

Let’s look at what you can do to optimize page responsiveness and improve Core Web Vitals metrics for INP and FID.

Reduce JavaScript Execution Time

By default, all JavaScript blocks rendering. When the browser encounters a script tag that references an external JavaScript file, it has to pause and process that JavaScript: load it, parse it, compile it, and execute it.

To minimize this delay, you need to set priorities: load first what the user needs right now. This is universal advice for optimizing all Core Web Vitals metrics — INP, LCP, and CLS.

Only critical scripts required for the page to function should be placed in the head section. Aim to minimize the amount of data that needs to be processed on the client side.

You can view unused JavaScript on the page in Chrome DevTools under the Coverage tab. Chrome DevTools can be opened with the shortcut Ctrl + Shift + I in Google Chrome.

Alternatively, you can use a free Website Speed Test tool. It will provide page load optimization recommendations, including a list of unused JavaScript and an estimate of the savings from removing it.

To reduce JavaScript processing time, split it into smaller chunks and use asynchronous loading — this is one of the fastest ways to improve both lab TBT and field INP.

Break up long tasks into smaller chunks

Any execution of a code fragment that blocks the browser’s main thread for 50 ms or more is considered a long task. These tasks can be split into smaller parts and loaded asynchronously, so that the necessary functions are loaded only right before they are used, while unnecessary ones are not loaded at all.

You can fetch a module on demand using JavaScript’s dynamic import syntax. It ensures that code not used for the initial page load is fetched only when needed.

import('module.js').then((module) => {
  // Do something with the module.
});

Most modern browsers support it.

Source: caniuse.com

This minimizes the amount of script that needs to be parsed and compiled, which means the page will load faster and respond to users more quickly.

Defer unused JavaScript

Any non-critical JavaScript, including third-party scripts, can be deferred using async or defer.

<script defer src="…"></script>
<script async src="…"></script>

Keep an eye on the size of loaded JavaScript libraries

The more JS code the browser has to process, the longer the main rendering thread will be blocked, and the greater the FID and INP delay will be.

Review the list of libraries that are set as a priority. For example, the popular JqueryUI library — jquery (90 KB) — is often prioritized, even though this is unnecessary if it is only needed to handle a single event. In some cases, it may not be needed at all if pure JS code would take just a couple of lines.

Optimize the execution of third-party scripts

Third-party tags and analytics tools can consume network resources and slow down the browser’s main thread. Prioritize them using exactly the same principle: load third-party code at the moment it is needed for the page to function, and do not interfere with key user scenarios.

Analytics counters, end-to-end analytics, and call-tracking scripts should not prevent users from accessing the page quickly. Check how third-party code is loaded and configure deferred, on-demand loading. For example, do not load elements from the lower part of the page immediately before the user has scrolled down to them.

If scripts are hosted on your own server, they will load faster — this is what self-hosted systems are for. In this case, the data will also be stored on your own servers.

If you use analytics only superficially, do not look at heatmaps, and do not set up virtual goals, then server-side analytics tools may be enough. In that case, there is no need to install scripts on the website. For example, there are tools like goAccess, awstats, analog, and webalizer. They take data from web server logs and do not worsen Core Web Vitals.

Use web workers

With web workers, you can write a script to run JavaScript in a separate background thread. This way, JS code processing will not delay the browser’s main thread or increase FID and INP. Other resources can also be loaded this way, for example, media content.

FAQ on INP and FID optimization

Where should I start if INP is red in the report?

Start by reducing the amount and priority of JavaScript: disable unused scripts, defer third-party counters, and break up long tasks. Then run the measurements again and refine the heaviest scenarios.

Do I need to rewrite the site using another framework to improve INP?

Not necessarily. It is often enough to clean up the existing code: optimize event handlers, review component rendering, and move heavy calculations into web workers.

Will caching help improve INP?

Indirectly, yes: good caching and a CDN reduce the load on the network and server, but the key factor in INP is still blocking tasks on the browser’s main thread.

How to Check Core Web Vitals, INP, and Website Loading Speed

The INP metric is based on real user data, so it can’t be simulated 100% accurately with lab tests alone. In lab conditions, the most convenient metric to look at is TBT — Total Blocking Time. These metrics measure different things, but improving TBT usually correlates with a lower INP.

You can view a site’s metrics in the Core Web Vitals report in Search Console. Since 2024, INP is displayed there, while FID is available only in historical data and is no longer used as a target metric.

INP values and other Core Web Vitals are also shown in PageSpeed Insights. For a detailed audit, it’s worth focusing on TBT and the recommendations related to heavy JavaScript tasks that prevent the interface from being responsive.

PR-CY offers an online Website Speed Test tool that uses the Google API. The tool shows how the site behaves at different stages of loading, analyzes how well the Core Web Vitals metrics perform (LCP, CLS, INP), and suggests what can be improved.

And if you want to monitor more than just speed, try Website Analysis. This service runs an online audit of SEO metrics, technical characteristics, mobile usability, and other parameters, finds errors on internal pages, and shows a graph of search engine rankings.

FAQ on checking website speed and Core Web Vitals

How often should you check a website’s Core Web Vitals?

At least once a month, and after any major site changes — immediately after release, so you can catch possible drops in INP, LCP, and CLS.

Is one tool enough to evaluate website speed?

It’s better to combine several: use both PageSpeed Insights and internal Search Console reports, along with independent services like PR-CY for more detailed diagnostics.

Should you focus only on green indicators?

No, it’s important to look at trends and real user scenarios. Even with green scores, there can still be bottlenecks in specific sections or on certain types of devices.