Core Web Vitals – Improve First Input Delay (FID)

Have you ever clicked a page and nothing happens? It’s very frustrating!

While Largest Contentful Paint (LCP) measures how long it takes content to render on a page, First Input Delay (FID) measures how quickly a page reacts to a visitor interacting with it. As one of three Google Core Web Vitals, achieving a reasonable score for this performance metric is critical.

Google considers any FID above 300 milliseconds (ms) to be poor, between 100ms and 300ms needs improvement, and less than 100ms is good.

Measuring FID and Its Alternative

First Input Delay is a field metric which means it can’t be simulated — real user interaction is required to measure response delay. You can use PageSpeed Insights to determine FID if the page has enough data over the previous 28 days. Likewise with Chrome User Experience Report and Google Search Console.

But any changes you make won’t be immediately reflected in your FID score. For that, we need to turn to a different, yet similar, metric called Total Blocking Time (TBT).

Like FID, it also measures unresponsiveness, but without user input. It just adds up the blocking time for all Long Tasks. Those are tasks running on the main thread for over 50 milliseconds.

So, you can make changes and see the effect based on field data. Just remember that field data is a historical report on how a particular URL has performed using a multitude of devices under varying network conditions. Lab data, on the other hand, simulates page load on one device under a fixed set of network conditions.

The #1 Factor Affecting FID

Heavy JavaScript execution is the #1 cause of poor FID score. The time required for a web browser to load and execute the main thread prolongs the time it takes to respond to any interaction.

Reduce JavaScript Execution Time

Technically, all JavaScript is render-blocking. Every time a browser sees a script tag, it needs to stop what it’s doing and download, parse, compile and execute that JavaScript. No wonder why bad coding results in a poor FID score!

You can see how much JavaScript isn’t being used on a web page through the coverage tab in Chrome DevTools. Just right-click on a page and select Inspect.

You can reduce JavaScript execution time by:

• Code-splitting
• Deferring JavaScript
• Removing unused JavaScript
• Delaying JavaScript execution
• Minifying JavaScript with WordPress Plugins like Asset CleanUp, or Fast Velocity Minify

Code-splitting

You can split one large JavaScript bundle into smaller chunks of code for lazy loading. I’ll talk more about this in a later section on breaking up long tasks, since it’s essentially the same process.

Deferring JavaScript

Deferring JavaScript ensures that the most important content is rendered so that a visitor can quickly interact with the page. WordPress plugins like Asset CleanUp, Hummingbird, or WP Rocket can help.

Removing unused JavaScript

A site or plugin should only load JavaScript when needed, but that’s not always the case. If you can’t change your site theme or plugin, then a WordPress plugin like Asset Cleanup or Perfmatters can help. I know, the irony of using one plugin to solve the problems of another isn’t lost on me!

Delaying JavaScript execution

Prioritizing resources required for interaction and delaying the rest helps improve your FID score. Not every JavaScript file can be handled in this manner, in cases where you can do it — delaying execution affects load time and ultimately time to interaction. There’s simply less code to get in the way, so to speak. Consider using a WordPress plugin like FlyingScripts or WP Rocket.

Minifying JavaScript

JavaScript files can contain comments, spaces, and line breaks — all things that make it easier for humans to read, but are totally unnecessary for machines. Removing these can make the file smaller and reduce load time. Most WordPress caching plugins allow you to minify JavaScript, making a tedious and rather complex problem simple. Just know that minifying your JavaScript files won’t have a dramatic impact.

Optimize Your Page for Interaction Readiness

If your page relies heavily on JavaScript, script execution and data-fetching can impact how quickly a page is ready to interact. Javascript analytics and other third-party scripts can also delay interaction latency. Ideally, you should prioritize loading the most valuable scripts first, delaying those that aren’t as important.

In the above example, third-party scripts block the main thread for 1.46 seconds.

Break up Long Tasks

Long Tasks result in periods where a visitor may find your site to be unresponsive. That’s because the browser is busy executing the JavaScript code. Long Tasks, which are over 50 milliseconds long, may indicate JavaScript bloat because of the need to load and execute time-consuming code.

JavaScript bundlers like Rollup and Webpack can help split code into appropriate files so that smaller pieces are loaded and executed as necessary. Unless you have development experience, this will be outside your realm.

Additional Ways of Reducing FID

Let’s briefly look at two other ways of improving web performance:

• Minimizing unused polyfills
• Using a web worker

I’ll mention them for the sake of completeness, but they’re really best used by those with some development skills.

Code that uses modern JavaScript syntax or uses current web browser APIs needs to be transpiling and the inclusion of polyfills. To minimize file size and thus load time, it’s best to limit unused polyfills and employ them only where necessary.

Takeaway

A well-optimized site should have a TBT of less than 100ms. Since fixing FID can require the assistance of a developer, the best strategy is to avoid getting into that situation in the first place. If you’re looking for a new WordPress theme, analyze it using any web page tester that provides Total Blocking Time. Likewise,when testing a WordPress plugin, check your TBT before and after installing the plugin.

Some WordPress plugins can help improve TBT (and thus FID) by deferring, delaying, or removing unused JavaScript. Other approaches are available, but they require the assistance of a developer.