I officially launched Siteimp last night so finally have time to do a bit of work on this website. One of my big goals is to improve it’s performance. It’s already quite good but I know that I can optimize it even further. Here are my average scores from the Siteimp report:

Things I learned

As you can see, my performance is quite good but I noticed a couple of things. First, my site is relatively image light but it’s still coming it with an average page size of over 88,000 bytes. That’s small but if I start adding images to blog posts, that’s going to quickly go up. It’s interesting because the report shows that unused CSS is a problem on 100% of my pages.

I also learned that 100% of my pages are having problems with render blocking resources. If you have run Lighthouse reports for your site, you might be familiar with the suggestion “eliminate render blocking resources”. If so, I’m going to go in depth in the next article in this series. For now though, I’ll give a simple explanation of the suggestion.

Before a user gets to use your page, their browser has to execute a critical rendering path. If CSS or JS is necessary to display your page, those files are referred to as ‘render blocking resources’. So essentialy, when Google Lighthouse suggests that you eliminate render blocking resources, they really want to help you shorten your page’s critical rendering path. Does that make more sense? If not, read page 2 of this and I’ll go into way more depth.

Siteimp site wide recommendations

One of my favourite parts of using Siteimp is that it can go through big websites and find all the problems in common between all the pages. Then it shows those in the full site recommendations section. These are always a very useful place to start when you want to start optimizing your website. They help in two ways - not only will they immediately help all your Siteimp scores (and thus your Lighthouse scores, search performance and user experience), but they’ll also usually help cut down on server load. So your site will also perform better under load. So if you implement the full site recommendations you’ll see instant gains plus cumulative gains as your website gets busier.

My report shows that reducing unused CSS and eliminating render blocking resources will improve performance in 13/13 pages, for both mobile and desktop loads. That is a massive opportunity between those two areas. My report also suggests that I serve static assets with an inefficient cache policy. However, I am hosting hluska.ca on DigitalOcean’s App Platform. I’m still learning App Platform, but from what I’ve read, this is a known problem with the App Platform and I’ll have to wait for a fix.

If my performance was really poor, I would consider moving my site over to an Nginx server so I’d have far deeper control over how my site caches assets in my users’ browsers. However, at this point, my overall site performance is quite good. According to the Siteimp report, App Platform is delivering average server response times of 118.75ms across my entire site. My performance is good enough that it’s not worth duplicating that kind of response in order to shave milliseconds off page renders with more finegrained asset caching.

Next post

I’ll start looking into the resources that I load on every page and start making decisions how to optimize page loads.

The series

1. Improving hluska.ca’s performance with a Siteimp audit - this post
2. Eliminating render blocking resources part 1 - rel preload - next
3. Thinking through css on hluska.ca
4. Checking in on those changes
5. Investigating Font Awesome on my contact page
6. Minifying my site with Hugo on DigitalOcean App Platform
7. Writing a Hugo shortcode to optimize my images with UI Kit
8. Final results from my site improvement program