Last post, I talked about all the CSS that loads on hluska.ca, changed how my site downloands and processes Font Awesome CSS files and moved my internal CSS out of style.css into the head of my website. At the end, I mentioned that I was going to run another report so I could show you the impact of my changes.
Let’s take a look at where we were before articles two and three in this series. Here are site wide average scores from my first Siteimp audit (on January 7, 2022):
Those scores were already quite good but I wrote a couple of articles and optimized how browsers download and process site resources. I ran another report (on January 8, 2022) and here are the results:
The results here are extremely good - average performance increased 0.9 points in both mobile and desktop. All 17 pages on my site performed better as a result of those optimizations. But now look over to the far right hand of the report. Cumulative layout shift stayed 100 but I planned for CLS when I built this site so that’s expected. First input delayed improved site wide in both desktop and mobile views. And my largest contentful paint scores increased by 1.1 points on mobile and 1.7 points on desktop.
Those changes aren’t huge in terms of raw numbers, but hluska.ca started with site wide performance scores in the 90s. Once you get that high, it’s very hard to make small gains. I’m not sure I’ll be able to get to 100 but I’m going to keep trying.
Changes to SEO, Accessibility and Total Transfer
I relaunched my site about six weeks ago and have been busy working on a couple projects since so my website doesn’t have much content. The first report found 14 pages and the second report found 17. That’s it. I would like to take credit for the changes to SEO, Accessibility and Total Transfer but in reality, I just added three pages that didn’t make stupid mistakes in the content. It’s nothing I did, just mistakes I didn’t make. I guess that’s kind of technically something I did, but it’s irrelevant for our purposes.
Things I learned
Render blocking resources are less of a problem now. They still appear as a recommendation on roughly half my pages, but I’m going to leave that now. It’s all CS out of UI Kit and while I could pull the most critical CSS out and put it in my head, I’m not going to do that right now. I have a lot of pages and use many parts of UI Kit so that will add enough page weight on every load that the real world performance impacts will be small. The CSS still won’t be used on every page so I’ll still download unused bytes. I’ll just download them as part of the main .html document at load instead of waiting for UI Kit to download. That is one heck of a lot of work for limited gains and UI Kit has a really nice browser caching policy.
I’m going to leave render blocking resources alone in favour of some bigger changes.
One of my favourite parts of Siteimp (other than the fact that I built it and think it’s great), is the All Pages section of the report. It lists every page that our crawler found and lists its individual scores and total bytes transferred. It’s really useful after you’ve made
I understand why my home page is so big - it has a picture of me. But I’m not happy with my contact page’s performance. It’s currently the third biggest page on my site because of Font Awesome.
I’m going to take a close look at my contact page and make a final decision about Font Awesome.
- Improving hluska.ca’s performance with a Siteimp audit
- Eliminating render blocking resources part 1 - rel preload
- Thinking through css on hluska.ca - last post
- Checking in on those changes - this post
- Investigating Font Awesome on my contact page - next post
- Minifying my site with Hugo on DigitalOcean App Platform
- Writing a Hugo shortcode to optimize my images with UI Kit
- Final results from my site improvement program