From dcfb172704f3afb68a30425029ec834be2883274 Mon Sep 17 00:00:00 2001
From: bt
Date: Sat, 8 Jun 2024 13:22:19 -0400
Subject: More content porting, on-going markdown changes for lowdown support
---
build/chasing-performance/index.html | 311 ++++++++++++++---------------------
1 file changed, 126 insertions(+), 185 deletions(-)
(limited to 'build/chasing-performance/index.html')
diff --git a/build/chasing-performance/index.html b/build/chasing-performance/index.html
index 30e7436..86e39cc 100644
--- a/build/chasing-performance/index.html
+++ b/build/chasing-performance/index.html
@@ -1,216 +1,157 @@
-
+
Chasing Performance
-
-
+
+
+
-
Chasing Performance
+
Chasing Performance
+
2017-11-20
-
Update
-
This post is no longer relevant since this blog has been redesigned since. I'm keeping this article up as a point of reference.
-
-
So I decided to participate in Smashing Mag's Front End Performance Challenge, not only for the potential of winning the prize but to further experiment with optimizing my site. (Web performance is a passion of mine)
-
Below I will breakdown the before & after statistics of my personal site and what changes I made in great detail.
-
I will be using both my homepage and the image-heavy article I recently wrote, The Death of Personality, as the basis for my tests.
Though my homepage only made some minor speed performance enhancements, my article post's initial load time was slimmed down by a whopping 4.2 seconds! That's pretty incredible and very noticeable from an end-user's perspective.
-
So - What Changed?
+
+
Update
+
+
This post is no longer relevant since this blog has been redesigned since. I’m keeping this article up as a point of reference.
+
+
+
+
So I decided to participate in Smashing Mag’s Front End Performance Challenge, not only for the potential of winning the prize but to further experiment with optimizing my site. (Web performance is a passion of mine)
+
+
Below I will breakdown the before & after statistics of my personal site and what changes I made in great detail.
+
+
I will be using both my homepage and the image-heavy article I recently wrote, The Death of Personality, as the basis for my tests.
+
+
Lighthouse Score - Homepage
+
+
Full source original stats // Full source updated stats
+
+
Lighthouse Score - Article Page
+
+
Full source original stats // Full source updated stats
+
+
Web Page Test - Homepage
+
+
Full source original stats // Full source updated stats
+
+
Web Page Test - Article Page
+
+
Full source original stats // Full source updated stats
+
+
Quick Look
+
+
Though my homepage only made some minor speed performance enhancements, my article post’s initial load time was slimmed down by a whopping 4.2 seconds! That’s pretty incredible and very noticeable from an end-user’s perspective.
+
+
So - What Changed?
+
Webfonts
-
I'm not using any webfonts but instead defaulting to the user's OS System Fonts. I love custom typefaces but performance takes just too much of a hit on my personal site to bother with them.
+
+
I’m not using any webfonts but instead defaulting to the user’s OS System Fonts. I love custom typefaces but performance takes just too much of a hit on my personal site to bother with them.
Don't go down the rabbit hole of using 3rd party plugins to optimize something as basic as a typeface
+
Try to avoid any FOUT, FOIT, FOFT
+
Don’t go down the rabbit hole of using 3rd party plugins to optimize something as basic as a typeface
-
Critical CSS
-
This part was easy. In order to avoid the weird styling 'pops' present on some websites when initially loading with slow connections, it's best to place all your most critical styling inline and then load your external CSS once everything else has loaded.
-
On top of that, I decided to also implement Filament Group's loadCSS function to load my CSS asynchronously. If you are not currently using this in any of your projects; stop reading this and go do it! It's a game changer.
-
Critical JavaScript
-
My personal site only uses a small amount of JavaScript on the article post Jekyll template pages. By using the defer property I can be sure to load the IntersectionObserver API polyfill after the rest of the DOM as finished loading.
This part was easy. In order to avoid the weird styling ‘pops’ present on some websites when initially loading with slow connections, it’s best to place all your most critical styling inline and then load your external CSS once everything else has loaded.
+
+
On top of that, I decided to also implement Filament Group’s loadCSS function to load my CSS asynchronously. If you are not currently using this in any of your projects; stop reading this and go do it! It’s a game changer.
+
+
Critical JavaScript
+
+
My personal site only uses a small amount of JavaScript on the article post Jekyll template pages. By using the defer property I can be sure to load the IntersectionObserver API polyfill after the rest of the DOM as finished loading.
I could probably optimize this further by only calling these scripts if an image is actually present in the article post, but this fits my needs nicely as is.
-
Responsive Images
-
The only images I use are those included in supported blog posts, so the first step was making sure to only call iolazy.min.js on those specific template pages. The next step was defaulting to webp image formats with a lossless jpg fall-back with the help of the picture element:
-
I've also included responsive image sizes for further optimization based on screen size and loading speeds.
The only images I use are those included in supported blog posts, so the first step was making sure to only call iolazy.min.js on those specific template pages. The next step was defaulting to webp image formats with a lossless jpg fall-back with the help of the picture element:
+
+
I’ve also included responsive image sizes for further optimization based on screen size and loading speeds.
The Lighthouse audit also suggested implementing an SSL certificate (something I've been meaning to do for a while anyway) and also utilize CDN caching. So it was Cloudflare to the rescue!
-
Since my website is hosted through Github, setting up a free SSL certificate and enabling site-wide caching was a breeze. If you're interested in setting this up yourself, step-by-step instructions can be found here.
+
+
HTTPS & Caching
+
+
The Lighthouse audit also suggested implementing an SSL certificate (something I’ve been meaning to do for a while anyway) and also utilize CDN caching. So it was Cloudflare to the rescue!
+
+
Since my website is hosted through Github, setting up a free SSL certificate and enabling site-wide caching was a breeze. If you’re interested in setting this up yourself, step-by-step instructions can be found here.
+
This simple update helped boost my best practices score from a 69 to a 94. Yet another performance enhancement you should be enabling for all your current and future projects!
-
Performance Happiness
-
Overall I'm pretty content with the major performance boost my site has received from these fairly minor updates and I hope this article inspires other designers and developers to jump into updating their own site/app performance speeds. The pay-off is truly worth it!
-
Some Extra Reading Material
+
+
Performance Happiness
+
+
Overall I’m pretty content with the major performance boost my site has received from these fairly minor updates and I hope this article inspires other designers and developers to jump into updating their own site/app performance speeds. The pay-off is truly worth it!