NEWS

First Input Delay – A Simple Explanation via @martinibuster

Published

4 years ago

March 13, 2021

First Input Delay (FID) is a user experience metric that Google introduced and will soon use as a small ranking factor. This article offers an easy to understand overview of FID in order to help make sense of the topic.

First input delay is more than trying to please Google. Improvements to site performance generally lead to increased sales, ad revenue and leads.

Definition of First Input Delay

FID is the measurement of the time it takes for a browser to respond to a site visitor’s first interaction with the site while the site is loading. This is sometimes called Input Latency.

An interaction can be tapping a button, a link or a key press and the response given in response. Text input areas, dropdowns, and checkboxes are other kinds of interaction points that FID will measure.

Continue Reading Below

Scrolling or zooming do not count as interactions because there’s no response expected from the site itself.

The goal for FID is to measure how responsive a site is while it’s loading.

The Cause of First Input Delay

First Input Delay is generally caused by images and scripts that download in a non-orderly manner. This disordered coding causes the web page download to excessively pause then start then pause. This causes unresponsive behavior for site visitors attempting to interact with the web page.

It’s like a traffic jam caused by a free for all where there are no traffic signals, which causes accidents and slowdowns. Fixing it is about bringing order to the traffic.

Google describes the cause of input latency like this:

“In general, input delay (a.k.a. input latency) happens because the browser’s main thread is busy doing something else, so it can’t (yet) respond to the user. One common reason this might happen is the browser is busy parsing and executing a large JavaScript file loaded by your app. While it’s doing that, it can’t run any event listeners because the JavaScript it’s loading might tell it to do something else.”

Continue Reading Below

How to Fix Input Latency

Since the root cause of First Input Delay is the disorganized download of scripts and images, the way to fix the problem is to thoughtfully bring order to how those scripts and images are presented to the browser for download.

Solving the problem of FID generally consists of using HTML attributes to control how scripts download, optimizing images (the HTML and the images) and thoughtfully omitting unnecessary scripts. The goal is to optimize what is downloaded to eliminate the typical pause and start download of unorganized web pages.

Why Browsers Become Unresponsive

Browsers are software that complete tasks to show a web page. The tasks consist of downloading code, images, fonts, style information and scripts and then running (executing) the scripts and building the web page according to the HTML instructions.

This process is called rendering. The word render means to make and that’s what a browser does by assembling the code and images to render a web page.

The individual rendering tasks are called threads. The word thread is short for “thread of execution” which means an individual sequence of action (in this case, the many individual tasks done to render a web page).

In a browser there is one thread that’s called a Main Thread. The main thread is responsible for creating (rendering) the web page that a site visitor sees.

The main thread can be visualized as a highway in which cars are symbolic of the images and scripts that are downloading and executing when a person visits a website.

Some code is large and slow. This causes the other tasks to stop and wait for the big and slow code to get off the highway (finish downloading and executing).

The goal is to code the web page in a manner that optimizes which code is downloaded first, when the code is executed, in an orderly manner so that the web page downloads in the fastest possible manner.

Continue Reading Below

Don’t Lose Sleep Over Third Party Code

When it comes to core web vitals and especially with First Input Delay, there is some code over which there is little that can be done. However, this is likely to be the case with your competitors as well.

For example, if your business depends on Google AdSense (a big render blocking script) the problem is going to be the same for your competitor.

In many cases, it may be enough to do the best you can because your competitors may not be able to do any better either.

So in those cases it’s best to take your wins where you can find them and don’t sweat the losses where you can’t make a change.

JavaScript Impact on First Input Delay

JavaScript is like a little engine that makes things happen. When a name is entered on a form, a JavaScript might be there to make sure both the first and last name is entered. When a button is pressed a JavaScript may be there to tell the browser to spawn a thank you message in a popup.

Continue Reading Below

The problem with JavaScript is that it not only has to download but it also has to run (execute). So those are two things that contribute to input latency.

If a big JavaScript file is located near the top of the page, then that file is going to block the rest of the page beneath it from rendering (becoming visible and interactive) until that script is finished downloading and executing.

This is called blocking the page.

The obvious solution is to relocate these kinds of scripts from the top of the page and put them at the bottom of the page so that they don’t interfere with all the other page elements that are waiting to render.

But this can be a problem if, for example, it’s placed at the end of a very long web page. The reason is because once the large page is loaded and the user is ready to interact with it, the browser will still be signalling that it is downloading (because the big JavaScript file is lagging at the end). The page may download faster but then stall while waiting for the JavaScript to execute.

