The Problem We Were Actually Solving
We were trying to solve the problem of user adoption in a market where traditional payment processing systems wouldn't work. The catch was that most of our users, being in a highly restricted country, would be accessing the system through low-end devices and networks, which made performance a top priority. The last thing we wanted was a clunky admin dashboard that would drive users away.
What We Tried First (And Why It Failed)
Initially, we built the admin dashboard using a well-known UI component library that touted itself as "extremely fast" and "reusable". We thought it would be a good idea to just drop those components into our design and call it a day. However, as soon as we started adding features, the dashboard began to slow down dramatically. We'd get these intermittent errors like "Cannot read property 'key' of undefined" which we thought were related to the data we were passing down, but it turned out to be a prop mismatch in one of the components. We spent hours debugging, and at the end of the day, we realized that we had fallen prey to the pitfalls of component bloat.
The Architecture Decision
I started to rethink our approach, and we decided to abandon the UI component library in favor of a custom-built design system. We opted for a strict TypeScript setup, which forced us to be more intentional about our code. We broke down the admin dashboard into smaller, reusable components that could be easily tested and maintained. I also implemented a performance budget, setting a maximum number of DOM elements we'd allow in our dashboard at any given time. We used a metric called "Time to Interact" or TTI to measure how fast the dashboard responded to user input. This metric became our north star as we continued to optimize and refine our design.
What The Numbers Said After
After implementing our performance budget and custom design system, we saw a significant improvement in our dashboard's performance. Our TTI went from an average of 2.5 seconds to just 400 milliseconds. We also saw a noticeable drop in the number of user complaints about the dashboard being slow or unresponsive. With our custom design system in place, we were able to push out feature updates and bug fixes at a much faster pace, without having to worry about introducing performance regressions.
What I Would Do Differently
If I had to do this project again, I'd still opt for a custom-built design system, but I'd take it a step further by implementing a more robust testing suite. I'd write end-to-end tests to verify that our performance budget is still intact after each new feature or update is pushed out. I'd also set up a continuous integration pipeline to catch any performance regressions before they make it to production. Lastly, I'd invest more time in educating our team on the importance of performance budgets and how to measure them effectively, so we can avoid the pitfalls of component bloat and slow admin dashboards once and for all.
Top comments (0)