How we made loading 50% faster for bigger customers
A behind the scenes look at how we boosted our sync engine performance and cut first load times almost in half for one of our largest customers. We walk through what we discovered why the real bottleneck was not the network at all and how a simple shift in sync priority delivered a huge improvement. If you enjoy stories about clever engineering wins and where we are taking our offline first architecture this one is for you.
Every now and then we like to pull back the curtain and talk about what is happening under the hood at Success.co. Not the marketing story. The real engineering story. The stuff our team gets excited about when we finally crack a tricky problem that has been nagging at us. Today is one of those moments.
A quick recap of the sync engine
If you have used Success you have already benefited from the sync engine that powers the entire experience. (And if you haven't see https://www.success.co/demo). We built it ourselves from scratch because we wanted something that gives customers an incredible experience. The engine keeps a secure in-browser database (IndexedDB) up-to-date which basically means the app can keep working even when you are sitting on an airplane with no wifi and we sync your changes with your get wifi again.
This approach also lets us ship features faster because the design takes care of all the network programming for us and means we can focus more energy on the actual user experience.
The problem we ran into
Recently one of our larger customers who has a big team and a huge amount of historical data let us know that the very first load of Success on a fresh laptop was slower than it should be. Not unusable but not the experience we want to deliver. Once the data was synced the app was blazing fast. But that very first load was not where we wanted it.
This customer had imported more than seven years of data from another platform. That added up to more than one hundred thousand objects that needed to be dropped into the local database. Naturally our first assumption was that we needed to speed up the network side. Maybe pre cache some GraphQL data. Maybe warm things up on the server before the client even opened the app.
But once we dug into the numbers we found that the network was not the biggest bottleneck. The bottleneck was actually the laptop itself. More specifically the time it takes to insert that huge volume of objects into IndexedDB during the initial sync.
The experiments
This is where the fun engineering work began. Our goal was simple. We wanted the app to render as fast as absolutely possible with all the active data already available while still keeping the sync engine trustworthy and accurate.
We tried a few paths.
We first tried delaying index creation until after the main dataset was inserted. It helped but not enough.
Then we looked at ways to batch operations differently. Still not enough.
The breakthrough
What finally worked was a shift in thinking. Instead of treating all data equally during the very first load we now sort data on the server by order of priority. Then the client inserts only the first two thousand records for each object type which covers all of the important active work the customer needs right away.
Once those are in place the app can render almost immediately because all the visible and current information is already present. The rest of the older legacy data continues inserting quietly in the background without slowing down that first meaningful interaction.
This change improved time to first display by around fifty five percent for that customer. A dramatic improvement and honestly a nice moment for the whole team because it is one of those wins that is both elegant and practical. The customer was thrilled and so were we.
What this means going forward
This improvement is live as of today and we are already seeing the smiles it puts on customer faces. Faster first load on new devices and full refreshes. A smoother feel all around.
Next up we will turn our attention back to the server. A deeper server side caching layer is on our roadmap and it is a more complex challenge. We want to let the current improvement run for a few weeks so we can watch real world data and let things settle before making another leap.
Why this work matters
Performance is not just a technical detail for us. It is a core part of what makes Success.co feel different. When the data is always ready and the app behaves instantly customers have a great experience and achieve more. That's what it's all about.
We are on a mission to deliver the best EOS® platform in the world to help companies running on EOS® thrive. The sync engine is cornerstone of our strategy to do just that.
More improvements are coming. We are just getting started. Thanks for reading.