Google hasn't been sitting still. Both LCP and CLS have been seeing drastic changes already, so why not changing the FID metric?
You would almost think Google is trying to annoy us. However, both LCP and CLS changed for the good. Remember?
Google isn't doing this in an attempt to annoy us though. They're just trying getting a better idea of the impact on real user experience. As a result, it's now FID that will change into a more nuanced metric. Google even wrote an article covering the new responsiveness, asking for feedback on their approach.
Quick Introduction into FID
Not sure what FID actually is? FID means First Input Delay, measuring the delay between user interaction and when the browser was able to come back with feedback.
The demo below is illustrating this. Click on a button to cause a deliberate. Then, within that delay, try to click the checkbox.
Â
Nothing happens as the browser was too busy. This is illustrating the potential bottleneck of too much work on the browser's main thread. This could be caused by long JavaScript tasks or rendering work.
Future FID change "explained like I'm 5"
You might need to be a bit older than 5, or just really into user experience research. Nevertheless, without becoming too technical, the difference between the current and future FID metric seems to be as following:
Current FID metric
Currently, FID is tracking the time between user interaction and when the browser was idle enough to respond to the user interaction. But the FID metric might still be missing an important part of what is happening in the browser.
As a developer, we know that an ajax or fetch request in general will need to be done as well. For example to actually show new information on the screen, such as an alert after 'adding to cart' was pressed. But if adding to cart takes too long, then it will also take longer to show the alert message when it was done using a callback.
The duration for the visual change isn't part of the FID metric today.
Future responsiveness metric
In the near future, FID (or maybe having a new name by then) is more close to tracking the time between user interaction and when the first visual change happened. Often a change related to the last interaction.
Moreover, the current threshold of the good bucket is 100 milliseconds. In the future, this is more likely to depend on the type of user interaction, because users are having different expectations depending on different type of interactions:
- When typing, we expect letters to show up almost randomly (within 50ms) after each keystroke (keyup event);
- When pressing (tab or click) on a button or when dragging, 100ms still feels fast and is considered good enough.
Cumulative input delay
FID means First Input Delay. However, there often will be more user interactions than just the first one. So as a result, there also is a chance of other input delays. There were rumours that First Input Delay would change into Cumulative Input Delay.
With the above, this isn't the case anymore. However, next to the above, there is a chance that all interactions will be tracked, and that -just as CLS changed as well- the worst input delay of all input delays will be used for your Core Web Vitals status.
However, Google is still requesting feedback on their approach, so this could still change.
Expect Core Web Vitals numbers to drop
Do note though that as the thresholds themselvs won't become easier, but will include additional browser tasks, it is likely to result in regressed numbers. More websites, webshops and their pages could end up not passing this metric and thus not passing Core Web Vitals anymore.