Website Redesign: Performance Audit

One of the goals of redesigning my personal site was to improve performance. You know, things like how fast it loads, how many things are being loaded and such.

My existing site design actually did pretty well for a site that hasn’t been touched in six years. Here are a few of the metrics that I pulled from WebPageTest:

Time to First Byte	2.782s
Fully Loaded	5.3s
Requests	46
Data	764 KB

Those 46 requests (and 764 KB) freaked me out a little. For crying out load, where were those coming from?! I guess I relied pretty heavily on third-party libraries and scripts, but I had no idea it was that many.

I went ahead and started optimizing things in a few kew ways.

Remove unnecessary scripts

The first thing I did was go ballistic on third-party scripts. One piece of low-hanging fruit was the site’s typography. I had been using Typekit (now Adobe Fonts) to serve custom fonts and, while they do an excellent job optimizing things on their end, I no longer see the value in having special fonts on my site at all. So, I ditched all fonts and went with a system font stack that uses the default font of the user’s operating system:

{!{code}!}czoxNzQ6XCJib2R5IHsKICBmb250LWZhbWlseTogLWFwcGxlLXN5c3RlbSwgQmxpbmtNYWNTeXN0ZW1Gb250LCBcXFwiU2Vnb2UgVUlcXFwie1smKiZdfSwgUm9ib3RvLCBIZWx2ZXRpY2EsIEFyaWFsLCBzYW5zLXNlcmlmLCBcXFwiQXBwbGUgQ29sb3IgRW1vamlcXFwiLCBcXFwiU2Vnb2UgVUkgRW17WyYqJl19b2ppXFxcIiwgXFxcIlNlZ29lIFVJIFN5bWJvbFxcXCI7Cn1cIjt7WyYqJl19{!{/code}!}

Good good, one down… and so many others to go.

Another culprit was jQuery. Now, I’m not on the bandwagon that says jQuery is bad in modern web development. It’s a wonderful language and I’d still use it on projects, if it made sense for the job. It’s just that this particular job didn’t require it. WordPress includes it by default, so I went ahead and removed it:

{!{code}!}czoyNTc6XCJmdW5jdGlvbiBjaGFuZ2VfZGVmYXVsdF9qcXVlcnkoICZhbXA7JHNjcmlwdHMpewogIGlmKCFpc19hZG1pbigpKXsKICB7WyYqJl19ICAkc2NyaXB0cy0mZ3Q7O3JlbW92ZSggXFxcJ2pxdWVyeVxcXCcpOwogICAgJHNjcmlwdHMtJmd0OzthZGQoIFxcXCdqcXVlcnlcXFwnLCBmYWxze1smKiZdfWUsIGFycmF5KCBcXFwnanF1ZXJ5LWNvcmVcXFwnICksIFxcXCcxLjEwLjJcXFwnKTsKICB9Cn0KYWRkX2ZpbHRlciggXFxcJ3dwX2RlZmF1bHRfc2Nye1smKiZdfWlwdHNcXFwnLCBcXFwnY2hhbmdlX2RlZmF1bHRfanF1ZXJ5XFxcJyApO1wiO3tbJiomXX0={!{/code}!}

Notice that I’m only removing it from the front end of the site. I think WordPress uses it in the admin, so I wanted to make sure it stays there.

As I kept digging into scripts, I noticed saw another Jetpack relic in the source code. This time it was a CSS file the plugin was loading. I’m not sure why, but I’m pretty confident my front end views aren’t using it. Turns out Chris wasn’t either when I found his post sharing how to remove it:

{!{code}!}czoxMzc6XCJhZGRfZmlsdGVyKCBcXFwnamV0cGFja19zaGFyaW5nX2NvdW50c1xcXCcsIFxcXCdfX3JldHVybl9mYWxzZVxcXCcsIDk5ICk7CmFkZHtbJiomXX1fZmlsdGVyKCBcXFwnamV0cGFja19pbXBsb2RlX2Zyb250ZW5kX2Nzc1xcXCcsIFxcXCdfX3JldHVybl9mYWxzZVxcXCcsIDk5ICk7XCI7e1smKiZdfQ=={!{/code}!}

A couple of other housekeeping things I was able to do to help improve things:

• Use inline SVG whenever possible.
• Use as few raster images as possible (only one!)

