Hi folks, I already have a few articles on my Performance series.
They were about JavaScript and Rendering performance, as well as a high-level overview of Networking performance.
If you’re curious, go ahead and check it out.
In this article and a few later ones, I will share my thoughts and notes on Web Performance, I learned from a wonderful workshop with Todd Gardner. This includes understanding web performance, how to improve it, and how to plan for your application to get the most out of it.
Why is Performance important?
From Walmart
Every 1s improvement = Up to 2% increase in CVR
100ms improvement = Up to 1% incremental revenue
From Agrofy
They raised their conversion rate by 18%, by dropping their load times.
From Cloudflare
Their studied show the conversion rate of your website will go down if it takes more time.
From GOOGLE
They will rank your site based on its performance.
From USER
Angry and frustrated users don’t stick around long.
So, your business will depend on how you make your performance fast.
BUT.
What exactly is “FAST”?
Psychology of Waiting
Well, the answer is “it depends”
Because Wait time feels subjective.
Each of us has a different feeling and perception of HOW MUCH TIME WE SPENT.
To be more specific, it depends on
Our expectation of how long it should take.
What we can do while we’re waiting
There’s some general rules we need to discuss
People want to start. If we give them a way to start earlier, they feel like the wait time is LESS. Even it still take the same amount of time.
Bored time feels slower. Especially when the user doesn’t have anything to do during the waiting time.
Anxious wait times feel slower
Unexplained, uncertain wait times feel slower
People will be ready to wait for valuable things.
Measuring Web Performance with Core Web Vitals
We cannot just rely on our perceived performance.
The feeling of “fast” or “slow” can be different from person to person.
That’s why we need common metrics to measure Web Performance.
If we can’t measure, we can’t improve.
Image Source: Todd Gardner - TrackJS
We have 4 core metrics to measure 4 different performance aspect of our website.
Let’s explore them one by one
First Contentful Paint (FCP)
This is the time from the start when the user first clicks the link or enters the URL, until the first meaningful content enters the page.
The time until the user sees an indication that the page is loading.
Largest Contentful Paint (LCP)
The time until the user sees MOST OF the page and believes it is (almost) ready
Condensing that down to a rule, the user came to our site for a reason. Show that reason AS FAST AS you can.
Image Source: Todd Gardner - TrackJS
The largest contentful paint on the above page is actually the images.
Cumulative Layout Shift (CLS)
The total movement distance and impact of page elements during the ENTIRE LIFETIME of the document the user sees.
DON’T MOVE STUFF.
Each time the images or the banner finishes loading, they shift all the content down.
How might this impact our Client-side Rendering?
Each time you click on something, it’ll repaint a big portion of the screen to simulate a big portion of page movement.
But it wasn’t really a page movement. It was the SAME document as before.
It created a whole lot of layout shifts, and it worse.
First Input Delay (FID)
The browser time delay between the user’s FIRST CLICK and execution of the application code
SO, DON’T LOAD TOO MUCH! Don’t load what you don’t need. Or put too much things that slow the browser down.
Web Vitals
FCP - RESPOND QUICK
LCP - GET TO THE POINT
CLS - DON’T MOVE STUFF
FID - DON’T LOAD TOO MUCH.