From dc6db80fa72286704849ef61ee0e5ccb5841cb09 Mon Sep 17 00:00:00 2001 From: Bradley Taunt Date: Tue, 2 Jul 2024 14:28:49 -0400 Subject: Conversion to barf for testing purposes --- _posts/2017-11-20-chasing-performance.md | 250 ------------------------------- 1 file changed, 250 deletions(-) delete mode 100644 _posts/2017-11-20-chasing-performance.md (limited to '_posts/2017-11-20-chasing-performance.md') diff --git a/_posts/2017-11-20-chasing-performance.md b/_posts/2017-11-20-chasing-performance.md deleted file mode 100644 index b02e3db..0000000 --- a/_posts/2017-11-20-chasing-performance.md +++ /dev/null @@ -1,250 +0,0 @@ ---- -layout: post -title: "Chasing Performance" -date: 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. - -### Lighthouse Score - Homepage - -Full source original stats // Full source updated stats - - - - - - - - - - - - - - - - - - - - - - - - - - -
StatsBeforeAfter
Performance8298
Accessibility100100
Best Practices7594
- -### Lighthouse Score - Article Page - -Full source original stats // Full source updated stats - - - - - - - - - - - - - - - - - - - - - - - - - - -
StatsBeforeAfter
Performance3996
Accessibility97100
Best Practices6994
- -### Web Page Test - Homepage - -Full source original stats // Full source updated stats - - - - - - - - - - - - - - - - - - - - - - - - - - -
StatsBeforeAfter
Initial Load Time0.91s0.41s
Visually Complete0.9s0.7s
Fully Loaded0.94s0.65s
- -### Web Page Test - Article Page - -Full source original stats // Full source updated stats - - - - - - - - - - - - - - - - - - - - - - - - - - -
StatsBeforeAfter
Initial Load Time4.7s0.5s
Visually Complete3.1s0.8s
Fully Loaded4.8s0.67s
- -### 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. - - - body { - font-family: -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen,Ubuntu,Cantarell,"Open Sans","Helvetica Neue",sans-serif,"Sans Serif",Icons; - } - - -For reference, there are some things you should to look out for when using custom typefaces: - -- Readability and accessibility -- Possible extra overhead loading in a custom @font-face -- 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. - - -