In Speed We Trust
Speed is Gold.. don’t keep on silence.
Last year, we had a challenge to improve Blibli load time. It was a challenge that many have fallen, and had always been the war of interests..
A war between Business users wanting features, against us, Developer having less site load time as our KPI.
What I meant by interests was, when the developers were asked to improve the load speed, we were faced with overflowing feature requests.. then choices should be made, speed xor features. At that time, we chose many times on features.. expecting a better user experience by pushing new features. More features should mean higher traffic, in turn increased GMV.
However, researches has proven, speed is certain order of magnitude more important than abundant feature.
Every second counts [1] and [2]
According to surveys done by Akamai and Gomez.com, nearly half of web users expect a site to load in 2 seconds or less, and they tend to abandon a site that isn’t loaded within 3 seconds. 79% of web shoppers who have trouble with web site performance say they won’t return to the site to buy again and around 44% of them would tell a friend if they had a poor experience shopping online.
What is the average loading time among e-commerce in Indonesia? By our measurement.. far beyond 8 seconds.. including us, Blibli.com.
There really is something we must do about this.
My own experience, I was searching an item in blibli.com for maybe around 30 minutes. I was so excited to buy it there.. However, because the search result came up in around 20 seconds.. Suddenly, a question came up in my mind, how much is this item in another site..? Guess what happened! I closed the page and explore other competitors, a sad truth.
Abundant features are not everything, the FOCUS of customer is.
Do not let customer to have second thought on your items, let them focus on the items and wanting to execute checkout as soon as possible.
Regarding focus, you can look at the closest example.. your iPhone/android phone.. how many buttons are there?
Well, mostly nowadays, one button at front-facing, 3 other buttons in the right side, and a toggle in the left side..
Only one button at your view, providing simplicity.. and allowing user to get onboard quickly on using the phone. High FOCUS of customer on utilizing the phone, rather than distracted by many buttons.
Another example, related to web, is Google homepage.. how many items are there? It’s still countable by your fingers.
Google homepage is simple, fast, and focused entirely on its main goal, giving you a place to start typing search terms.
The silver lining of both are.. speed.. speed to get on board.. speed to provide the UI as soon as possible. Speed that will prevent the user to have second thought.
The first step
We had a pre-loader image.. a bouncy shopping bag that would keep on dancing until the page is completely loaded. It was a quite long dance though.. a minute or even more.
That was what we had till middle of last year. A not-funny bouncing shopping bag in our homepage. Rather than giving a good experience to user, it gave us (at least me personally) a traumatic experience.
Why? Because the homepage sometimes loaded fast, but in most cases it will wait up to one minute (browser max connection timeout) for the blinking dancing bouncing shopping bag to disappear. In not too rare cases, that stupid ridiculous dancing bouncing shopping bag wouldn’t vanish…… -_____-! then we are forced to reload the page, just to keep on trying.
What a pain in the a*s.
That’s what I and Herwidodo (my team-mate) were targeting first, along with the no-style login status and disappearing search box.
We killed the annoying dancing bouncing shopping bag, put a style on simple eye-serving search box and styled login status on first render.
The experience went much better. It was fun, again.. delightful.. remarkable.. bravo. Just a quick tweak, and the world of fun shopping experience was open again right before our eyes.
Defer as you can
But still.. something was still missing, even though the page seemed to be loaded quickly, there was still some glitch at the first load. We found out it was because of our js and css files were hold behind by trackers files.
That is our next enemy.. the trackers..
Based on suggestion here [3], we pull it back after the page is loaded (defer the script).
It worked like a charm :)
Although we had internal disagreement about this, we finally had a convention on which to load and when.
Afterwards, our site load time got trimmed half. Customer satisfaction index is higher in our analytic page, and the most important thing of all is us, the developer, we finally made a progress on speed.
A step that would be remembered as a milestone and opened up another possibility.. on changing our vue :)
References:
[1] How Loading Time Affects Your Bottom Line, https://blog.kissmetrics.com/loading-time/, September 2017
[2] Speed Is A Killer — Why Decreasing Page Load Time Can Drastically Increase Conversions, https://blog.kissmetrics.com/speed-is-a-killer/, September 2017
[3] How tracking scripts affect page loads… can tracking scripts kill my web app?, http://mrcoles.com/blog/how-tracking-scripts-affect-page-loads/, September 2017
