The Core Web Vitals have become an important standard promoted by Google to evaluate the page experience under three metrics:
The CLS, the LCP, and the FID.
The First Input Delay, FID for its acronym in English, is the time it takes for the user to make the first interaction with the page and the time it takes for the browser to process it.
Google has spent years evaluating the loading speed of websites and the user experience they offer.
If we want our website to appear in the first results of Google.
We must also work on the Core Web Vitals as one more pillar of SEO.
Due to the increase in browsing on mobile devices, Google is very demanding with loading times.
If users quickly interact with the page.
It means that they are interested and willing to spend time visiting it.
What is the FID (First Input Delay)?
The FID (First Input Delay) is a metric that measures the time from when a user interacts with the page until it responds.
We have to remember that interaction is considered when a user clicks on an interactive element such as a button or a link.
Scrolling or zooming is not considered user input.
Getting this metric approved is not always easy.
We must try to keep it as low as possible or at least between 100 and 300 milliseconds.
A good FID should take less than 100 milliseconds:
- Good: FID less than 100ms
- Needs improvement: FID between 100 and 300 ms
- Bad: FID greater than 300 ms
Google’s measurement of the FID is based on weighting the metrics of real users using the Google Chrome browser.
Being a metric that depends on user interaction.
Bots cannot simulate clicks or real behavior for a laboratory test that we want to do with a measurement tool.
What Causes a High FID (First Input Delay)?
Having a slow FID is usually caused by the effect of JavaScript and/or CSS elements on the website.
In most cases, the content is visible.
It looks like everything has been loaded.
But the system is unable to respond to the user’s request because it is finishing downloading other DOM elements.
On many occasions, it is due to very heavy JavaScript code or many requests.
Let’s think about the loading of Tag Manager or Analytics, embedded videos, social network pixels, and measurement tools such as a heat map,…
These are requests that are included in the head of the web and if they are loaded at the beginning they will increase the FID time.
The FID is considered a first impression metric.
If a user arrives at our website, clicks on a link and the page takes time to respond.
We will be causing a bad impression and may leave our website.
In mobile browsing, speed is very important.
It depends both on the network and on the power of the device.
And, with the amount of information available, a user usually has little patience for a website to load.
Having a very good product or service is not enough if the page does not respond quickly to user demands.
Just as we do not like to wait in a physical establishment to be served.
We must prevent our web users from having to wait for the information that they have already requested to be displayed.
How to Measure the FID of a URL?
This metric can be measured through different tools.
The most recommended is the Chrome inspector to measure Core Web Vitals.
Which indicates the time it takes to make your first interaction and the value of this metric.
We must emphasize that it is a fielding metric.
When we talk about field data, we mean that we need real user metrics because Google can’t simulate user interaction.
The interactivity index only focuses on the delay or delay in the processing of events.
If we look at the following graph we will see the difference in requests from the main thread and how they are processed in the background.
We can measure the FID of a website with the following tools:
- Google Page Speed Insights.
- Chrome User Experience Report.
- With JavaScript and the API for timing events or with the web-vitals JavaScript library.
Tips to Improve the FID (First Input Delay) of Your Page
The Total Blocking Time (TBT) is the time in which the page is blocked by long page load processes.
Therefore, any optimization of the TBT (Total Blocking Time) will have an impact on an improvement of the FID.
Since they understand that they are correlated.
To optimize the FID it is necessary to improve the loading speed of the page and we can do it in the following way:
- Reducing the execution time of JavaScript and CSS.
- Reducing page requests to third-party code.
- Minimizes the work of the main thread.
- Fewer requests and less weight possible
When we need to improve the web speed of a website, optimizing JavaScript and CSS usually gives good results.
As a general measure, we remember that it is necessary to eliminate the unnecessary, minify the code as much as possible and compress it.
This way we will also improve the LCP (Largest Content Paintful), another of the Core Web Vitals.
If our website is in a CMS like WordPress.
We can make use of one of the numerous optimization plugins, which, when properly configured, can do much of the work of improving these metrics.
JavaScript Attributes to Improve Page Load Speed
- The “preload” attribute should be used to prioritize key web resources. So they will be available when the call event is fired.
- The “defer” attribute can be used to load external scripts (Youtube embedded videos, for example), as it sends a signal to the browser not to defer the loading of said script. This will load in the background allowing the DOM to be complete in less time.
- The “async” attribute shares with “defer” the property of making scripts non-blocking. It is used for completely independent scripts that are downloaded in parallel with the rest of the page and are executed after their download is complete.
- Prefetch to load resources early. It can be used for certain pages or resources that we have estimated the user will need later. For example, in a list of featured blog posts, if they have been preloaded, navigation will be very fast.
When we make changes, we will not see the result immediately in Google tools (the data is taken every 28 days).
We can test it in the Google Chrome browser, through the browser inspector option and the “Network” tab.
Once there, we will reload the page and we will have a list of all the elements that have been loaded.
We can search and lock a resource to test what impact that change would have.
From the Lighthouse tab, we can do the test before and after blocking the resources.
If we get the result we expected, we can ask the development team to block that item.
We hope this article has helped you understand one of the Core Web Vitals of your website.
And that you follow our advice for a faster website that better meets the needs of your users.
Thanks for Reading.