Connect with us

NEWS

First Input Delay – A Simple Explanation via @martinibuster

Published

on

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.

Advertisement

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.

Advertisement

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.”

Advertisement

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.

Advertisement

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.

Advertisement

Continue Reading Below

Advertisement

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.

Advertisement

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.

Advertisement

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.

Advertisement

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.

Advertisement

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.

Advertisement

Continue Reading Below

Advertisement

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.

Advertisement

Advertisement

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.

Advertisement

Advertisement

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.

Advertisement

Advertisement

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.

Advertisement

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

Advertisement

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.

Citations

Chrome User Experience Report

Advertisement

PageSpeed Insights

Chrome Dev Tools Lighthouse

Google Search Console (Core Web Vitals report)

Optimize First Input Delay

First Input Delay

User-centric Performance Metrics

GitHub Script for Measuring Core Web Vitals

Searchenginejournal.com

Advertisement

NEWS

Google December Product Reviews Update Affects More Than English Language Sites? via @sejournal, @martinibuster

Published

on

Google’s Product Reviews update was announced to be rolling out to the English language. No mention was made as to if or when it would roll out to other languages. Mueller answered a question as to whether it is rolling out to other languages.

Google December 2021 Product Reviews Update

On December 1, 2021, Google announced on Twitter that a Product Review update would be rolling out that would focus on English language web pages.

The focus of the update was for improving the quality of reviews shown in Google search, specifically targeting review sites.

A Googler tweeted a description of the kinds of sites that would be targeted for demotion in the search rankings:

“Mainly relevant to sites that post articles reviewing products.

Think of sites like “best TVs under $200″.com.

Goal is to improve the quality and usefulness of reviews we show users.”

Advertisement

Advertisement

Continue Reading Below

Google also published a blog post with more guidance on the product review update that introduced two new best practices that Google’s algorithm would be looking for.

The first best practice was a requirement of evidence that a product was actually handled and reviewed.

The second best practice was to provide links to more than one place that a user could purchase the product.

The Twitter announcement stated that it was rolling out to English language websites. The blog post did not mention what languages it was rolling out to nor did the blog post specify that the product review update was limited to the English language.

Google’s Mueller Thinking About Product Reviews Update

Screenshot of Google's John Mueller trying to recall if December Product Review Update affects more than the English language

Screenshot of Google's John Mueller trying to recall if December Product Review Update affects more than the English language

Product Review Update Targets More Languages?

The person asking the question was rightly under the impression that the product review update only affected English language search results.

Advertisement

Advertisement

Continue Reading Below

But he asserted that he was seeing search volatility in the German language that appears to be related to Google’s December 2021 Product Review Update.

This is his question:

“I was seeing some movements in German search as well.

So I was wondering if there could also be an effect on websites in other languages by this product reviews update… because we had lots of movement and volatility in the last weeks.

…My question is, is it possible that the product reviews update affects other sites as well?”

John Mueller answered:

“I don’t know… like other languages?

My assumption was this was global and and across all languages.

But I don’t know what we announced in the blog post specifically.

Advertisement

But usually we try to push the engineering team to make a decision on that so that we can document it properly in the blog post.

I don’t know if that happened with the product reviews update. I don’t recall the complete blog post.

But it’s… from my point of view it seems like something that we could be doing in multiple languages and wouldn’t be tied to English.

And even if it were English initially, it feels like something that is relevant across the board, and we should try to find ways to roll that out to other languages over time as well.

So I’m not particularly surprised that you see changes in Germany.

But I also don’t know what we actually announced with regards to the locations and languages that are involved.”

Does Product Reviews Update Affect More Languages?

While the tweeted announcement specified that the product reviews update was limited to the English language the official blog post did not mention any such limitations.

Google’s John Mueller offered his opinion that the product reviews update is something that Google could do in multiple languages.

Advertisement

One must wonder if the tweet was meant to communicate that the update was rolling out first in English and subsequently to other languages.

It’s unclear if the product reviews update was rolled out globally to more languages. Hopefully Google will clarify this soon.

Citations

Google Blog Post About Product Reviews Update

Product reviews update and your site

Google’s New Product Reviews Guidelines

Write high quality product reviews

John Mueller Discusses If Product Reviews Update Is Global

Watch Mueller answer the question at the 14:00 Minute Mark

[embedded content]

Searchenginejournal.com

Continue Reading

DON'T MISS ANY IMPORTANT NEWS!
Subscribe To our Newsletter
We promise not to spam you. Unsubscribe at any time.
Invalid email address

Trending

en_USEnglish