How We Stay Lean While Doing Performance Improvements

As our CTO Sunil has explained previously, we make all our product decisions based on metrics, meaning that we try to launch features early and measure how they impact all our metrics in order to decide which path to follow.

We had the intuition that our current analysis tab in the Buffer for Business area could be tweaked a bit to make the user experience better. And last week Niel, one of our awesome front-end engineers, started drafting out some ideas on that and shared the document with the whole team, where we started brainstorming over it right away.

The ideas that came up were that Niel would trim down the retrieved data from the server, ensuring that we only receive the data we need (and thus getting a lighter response from the server), and I would try to implement some kind of client-side storage, in order to make the experience smoother for the user.

Finding the perfect balance

Whoa! Those are big tasks! Implementing a client side storage would mean to add an IndexedDB client-side database for the browsers that support it, and implement a fallback for the other browsers in LocalStorage or something similar!

One way of going about it would be to consider when and how to fetch from the server to keep that local data updated…

…but then we would lose the point of being lean, and we will be doing too much without knowing if that was at all the right thing to do.

Or we could tweak the code just to make it faster than what we currently have, impacting only the main bottleneck in the analytics flow, which seems to be the initial load time, and displaying the stats table for the sent updates for the selected date range. Then, if everything looked good, we would then create better fallbacks and have an opportunity to implement the storage strategies in other areas!

Searching for some libraries to help me communicate with IndexedDB, I found db.js which was just what I was looking for, a small wrapper for all the browsers IndexedDB implementations with a small and nice documentation and a readable codebase (oh! and you might have seen it mentioned on our engineering team Twitter account: @bufferhackers).

After toying around with it for a while, I quickly had a local database with my sent updates for the last 90 days, and the initial load time for the recent posts table was trimmed down by a couple of seconds. We were still fetching the data from the server side in the background, but we could start looking at our stats and they’d be completed after the server sent us the updated data.

Implementing a fallback

Implementing a fallback at this point seems like a big step to make, it feels like we are committing to our first implementation for improving the performance, and we know that we might be wrong.

The easiest fallback is the one that’s already developed: if the browser doesn’t have an IndexedDB, we will run exactly the same code as always. No performance boost for those users (for the moment), but it’s a solid code that has been working for everyone until now.

Release often and early

We try to deploy features like this as early as we can in the process, in order to gather early feedback from the whole team and to catch as many bugs as possible. That is usually done by releasing it on one of our staging servers for a day, and after smoothing as much as we can of the experience, we’d deploy it under a feature flip on production.

Feature flips and experiments

Feature flips are a way for us to enable experimental features on certain users. This allows us to test in production a new feature without impacting our current user experience. Usually we test it for a couple of days and then release it as an experiment for a small percentage of the user base (around 10–50% of the users). That way we can make sure that it impacts positively on our metrics and then we can make the call of deploying it to all users.

In this particular case, deploying it under a feature flip has helped us find and fix some bugs before the feature was released to the users, so it made us happy to know that we can give a more solid experience to you now ?

Over to you

How do you approach launching and developing new things on your projects?

I’d love to know your experiences and workflows!