Frontend Performance Tuning

I recently chatted with a potential client about some front-end work that I might be able to help them with. I was asked if I had any experience with front-end performance work, specifically with React. I chewed on this for a moment before answering that I didn't.

It's pretty rare that I've actually had the opportunity to work on a front-end where the actual performance was a pressing issue beyond anything else, where React and the UI is being pushed to its limits. The kind of situation where the UI/UX is so complex that the UI chugs or is unresponsive—whether due to the sheer amount of data in the DOM or complex interactions etc.. But, nearly every time I'm working with React, performance is well above product requirements. Often, issues of performance are having to do with bottlenecks in backend service(s).

This realization made me feel a bit unchallenged and curious about what work I could find that might push this boundary for me. From observing some of the clients I've worked with (and other folks' experience on the teams I've been on), it seems that this kind of work appears more commonly for larger companies where they:

• a) might actually have front-end performance issues
• b) have a budget to improve front-end performance, even if those changes would be (subjectively) negligible to users.

Note that this is just an observation I’ve had, working for client companies ranging in size of 2 people to 3000 people (and plenty of legacy code).

Many years ago, my first boss at my first programming job said that most programming for the web is mostly building forms (and of course, displaying the data from those forms). He was being reductive to make a point—but at the end of the day, the statement did help me wrap my head around approaching web programming. As such, I think it's pretty uncommon to find a user interface that isn't related to form-esque CRUD operations, has a complex UI and user experience, and where performance is a problem. Web applications like Figma (and its use of web assembly) come to mind.

Another caveat in all this is that a lot of the time that I'm working on various front-ends, nobody, including myself, is testing for low-powered or lower-end devices. There's a pretty evident bias as everyone working on the front end is usually working on some kind of high-powered MacBook Pro, and it's altogether too easy to forget that many people are either on their phone or are likely on a much lower-powered device.

Even if performance is a problem, it is often forgotten (just like accessibility, unfortunately)—well, at least until a company has enough budget (or legal ramifications to deal with, in the case of accessibility) to sand down these rough edges. Perhaps this slow-to-move attitude is somewhat in line with the nature of developing for the browser—it's easier to be reactive rather than proactive. The rigorousness of schemas and database security and other such things aren't as pressing. Maybe there's been a history of flexibility and leniency that puts performance in the backseat at times. I don't know.

I hope I come across this sort of front-end work in the future, even if just for my curiousity’s sake. It might be more rare than I think.