1. Definition of the first entry delay
  2. The cause of the first entry delay
  3. How to fix input latency
  4. Why browsers stop responding
  5. Don't lose sleep over third party code
  6. How JavaScript affects first entry delay
  7. Move and asynchronize attributes
  8. The input latency is different for all users
  9. Why Most FID Websites Fail
  10. It is now time to fix the initial entry delay

First Input Delay (FID) is a user experience metric introduced by Google that will soon be used as a small ranking factor. This article provides an easy-to-understand overview of FID to help you better understand the subject.

The first entry lag is more than trying to please Google. Improvements in website performance generally translate into higher sales, ad revenue, and leads.

Definition of the first entry delay

FID is the measurement of the time it takes a browser to respond to a website visitor's visitors first interaction with the site while the site is loading. This is sometimes referred to as input latency.

An interaction can be a tap of a button, a link, or a keystroke and the answer as an answer. Text entry areas, dropdowns, and check boxes are other types of interaction points that FID measures.


Read on below

Scrolling or zooming does not count as interactions as it does not expect a response from the site itself.

The goal of FID is to measure how responsive a website is when it loads.

The cause of the first entry delay

The first input delay is generally caused by images and scripts not downloading properly. This out of order coding causes the webpage download to be excessively paused, then started, and then paused. This causes website visitors who try to interact with the website to stop responding.

It's like a traffic jam caused by a free promotion for everyone where there are no traffic signals, resulting in accidents and slowdowns. In order to remedy this, order must be brought into circulation.

Google describes the cause of the input latency as follows:

"In general, input delay (aka input latency) occurs because the main thread of the browser is busy doing something else and therefore cannot (yet) respond to the user. A common reason for this is that the browser is parsing a large JavaScript file and executes that is loaded by your app. Event listeners cannot run during this time because the loaded JavaScript may be instructing to do something else. "


Read on below

How to fix input latency

Since the main cause of the first input delay is the disorganized download of scripts and images, the best way to fix the problem is to carefully fix the order in which these scripts and images appear in the browser for download.

The general solution to the FID problem is to use HTML attributes to control how scripts are downloaded, optimize images (HTML and images), and carefully omit unnecessary scripts. The goal is to optimize the download to avoid the typical pause and start downloading unorganized websites.

Why browsers stop responding

Browsers are software that perform tasks related to displaying a web page. The tasks are to download the code, images, fonts, style information, and scripts, execute (execute) the scripts, and build the web page according to the HTML instructions.

This process is known as rendering. The word "render" means "create," and that is exactly what a browser does, putting together 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 actions (in this case the many individual tasks that are performed to render a web page).

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

The main thread can be portrayed as a highway with cars symbolizing the images and scripts that are downloaded and executed when a person visits a website.

Some codes are big and slow. This causes the other tasks to stop and wait for the big and slow code to come off the highway (download and stop executing).

The goal is to code the web page to optimize which code is downloaded first when the code runs so that the web page downloads as quickly as possible.


Read on below

Don't lose sleep over third party code

When it comes to key web vitals, and first-time entry delay in particular, there is little code that can be done about it. However, this is likely to be the case with your competitors as well.

For example, if your business depends on Google AdSense (a big script that blocks renders), the problem is the same for your competitor. However, there are solutions like deferred loading with Google Ad Manager.

In some cases, doing the best you can can be enough as your competitors may not be able to get better results either.

In these cases, the best thing to do is to put your winnings where you can find them and not sweat the losses if you can't make a change.

How JavaScript affects first entry delay

JavaScript is like a little engine that makes things happen. When a name is entered on a form, JavaScript may be in place to ensure that both the first and last name are entered. When a button is pressed, there may be JavaScript to instruct the browser to generate a thank you message in a popup.


Read on below

The problem with JavaScript is that in addition to downloading it, it needs to be executed (executed). So these are two things that add to input latency.

If there is a large JavaScript file at the top of the page, that file will block the rest of the page below from rendering (visible and interactive) until the script is fully downloaded and executed.

This is known as blocking the page.

The obvious solution is to move these types of scripts from the top of the page and place them at the bottom of the page so they don't interfere with any other page elements that are waiting to be rendered.

