[MUSIC PLAYING]
PATRICK KETTNER: You never get a second chance
to make a first impression.
That's why perfecting your First Input Delay
is key to a great page experience.
Isn't it frustrating when you're trying to browse a site,
or use an app, or just watch a video--
see what I mean?
Delays interrupt us.
They break up our thought process
and make it harder to focus or just complete our goals.
That's why it's so important to make
sure the people using our site have as few delays as possible.
One of the ways that Page Experience helps reinforce
this idea is through the metric First Input Delay, or FID.
FID is a new web API that you may have heard of last year,
as it was a part of the inaugural group of Core Web
Vitals.
First Input Delay measures how long
it takes in milliseconds for your site
to react after someone interacts with it.
It's like when they click on a button
or if they tap on a text input.
That means that we're measuring the delay in processing data
and interactions, not the time it actually takes
to process that data.
You can think of it as how long it takes for your page
to feel like it's interactive.
It's being responsive to the user the very first time
that they use it.
And just like every part of Page Experience,
each and every one of the URLs on your site
are scored on First Input Delay independently, directly based
off of the actual users using your site.
Your home page may have fantastic values,
but your product page or articles could be a little bit
far from perfect.
Regardless of how any page is performing though,
neither result impacts how another page is
performing on Page Experience.
Every URL is an island.
However any of your pages are scoring,
you can be sure that the numbers that you see
reflect what users are actually experiencing.
That's because the FID scores are
coming from the monthly Chrome User Experience Report.
You can read more about this report in the links below.
Now that we have some idea as far as
what FID is, how do we go about finding out how your pages are
actually doing?
Since FID is inherently about how your site reacts
to interactions, it requires real users
to get an accurate measurement.
As a result of this, you can only
really rely on user measurements that
come from real-world users, either via your own analytics
or the ones that you have the ability
to access inside of the Core Web Vitals Report
section of the Search Console.
If you haven't already, you'll need
to create a free account to access the Search Console,
but I highly recommend it.
You will get some invaluable information
about how your site is performing with Page Experience
as well as a lot of other foundational pieces to creating
fantastic modern websites.
You can quickly check out how your pages are performing
with PageSpeed Insights.
This is a hosted online version of the same Lighthouse
tool that's a part of the Chrome DevTools.
It shows you how your pages are performing
in a test environment that's configured
to be around the connection speed and device
performance that's going to be average for a web user today.
Your URL needs to be online for over a month in order
to be included in the Chrome User Experience Report.
If it has been, you can see the actual Core Web Vitals results
directly.
So you've got a number.
Now what?
Like all the Core Web Vitals inside of Page Experience,
there's no such thing as passing or not passing.
These are all used as guides.
Search is using them to create relative performance
differences between URLs to see how they're
performing against one another.
Generally speaking, a good goal is to have about 75%
of your site's visitors have a First Input Delay
of less than 100 milliseconds.
100 milliseconds has long been considered
the point at which people perceive user interfaces
as behaving instantaneously.
Anything in the 100 to 300 millisecond range
is starting to become problematic.
And anything beyond 300 milliseconds
is a noticeable delay and will likely cause a worse experience
for your users.
One thing worth mentioning is you are not
guaranteed to have an FID value, since it's inherently based off
of a user interaction.
If your page doesn't have anything to interact with
or people just don't ever click on buttons or inputs,
there won't be an FID value recorded.
If your pages are new or your URLs
haven't been included inside of the Chrome User Experience
Report, you can still figure out what your FID results are.
It just takes a little bit more effort.
Like I mentioned before, all of the field data
in Page Experience comes from your actual real-world users.
That means that we can figure out the FID ourselves using
the same APIs.
In order to do this, we need did add a little bit of JavaScript
to our page.
All of the Core Web Vitals are available to us
via JavaScript APIs--
specifically, through PerformanceObservers.
These observers give us an event or list
of events that match the type of performance events
that we're interested in.
In this case, we're going to be looking for first-input.
Once the browser determines a first input has happened,
it will execute the function that we pass it,
passing us the list of events that
match what we've requested.
Though first input will likely only ever have one event,
the PerformanceObserver always passes
us a list of events to our callback,
so our code iterates over the responses
by calling getEntries.
For every entry, we look at the processingStart
and subtract the startTime.
The difference lets us know how long the First Input Delay was.
You can take these numbers and send them up
to your own analytics infrastructure
to start to get a good idea as to what our FID results are
going to look like.
If you're having a hard time bringing down
some of your results, tracking in your own analytics
can let you do a much more detailed data analysis.
You can look for patterns such as user location, device type,
or other bits of information that may not
be as obvious to compare and contrast on the official Page
Experience results.
It is important to note, however,
that while these are close and potentially identical
values to the FID results, there are a number of edge cases
that could potentially make it slightly different.
You can read more about the nuances of this at the link
below.
Do you have 100% of your users below 100 milliseconds?
That's amazing.
Let us know your secrets in the comments below.
But if you're anything like me, you'll
have at least a little bit of work to do.
So from a high level, there are a few things
to know about First Input Delay issues.
First is defer, delay, and delete JavaScript.
By definition, any delay that is occurring
is going to be related to JavaScript
that is running on your page.
All of the code on your page runs in the same thread
by default. That means that the browser can only
do one single thing at a time.
So if a bit of code takes longer than expected,
everything is blocked, even actions that people using
your site may be trying to do.
This could be that you're just having
a large chunk of JavaScript that's
being parsed or loaded when the page is initially loaded up.
An event handler could be blocking something on heavy,
or it's just slow there's some reason--
too much code or it's trying to run once
or any other things could be happening
that's just making the whole site slower in general.
If you're seeing issues with First Input Delay,
check if you are loading too much JavaScript.
Anything larger than 200 kilobytes
is probably pretty large.
If it is, it'd be a great idea to check out code splitting.
This is a feature built into all modern JavaScript bundlers that
allows you to split up code into smaller chunks
and make sure that you're not blocking the rest of your page
from reacting to users' input.
You can learn more about code splitting in the links below.
After splitting, any code that isn't essential for page load
should be loaded using the async or defer attributes
on the script tag.
By using defer, you're telling the browser
that the script is not going to change the layout of the page,
so it shouldn't block the rendering of the page
while it's being loaded or parsed.
Async is a lot like defer, only it takes it a step further.
It says to not wait on any other scripts.
Using the async attribute tells the browser
to execute your code without blocking on any other script
beforehand.
While we're already digging into the source code,
be sure to be on the lookout for code that can just simply
be deleted.
It can be easy to accidentally include
polyfills or workarounds long after they're actually needed.
Often, the first interaction a user has with the page
is going to be something at the top of your page,
things like a menu button or a search input, things like that.
But if you're having issues with First Input Delay
but aren't really sure why your score is what it is,
a great idea is to start tracking the elements
on your page that are having their delays being measured.
If we look at the code snippet we were working on before,
we also have access to APIs off of that same entry object.
Specifically, I like to look at entry.target.
This lets us know the element that we were interacting with,
whose delay is what's being measured.
This can be really helpful if you
have a large number of links, buttons,
or other clickable, tappable elements on your page
but aren't quite sure as to which one it is that's dragging
your scores down.
Once we track what target is often
associated with people who are having a slower First Input
Delay, you can start to dig into your site's code
to understand what events are tied to it, to any listeners
that may be attached to it.
Another thing to look into is breaking up long tasks.
Even if your code doesn't need to be split up,
your tasks may still need to be.
Tasks are just things that your code is doing.
It could be laying out your web app,
downloading states, or reacting to user input.
A long task is anything that takes
longer than 50 milliseconds to complete.
If you're having issues with FID,
then looking at your long tasks is a great starting place
to see where improvements could potentially be made.
Long tasks are actually highlighted
in the Chrome DevTools.
If you want to start looking for these on your user devices
to build up a correlation between Page Experience results
and long tasks in the field, you can actually
programmatically access them, just
like we looked at the first-input event before.
We create a PerformanceObserver, then observe the longtask type.
From there, we can iterate over every instance
to look into each attribution.
This will give us a bit of insight
into the functions that may be long running.
DevTools is definitely a much better developer experience,
but this API allows you to collect this information
from your users and your own analytics,
so you can track down correlations
that may be otherwise hard to find in your local dev setup.
Once you've found a long-running task,
the next step is going to try to break it up into smaller
asynchronous functions.
This can be as simple as wrapping code into setTimeouts
or requestAnimationFrames, but always, the specifics
depend on your specific situation.
You can read more about the techniques
you can utilize to break up long tasks in the links below.
In general, improving First Input Delay
comes down to optimizing when, where,
and why of the JavaScript on your site.
You want to try to reduce its usage to the minimum needed
to maximize your site's potential.
Page Experience is new, but the ideas behind it are solid
and user focused.
If you can get great results, then the visitors on your site
will be all the happier for it.
There's still quite a bit to cover with Page Experience,
but we're running out of time for this video.
So make sure to share any questions you
have on Twitter or in the comments below,
and be sure to Subscribe if you haven't already.
We'll be back soon to dive into yet another part
of Page Experience.
Thanks.
See you soon.
[MUSIC PLAYING]