Sometimes (well, always) products evolve, face the new requirements, and your legacy views designed in old good times start to work not so fine as customers expect. To solve this you have two ways - rewrite everything from scratch (which usually makes stakeholders furious) or try to improve the existing codebase to ensure it meets the new expectations. Here we will tell you how we started to suffer from performance problems in Wrike Workload - one of our most heavy and complex views in our product, how we improved its overall performance in a few months, and what tools and technologies we used for that.
When developers are talking about scale issues, they usually mention auto-scaling groups, load balancing or shedding, bundle size, code splitting, chunks caching, availability zones, and so on: not everyday pieces of a codin' cake. The truth is that, however, scale issues are not so distant as they may seem. This talk tackles user experience and design patterns at scale, from the perspective of simple elements, like a picker (HTML select), in large applications. How does such a trivial element affect overall scalability?
Can we count CPU instruction for JavaScript and websites? Can it be a more reliable performance metric? Could it be be a less noisy Lighthouse buddy? Can we wrap it into a CI feedback loop for a developer who cares? Why would we do that? RAIL like and Lighthouse metrics are amazing, but they depend on networking and can be noisy. Let's try to build a workflow where with every commit we can measurably improve performance for our users.