Those two little things must’ve made a huge difference because the total number of requests fell down to eight when all was said and done. That’s a 82% decrease!

Delegate images to a CDN

Images might be one of the biggest offenders when it comes to bloated webpages. Whether it’s using too many of them, using files that are super large, or serving them from your own server, the fact is they weight things down quite a bit. As of today, the average webpage serves 980 KB of images to desktops.

I mentioned earlier that I am now using one raster image on my homepage. That’s different from the several I used before.

I used to compress images using the Smush plugin. It basically squeezes files when they’re being uploaded to the WordPress media library. It’s a great tool.

This time, I decided to delegate my image delivery to a CDN. I signed up for a free Cloudinary account and connected it to WordPress with the Auto Cloudinary plugin, which is super simple to set up. Cloudinary has it’s own WordPress plugin but, gosh, it hijacks the entire Media Library experience by forcing you to use their UI to upload files. Auto Cloudinary merely connects WordPress to a Cloudinary account so that any files that are uploaded to the Media Library are sent over to Cloudinary and served up from there. Yes, that’s a third-party thing, but I figure the ability to use WebP for images and leverage Cloudinary’s CDN makes for a good trade-off.

Images made 11 of requests (or 15.5%) on my site before the redesign. Now it’s a single request. That single request does account for 71.2% of my overall size, but (as we’ll see) that’s only because I’ve decreased other assets so signifcantly that the one image dominates everything.

Get stingy with CSS and JavaScript

I really thought these were going to be the headaches but optimizing CSS and JavaScript on my site wound up being a breeze. The reason? I’m no longer using a framework!

I’m not anti-framework or anything, but they do force you to confirm to their coding standards and use assets that require them to work. Foundation was my favorite because I really enjoyed the syntax for their layout grid. The only problem is that I had to inherit a bunch of other code to use the grid.

Well, hello CSS Grid! Now that CSS has this new layout superpower, I was able to ditch Foundation (or any other pre-fab grid) and roll my own with a few lines of code.

{!{code}!}czoxNDM6XCJib2R5IHsKICBkaXNwbGF5OiBncmlkOwogIGdyaWQtdGVtcGxhdGUtY29sdW1uczogMWZyIDNmcjsKICBncmlkLXRlbXB7WyYqJl19bGF0ZS1hcmVhczogCiAgICBcXFwibmF2aWdhdGlvbiBtYWluXFxcIgogICAgXFxcIi4gZm9vdGVyXFxcIjsKICBncmlkLWdhcDogNzVweDsKfVwiO3tbJiomXX0={!{/code}!}

That’s it. Seriously.

Given that I could ditch entire framework of CSS and JavaScript for those few lines of code meant that my CSS dropped to 11.2 compressed kilobytes… from 51.2 KB. That’s a 78% reduction overall!

Same deal with JavaScript: It went down from 305.9 KB to 8.4 KB, or 97%!

Remember when I said I ditched fonts? It’s a good thing I did, because that killed 118 KB for a grand title of zero. Zilch. Nada. Bueno!

Cache aggressively

The site already been doing a pretty good job of this before the redesign, so not much a change here. I’ve been using the W3 Total Cache plugin for some time and don’t really see any reason to stop.

I guess it’s good practice but caching annoys me. Getting too aggressive requires purging the site on a regular basis or forcing your visitors to clear their browser cache — not the best user experience.

The results

Metric	New Design	Old Design	Difference
Time to First Byte	2.362s	2.782s	-15%
Fully Loaded	2.907s	5.3s	-45%
Requests	8	46	-45%
Data	182 KB	764 KB	-76%
Repeat Load	0.412	NA*	NA*
Repeat Requests	0	NA*	NA*
Repeat Data	0 KB	NA*	NA*

^*I lost the test results before I documented them. Ugh.

---

I also ran both versions of the site through Lighthouse and saw a decent improvement in the performance score, going from 84 to 99.

What’s next…

There’s still a bit of work to do before I’m ready to call the redesign baked. I’m definitely happy with the performance gains. A Lighthouse score of 99 is fantastic in my book and the fact that the single point I lost was due to the Time to First Byte means I’ve done all I can do to make things load quickly. Well, perhaps I could try to move my hosting over to Netlify to earn that point, but it’s not high on my list.

What is high on my list is accessibility. I tried to be pretty intentional about it going into the redesign but I neglected to test several things. That will be my next focus.