However, this can be a problem if, for example, it is placed at the end of a very long web page. This is because after the large page loads and is ready to interact with the user, the browser continues to signal that it is being downloaded (as the large JavaScript file is left behind in the end). The page may download faster, but it hangs while waiting for the JavaScript to run.


Read on below

There is a solution for that!

Move and asynchronize attributes

The HTML defer and async attributes are like traffic signals that control the start and stop of the download and execution of JavaScript.

An HTML attribute is something that transforms an HTML element, much like expanding the element's purpose or behavior.

When you learn a skill, that skill becomes an attribute of who you are.

In this case, the defer and async attributes instruct the browser not to block HTML parsing while downloading. These attributes tell the browser to keep the main thread running while the JavaScript is being downloaded.

Asynchronous attribute

JavaScript files with the Async attribute are downloaded and executed as soon as they are downloaded. When execution begins, the JavaScript file blocks the main thread.

Usually the file blocks the main thread when the download begins. But not with the asynchronous (or delayed) attribute.


Read on below

This is known as an asynchronous download, in which the download is independent of the main thread and in parallel with it.

The asynchronous attribute is useful for third-party JavaScript files such as advertising and social sharing. These files do not matter in which order they are executed.

Move attribute

JavaScript files with the "defer" attribute are also downloaded asynchronously.

However, the deferred JavaScript file will not run until the entire page has been downloaded and rendered. Deferred scripts are also executed in the order in which they are on a web page.

Scripts with the defer attribute are useful for JavaScript files, which depends on which page elements are loaded and when the order in which they are executed matters.

In general, use the defer attribute for scripts that are not strictly necessary to render the page itself.

The input latency is different for all users

It is important to note that the first entry delay values ​​are variable and inconsistent. The results vary from visitor to visitor.


Read on below

The variance in ratings is inevitable as the rating depends on interactions that are specific to the person visiting a site.

Some visitors may be distracted and may not interact until a moment when all the assets are loaded and ready to interact.

This is how Google describes it:

“Not all users will interact with your website every time they visit. And not all interactions are relevant for FID …

In addition, some users 'first interactions are at bad times (when the main thread is busy for an extended period of time), and some users' first interactions are at good times (when the main thread is completely idle).

This means that some users have no FIDs, some users have low FIDs, and some users are likely to have high FIDs. "

Why Most FID Websites Fail

Unfortunately, many content management systems, topics, and plugins were not designed around this relatively new metric.
This is why so many publishers are dismayed to find that their websites fail the First Input Delay test.


Read on below

However, this is changing as the web software developer community responds to the needs of the publishing community for different coding standards.

And it's not that the software developers who make content management systems are to blame for producing products that don't match these metrics.

For example, WordPress fixed a flaw in the Gutenberg website editor that resulted in it performing less well than it could.

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

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

There are different types of blocks that look and behave differently. Each individual block has a corresponding style code (CSS), much of which is specific and unique to that individual block.


Read on below

The standard way to code these styles is to create a stylesheet that contains the styles that are unique to each block. This makes sense because you have one central place where all of the block-specific code is there.

The result is that on a page that could be made up of (say) twenty blocks, WordPress loads the styles for those blocks as well as any other blocks that are not in use.

Before Core Web Vitals (CWV), this was considered the standard way of packaging CSS.

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

This is not intended as a minor offense against the WordPress developers. You did a fantastic job.

This is just a reflection of how quickly changing standards can encounter a bottleneck in the software development phase before they are incorporated into the coding ecosystem.

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


Read on below

Gutenberg 10.1 Improved Performance

WordPress Gutenberg 10.1 introduced an improved method of loading the styles by loading only the styles needed and not the block styles that shouldn't be used.

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

It is now time to fix the initial entry delay

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

Until then, however, the publisher must take steps to improve the delay in initial input. Understanding is the first step.


Chrome User Experience Report

PageSpeed ​​Insights

Chrome Dev Tools Lighthouse

Google Search Console (Core Web Vitals Report)

Optimize the first entry delay

First entry delay

User-centric performance metrics

GitHub script to measure key web vitals


Please enter your comment!
Please enter your name here