Saving 800KB per page with a bit of JavaScript
I know the title is almost click bait, but I wanted to write about a small change in the generated HTML code for post pages in this blog. It prevents another 800KB of JavaScript code and data from being loaded per page as of the time I’m writing this. The long explanation can be found below, but the short explanation follows: I added a button in the bottom every post page to load comments. Until that button is pressed, the additional Disqus JavaScript code, which embeds comments in the page, will not be loaded and run. Before the modification, comments would load automatically. That additional code and data weights around 800KB (it was 1.2MB when I decided to write about this a few days ago) even for a page with zero comments. Most of it does not change over time to recurring visitors and can be cached by the browser, but it resides in a subdomain related to my Disqus account under disqus.com, so I guess the browser has to download it first for every domain you visit with Disqus comments.
Background
This blog is ultimately hosted in my personal web space at FastMail. I’ve mentioned FastMail several times in the past, specially when I blogged about their CardDAV support. FastMail handles all my personal email for around 40€ a year. In addition to email, they also provide a few other services, like my contact list and my calendar (both accessible from my phone through the standard apps).
More importantly, FastMail also gives me a fair chunk of web space to upload files to. I can upload them through their web interface or using WebDAV, and I can upload HTML files and decide to publish them in a chosen domain, subdomain and path under my control. In any case, only static files are supported. FastMail is not a dedicated web hosting company. You can’t run PHP or CGI scripts, and you can’t touch the web server in any significant way. For example, I can’t configure a TLS certificate.
Disqus
Without dynamic content you can’t have user comments and, without user comments, what’s a blog? Well, in my case it would be exactly the same because most posts have zero comments, haha! Anyway, Disqus is probably the easiest solution to implement comments on a static site. They have free accounts and you only have to include a small piece of JavaScript code at the bottom of every page you want to insert comments in, together with a specially marked element (usually an empty div) that will be replaced with an iframe containing the comments.
That small piece of JavaScript will, in turn, load several larger scripts from Disqus that will examine your page and replace the designated element with the embedded comments. They will take into account the web page you’re running the script from so as to load and store the right set of comments. Pretty clever and simple from the user standpoint. The comments are hosted and stored at Disqus while your static site lives happily in your own domain. The problem is those scripts are pretty big. As I explained previously, I aim for my site to be available and readable from slow connections. I had checked my post pages were light, but I didn’t realize they were dynamically loading so much data.
A nice side-effect of the new “Load comments” button is that, if you visit this blog with uBlock Origin or a similar add-on installed, you’ll see post pages don’t need to have any element blocked until you press the button. This means users with or without an ad blocker will benefit from increased privacy when passing by the blog.
Cloudflare
While we’re at it, I put Cloudflare in front of the blog. I know we probably shouldn’t rely on a few CDNs to serve half the contents of the web, but Cloudflare was the easiest solution for me to add TLS support to this blog. You may have noticed the (probably) green padlock in the address bar. The site is now served over HTTPS, scoring an A+ in the SSL Server Test from SSL Labs. I’m using Cloudflare in its Flexible mode. That means Cloudflare retrieves my content over plain HTTP but caches it and serves it to you over HTTPS. As I don’t host any service with personal information here, this mode just means visitors will get added privacy at no cost thanks to the opportunistic encryption, and I also get some peace of mind knowing if any page hosted here is eventually hit with a lot of traffic (legit or not), I won’t reach the strict FastMail bandwidth limits, making the whole site unavailable.
If you ever comment, your experience should also be marginally better. Previously, it was an HTTP page with an embedded HTTPS comments iframe, but what you saw in the address bar was the plain text connection. As you logged in through Disqus, Google, Facebook or whatever account you may have been using to comment, it wasn’t crystal clear that it was a secure connection. With the site now being served through HTTPS, the absence of a mixed content warning should inspire more confidence. By the way, thanks to Mozilla for including an insecure login warning in Firefox. It’s a bit of a shame that searching for “firefox insecure password warning” leads you mostly to pages explaining how to disable it.
Kudos to Cloudflare for providing free accounts and making the integration process incredibly easy. You only have to create the account and tell them about the domain you want them to proxy. Then, you review the entries they import from your existing name servers, adding things they may have missed, removing some entries and deciding what Cloudflare will cache, and finally you switch your existing name servers to theirs. For simple cases like mine your site will experience no downtime. I did the switch in about one hour, including reviewing the DNS entries, reading a bit of documentation and flipping some switches in the Cloudflare control panel.
Edit: I forgot to mention the site is also available over IPv6 as another nice side effect of using Cloudflare.