This blog will be the first one in a series of blogs related to web performance. This is a surface-level blog made for anyone, technical or non-technical.
Turns out, it is actually quite important.
Why is that the case? Well...
80-90% of the end-user response time is spent on the frontend (Source:
The performance golden rule by
@Souders). So if you are looking to optimize the end-user's experience, you'd want to start investigating there.
But why is this the case? Why is so much of the end-user response time spent on the frontend?
According to HTTP Archive's
report, as of October 2023 the median webpage weights
2445.3 Kilobytes, and the median Mobile webpage weights
2174 Kilobytes. This data was the result of analyzing
~29.5 million websites.
So... what gives? Why is the average website so bloated? Why does it matter and why should you care?
And finally, how do you optimize them for performance?
Let's start with "Why should I care?", it's a fair question!
Where do I even begin? You should probably care about performance a lot if you own a company since optimizing your frontend performance will likely significantly increase your revenue.
Don't take it from me,
take it from Google themselves, with the shortest possible explanation:
"speed equals revenue."How does that work? Google found that as the load time of a webpage increases, the user bounce rate of the page increases too.
The bounce rate of a webpage is the percentage of visitors who leave a website after looking at just one page.
According to their study, a website that loads in 5 seconds has 90% more probability of users bouncing compared to a website that has a 1-second load-time.
Besides this, the Google PageRank algorithm also considers a webpage's load speed for its rankings. So it's obvious that more performant websites lead to a better revenue.
Now that you know why performance is important, let's explore why websites aren't performant, and what to do to fix that.
Let's answer that by looking at what bloat in exists in the median web page. Here's how the page weight is distributed:
According to the HTTP Archive, the median webpage consists of 1026 Kilobytes in Images and 509 Kilobytes in JavaScript, along with 72 Kilobytes in CSS and 31 Kilobytes in HTML.
So if you're looking to optimize your websites for load-speed, you'd want to start with the images that your website loads since they account for >63% of the page weight.
I'll keep this blog very surface-level and focused on images, and will follow up with optimizing the rest of the assets in a later blog.
It's very easy to use images in the wrong way; check
this example for reference. This is
not a vector image, but it is used in an
svg tag... which ends up being
951 Kilobytes in size.
And if you further inspect it, you will find that inside the SVG, there is an image that that refers to a PNG in base64. So the image being an svg serves us no purpose at all.
So let's set up some rules for image format usage!
Almost always, use WebP - WebP is better in every regard than PNGs and JPEGs. It offers better compression than both PNG and JPEG. It supports transparency (unlike JPEG). It also supports progressive rendering.
When to use PNGs and JPEGs - When you need ~100% browser support across every browsers ever. WebP is supported on
~97% (source) of all the browsers.
PNGs VS JPEGs - Use PNG when precise reproduction or transparency of the image is needed. Use JPEG when you have an image where some compression to save bytes is okay -- like a photo of some landscape, every pixel won't matter.
What about SVGs? - Exclusively for vector graphics which are easily representable programmatically. Just like the bad use case I provided above, SVGs very often get used as images where a raster image would've been a better fit. But even when it is not obvious, raster images often maintain a smaller file size even when the image looks like vector art, this tends to happen quite often with badly generated gradients.
Once you have the image in the correct format:
Always compress the images before you use them in your websites.
compressor.io works great for this!
Load only what is necessary -- don't load a 1920 x 1080p image when the image is only going to be displayed at 600px width.
Preload your hero image(s), lazy load the rest of the images lower down the viewport.
Load the images progressively for better "perceived performance".
Generally, modern web development tech takes care of most of this for you.
If you use a simple NextJS application with create-next-app, it will take care of the minification/uglification of the JavaScript, bundle all of the assets into a single bundle and compress it before transferring it to the client.
That being said, I'll dive into the finer optimizations in a later blog and update this part with the link to the blog. Thanks for reading!