First Input Delay (FID) is a user experience metric that Google uses as a small ranking factor.
This article offers an easy-to-understand overview of FID 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.
What is 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 keypress, and the subsequent response. Text input areas, dropdowns, and checkboxes are other kinds of interaction points that FID will measure.
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. 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.”
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 downloading 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, short for “thread of execution.” This 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 called the Main Thread and it 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 and when the code is executed, in an orderly manner, so that the web page downloads in the fastest possible manner.
Don’t Lose Sleep Over Third-Party Code
When it comes to Core Web Vitals and especially with First Input Delay, you’ll find there is some code over you just can’t do much about. However, this is likely to be the case for 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. Solutions like lazy loading using Google Ad Manager can help.
In some cases, it may be enough to do the best you can because your competitors may not do any better either.
In those cases, it’s best to take your wins where you can find them. 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, JavaScript might be there to make sure both the first and last name is entered.
When a button is pressed, JavaScript may be there to tell the browser to spawn a thank you message in a popup.
The problem with JavaScript is that it not only has to download but 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, 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 so 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.
This is because once the large page is loaded and the user is ready to interact with it, the browser will still be signaling 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.
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 when you learn a skill; that skill becomes an attribute of who you are.
In this case, the Defer and Async attributes tell the browser to not block HTML parsing while downloading. These attributes tell the browser to keep the main thread going while the JavaScript is downloading.
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.
Normally, the file would block the main thread when it begins to download. But not with the async (or defer) 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 where the order of execution doesn’t matter.
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.
This 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 users’ 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.
But that’s 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 a corresponding style code (CSS), with much of it being specific and unique to that individual block.
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 the standard way to package up CSS.
Since 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 into the coding ecosystem.
We went through the same thing with the transition to mobile-first web design.
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
Moving forward, we can expect that 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.
Citations
Google Search Console (Core Web Vitals report)
