My blog’s current incarnation’s birthday is approaching – it’s been nearly a year since I put a fresh coat of paint on an otherwise boring-looking site. In order to design and build it, I had to master some basics of web development. After its launch, I’ve not stopped learning and improving it.
At times, I’ve gone a bit overboard, but I’ve been able to justify the time and energy because it’s been educational. My blog has been a good side project to learn new things on. It’s something I care about, but updates to it are almost certainly never urgent. It’s a low-risk thing I’m motivated to work on.
This weekend has also been full of exciting changes to my blog ( ಠಠ ). It started when I took a look at the CloudFlare dashboard and saw that my site barely had _any cache hits. Not a huge deal, since my S3 bill is pretty cheap anyway, but I wanted to fix it. It was a matter of principle or whatever.
Now that the files are uniquely named based on hashes, I need to tell clients to cache these files for a long time. I used s3cmd to give all existing resources long cache lives, and I hooked into my existing CDN invalidation script to set cache headers on new or modified files.
The next thing was to tell CloudFlare to cache everything. By default, it doesn’t cache HTML. Since I’m trying to do things properly or whatever, I also added documentation.
So the site is now properly cached and stuff, very cool (since verified). I would’ve called it a day at this point, but in the process of setting up the cache, I came across Google’s PageSpeed tester. My site had a pretty respectable rating in general – CLoudFront helped a lot here – but it had only 74% on mobile. This really bothered me for some reason. I guess I always assumed since my site was statically served off of S3, and behind a CDN, that it would be fast.
The problem was, I had never considered what happens between my site being served and my site being seen by a user.
The biggest issue, according to Google, was that my site required render-blocking CSS to display “above the fold content.” Their recommendations seemed way too difficult, so I decided to tackle the smaller problems first.
I checked back with the PageSpeed tester, and I checked. My score had improved, but only from 74% to 84%.
I had to tackle the main problem: CSS.
Browsers work by downloading HTML, and then fetching the files needed to render it. This includes CSS – until every bit of it is downloaded, none of the page is rendered at all. Google’s suggestion was to include the CSS inline with the HTML, which is clever. Let me explain.
In order to display the top of the page – the part the reader sees first – you need to have all the CSS that HTML needs to be rendered. There’s lots of CSS that you don’t need to just render the top of the page, and you can download that later. By including just the necessary bits (near the beginning of the HTML file), you can render the visible content right away. While the user is reading the site, the browser downloads and applies the remaining CSS asynchronously.
It intimidated me because most of the resources I found suggested that I do this by hand. I thought this was a bananas idea – turns out I was right.
I pushed the changes, waited for the deploy, and Google was happy.
I’m sure there are things I’m not doing correctly, or optimally. If you have feedback or suggestions, just open an issue.
It’s remarkable that I’ve been able to take my site from something simple to something just sophisticated enough – I’m quite proud of it.
A year ago, if you told me to embed some CSS in the pages, I’d have just pasted it in. But now I’m comfortable enough to be clever about where I put it. It’s a small change, but it’s indicative of a broader perspective. My comfort zone has grown, and I’m excited to see what kinds of new challenges I’ll take on next.