How I Made GoodPlace Homes Faster By 314%

GoodPlace Homes

I suppose there’s no other way to put it: we completely bombed our launch last month. I won’t attempt to put a positive spin on it – we did a piss poor job at guessing how many people would turn up on launch day and prepare accordingly. In short, we screwed up. As you might know (if you were one of those who came on launch day), the site crashed in a rather spectacular fashion, and while it had since recovered, its uber slow loading speed (and I mean REALLY slow) meant that it was almost as useful as a Durex machine in Vatican city.

jared-loanstreet-censored

And as any self respecting startup geek would do, I went back into my room, cry a little, wallow in self-pity and finally came back out with a plan. In this day and age where the attention span of the homo sapien are but a little longer than that of a goldus fishingus, a slow loading website would be nothing short of an abomination. So I decided that GoodPlace should load as fast (if not faster) than the best property sites in Malaysia. Ahem.

As a wise man once told me, if I want to make good, I should compare what I do with those who have already done what I want to do successfully. So I went over to this nifty web speed benchmarking site WebPageTest.org and did a test on one of the biggest property sites in Malaysia (you could probably guess what it was) –

site-baseline-crop

The “First Byte” data point is a measure of how fast the server is – i.e. it’s the time taken for the server to respond when a user submits an HTTP request (geek talk for loading a web page). Therefore, we want the “First Byte” response time to be as low as possible. As you can see, this site’s time to First Byte (also known as “TTFB”) is 0.26 seconds, which is pretty good.

Additionally, “Start Render” is an important metric as it measures the time taken for the web page to start “appearing” in the user’s browser. The time taken for the web page to completely render visually is measured under “Visually Complete”. I’d give more importance to the “Start Render” metric, and in this case, it’s an impressive 2.8 seconds.

These will be the metrics that we will try to match (or beat). Now it’s GoodPlace’s turn to go through the same test, and here are the results –

goodplace-baseline

Kinda sucky! The server takes nearly 5.5 seconds to respond to an HTTP request, and consequently, only started rendering from 6.7 seconds onwards. Also, note the big red “F” that we received in the report card. We probably ranked in the bottom 10% of the entire Innerwebz as far as website speed is concerned! *nervous laugh*

But of course, you know that I won’t be writing this blog post if there’s no happy ending to the whole conundrum. Hacking a site to make it load faster is never easy because there’s just too many variables involved, and of course, being a blogger with a Darjah Satu level technical knowledge compounded to the problem.

And so I’ve spent two weeks trying to figure out everything from server administration to something as cryptic as “setup a cron job to warm the cache“, and thankfully, I survived the ordeal to tell this tale. 🙂 The following is the log of what I’ve done, and will make sense to those with an interest in website performance optimization; otherwise just skip to the results section below.

  1. Moving from the plain vanilla Exabytes server (Penang) to a Linode cloud server (Singapore). This made a ton of difference in terms of server response time. Although the cloud server is in Singapore, response time was still excellent, which made perfect sense because KL is (somewhat) of equal distance to Singapore and to Penang. Deploying a Linode required some Linux know-how though; my rusty Unix knowledge acquired about 15 years ago at school finally came to good use…
  2. Caching is a biggie. Enabling page, database and object cache kicked the site up a full notch in terms of site speed. Hacking the .htaccess file is kinda fun, I must admit. Also, “warming” up the cache made the site load even faster, and thankfully there was a free PHP script which I could download which could trigger the caching every day midnight through a cron job.
  3. Image optimization. I’m a fan of big, high resolution pictures, and I am in the minority few who believed in sacrificing some site speed for aesthetics. But still, further optimizing the images made the site load perhaps about 15% faster, and so it was worth it.
  4. Javascript / CSS minification and concatenation. Alright, we are now throat-deep in techie speak. What this means is that some files could be combined and further optimized so that they are delivered quickly in one shot (instead of the browser having to make multiple requests for multiple files). I found that some scripts broke after I minified the JS and CSS files, and there will be more work required to troubleshoot and test.
  5. Eliminate render-blocking Javascript / CSS. This was a simple tweak – making non-essential Javascript and CSS load last. As such, the page could render without having wait for every single JS and CSS file to load, giving the “Start Render” metric a boost.

At this point, I further considered to optimize further (I could enable a CDN a.k.a a content delivery network to host static content, which would make perfect sense given the amount of pictures that we had, and will have), but I’ve decided to stop tinkering for now because simply we’ve come to a point of diminishing returns.

Now post-optimization, here’s our test results with WebPageTest:-

goodplace-optimized-crop

Not too shabby, I must say. We have reduced the time to First Byte to 0.11 seconds, down from 5.5 seconds previously. More importantly, “Start Render” now stands at 1.8 seconds, down from 6.7 seconds. This represents an improvement of 314% in terms of site loading speed. Booyah!

If you’ve previously given up on GoodPlace Homes from its incessant crashes and slow loading speed, please do give it another spin and let me know! 🙂

About Khai Yin

When I am not writing for GoodPlace.my and helping my readers find properties though the DealMatcher service, I spend time doting on my three kids: Wenyi, Qinyi and Eian. My personal stuff, some published essays and contact details can be found at khaiyin.com

Speak Your Mind

*