The 3rd in series of posts about this website. I will write about website performance optimization, tools I use, and how I got this site to be one of the fastest on the internet.
This website is already very fast and scalable by design. Using statically generated Web pages has the benefit of not needing a web server to generate HTML so that you can deploy all your files to CDN. You only need a web server that can serve static files. By adding a CDN, files can be cached and served in less than 100 ms to any user in the world.
I will use Google Chrome Developer Tools to look into my website loading and rendering speed - Performance (former Timeline) and Network tabs.
Before the optimization
If we look at the screenshot, we can see that the first frame is rendered at around 700 ms when we open this website using 3g connection (simulated in Developer Tools with network throttling - “Regular 3g”). All of my JavaScript code is nonblocking using the defer script tag attribute. The purpose of a blog website is to show an article to the user, something to read, and this must be the priority. I want it to show the article to the user as soon as possible, and don’t want it to be blocked by JavaScript code downloading and parsing. Also, most of the CSS loading is asynchronous (FontAwesome and Disqus). But there’s that style.css file blocking the page rendering for more than 450 ms.
I decided to inline that CSS code and minify it. While searching for minifiers, I found purify-css npm module and decided to use it too. The script I wrote is replacing CSS link tags with minified and purified inline CSS. The script is running as Hexo console script, but it can be easily modified to be a standalone Node.js script.
There are some drawbacks to this approach. Inlined CSS is not cached on users browser when they navigate trough the website, and initial page is a bit larger. My HTML file was around 11 KB, and with inlined CSS it’s 18.5 KB. Let’s check the results.
After the optimization
Not bad - from 700 ms to less than 400 ms. There’s one roundtrip less, but more weight to the initial request is added. I think that something should be displayed to the user as soon as possible, and I’m not referring to a loading spinner.
But, there’s more room for optimization - this website is still lacking Gzip compression. CloudFront has an option to compress files automatically.
After Gzip enable
With Gzip on, I’m getting the first frame at around 200ms. Note that it’s without browser caching with a simulated 3g connection. I still need to optimize my images…
If you know how this site can be faster, please let me know - leave a comment, or throw me an email.
Stay tuned to read more about web application architecture, optimization and more. My plan is to add dynamic functionality to this website by integrating serverless architecture with AWS Lambda.
I will be reviewing some websites in the future to give you an insight into some bad design decisions which are directly affecting user experience and performance.