Continue Reading Below

There’s a solution for that!

Defer and Async Attributes

The Defer and Async HTML attributes are like traffic signals that control the start and stop of how JavaScript downloads and executes.

An HTML attribute is something that transforms an HTML element, kind of like extending the purpose or behavior of the element.

It’s like if you learn a skill, that skill becomes an attribute of who you are.

In this case, the Defer and Async attributes changes the way a JavaScript file behaves.

One of the important changes is that they tell the browser to not pause for the JavaScript. These attributes tell the browser to keep the main thread going.

The JavaScript files will download and process independently of the main thread, allowing the browser to render the web page faster.

Async Attribute

JavaScript files with the Async attribute will download and then execute as soon as it is downloaded. When it begins to execute is the point at which the JavaScript file blocks the main thread.

Continue Reading Below

Normally the file would block the main thread when it begins to download. But not with the async attribute.

This is called an asynchronous download, where it downloads independently of the main thread and in parallel with it.

The async attribute is useful for third party JavaScript files like advertising and social sharing, files in which it doesn’t matter in what order they are executed.

Defer Attribute

JavaScript files with the “defer” attribute will also download asynchronously.

But the deferred JavaScript file will not execute until the entire page is downloaded and rendered. Deferred scripts also execute in the order in which they are located on a web page.

Scripts with the defer attribute are useful for JavaScript files that depend on page elements being loaded and when the order they are executed matter.

In general, use the defer attribute for scripts that aren’t essential to the rendering of the page itself.

Input Latency is Different For All Users

It’s important to be aware that First Input Delay scores are variable and inconsistent. The scores vary from visitor to visitor.

Continue Reading Below

The variance in scores is unavoidable because the score depends on interactions that are particular to the individual visiting a site.

Some visitors might be distracted and not interact until a moment where all the assets are loaded and ready to be interacted with.

This is how Google describes it:

“Not all users will interact with your site every time they visit. And not all interactions are relevant to FID…
In addition, some user’s first interactions will be at bad times (when the main thread is busy for an extended period of time), and some user’s first interactions will be at good times (when the main thread is completely idle).
This means some users will have no FID values, some users will have low FID values, and some users will probably have high FID values.”

Why Most Sites Fail FID

Unfortunately, many content management systems, themes and plugins were not built to comply with this relatively new metric.
This is the reason why so many publishers are dismayed to discover that their sites don’t pass the First Input Delay test.

Continue Reading Below

But that’s something that is changing as the web software development community responds to demands for different coding standards from the publishing community.

And it’s not that the software developers making content management systems are at fault for producing products that don’t measure up against these metrics.

For example, WordPress addressed a shortcoming in the Gutenberg website editor that was causing it to score less well than it could.

Gutenberg is a visual way to build sites using the interface or metaphor of blocks. There’s a widgets block, a contact form block and a footer block, etc.

So the process of creating a web page is more visual and done through the metaphor of building blocks, literally building a page with different blocks.

There are different kinds of blocks that look and behave in different ways. Each individual block has corresponding style code (CSS), with much of it being specific and unique to that individual block.

Continue Reading Below

The standard way of coding these styles is to create one style sheet containing the styles that are unique to each block. It makes sense to do it this way because you have a central location where all the code specific to blocks exists.

The result is that on a page that might consist of (let’s say) twenty blocks, WordPress would load the styles for those blocks plus all the other blocks that aren’t being used.

Before Core Web Vitals (CWV) that was considered as the standard way to package up CSS.

After the introduction of Core Web Vitals that practice is considered code bloat.

This is not meant as a slight against the WordPress developers. They did a fantastic job.

This is just a reflection of how rapidly changing standards can hit a bottleneck at the software development stage before being integrated within the coding ecosystem.

We went through the same thing with the transition to mobile first web design.

Continue Reading Below

Gutenberg 10.1 Improved Performance

WordPress Gutenberg 10.1 introduced an improved way to load the styles by only loading the styles that were needed and not loading the block styles that weren’t going to be used.

This is a huge win for WordPress, the publishers who rely on WordPress and of course the users who visit sites created with WordPress.

Time to Fix First Input Delay is Now

I believe that moving forward more and more software developers responsible for the CMS, themes and plugins will transition to First Input Delay-friendly coding practices.

But until that happens, the burden is on the publisher to take steps to improve First Input Delay. Understanding it is the first step.