Migrating to WriteKay

Written on August 8, 2016

The web has an obesity crisis. This is why I have switched away from writing on Medium to writing on WriteKay - a self-hosting publishing platform based on Jekyll and Github Pages. The results have been astounding - achieving 7 times less data usage on average and a 200% page load speed boost.

A comparison. Or a non-comparison depending on your perspective.

My most popular post by far is about Apple’s updated Photos app and its enhanced capabilities. The exact same page - with the exact same compression on images weighs dramatically differently on Medium and on WriteKay.

On Medium, the page weighs 2.48MB in total, thanks to various webfonts and tracking scripts Medium loads alongside with the article. On an Intel i5 laptop, having all scripts complete running takes 8 seconds. On an iPad 2 with A5 chip running iOS 9, it takes a whopping 10 seconds for contents to display and 18 seconds for Javascripts to complete running.

On WriteKay, the same page weighs 367KB in total - that is 7 times less than 2.48MB on Medium. On the same Intel i5 laptop, all scripts finish running in just around 3 seconds. On the same iPad 2 with A5 chip running iOS 9, it takes about half a second for contents to display and 5 seconds for page composition to complete.

For text-only pages, the difference are even more dramatic - often with the Medium version weighing around 1.5MB while the WriteKay counterpart weighing around 150KB. That’s a 10x difference.


Sometimes, even on the fastest LTE or Wi-Fi, the latest hardware and software, there are still limiting factors that reduces Javascript performance. Popular social clients, such as WeChat still renders webviews with UIWebView rather than WKWebView on the latest public build of iOS as they have to support legacy versions of iOS and don’t want to write conditional code. And when a piece of writing is shared through WeChat, many complain the terrible page load performance - with my Medium posts taking around half a minute to load.

When I share the links with them in person, I observe them putting down their phones and do something else until it loads. That is a terrible experience. I remember someone asking me…

Can you make this any faster?

I shrugged, and said…

It’s not up to me. It’s up to Medium.

Then he said something as simple as…

You are good with computers. Take it over and do your thing.

I’m not that good but I’m glad I listened. Earlier today, I’ve linked a few posts on WriteKay to him.

Holy. That was fast.

A touch of Javascript

Safari in iOS 9.2.1 or below and any iOS app utilizing UIWebView rather than WKWebView suffers from the 300ms tap delay. Thanks to server logs collected over last month from a quiz game I have created, I have unsurprisingly and unfortunately discovered there’s a ton of devices running iOS 9.2.1 or below. And there’s even more apps utilizing UIWebView.

As a result of the need for legacy support, a lightweight 10KB polyfill named FastClick by FT Labs is conditionally deployed on this site when browser imposes the 300ms tap delay - allowing near-native responsiveness on mobile browsers.

FastClick is a simple, easy-to-use library for eliminating the 300ms delay between a physical tap and the firing of a click event on mobile browsers. The aim is to make your application feel less laggy and more responsive while avoiding any interference with your current logic.

Tell me What You Think

Feel free to send me an email at KayYin@Me.com and tell me what you think.