Where did it go wrong?

Web performance is an expansive topic across many disciplines and domains — user experience, networking, platform expertise, computer science. Figuring out where to go and what to fix means covering a large surface area of potential offenders.

Due to the scope of the problem, group decision-making can break down — conversations get lost in what-ifs (“it wouldn't be slow if we'd built it with (better language)”), stuck on immovable factors (“this wouldn't happen if we didn't have to use (brand font)”), and mired in wild guesses (“if we replace (library) with (library), it'll fix the problem”).

Building a fast app is challenging, but the specifics don't require much manager intervention — an experienced team will bake best practices into their work as they go. Fixing a slow app, however, is a different problem, and requires a mix of careful planning and scrappy decision-making.

Defining “Performance”

With some problems, “performance” is just a measure of computing or network time — the duration a process takes to complete. Making gains here is challenging, but the effort usually has a clear starting point and a quantifiable outcome.

In web applications, things aren't always so clear-cut: to your users, performance is simply a feeling they have about the product. It's a measure of how long they think they're waiting to perform their primary tasks. You can even manipulate this effect without making any real speed improvements, using tricks like:

Incrementally rendering data before the entire page is ready to view.

Removing a login screen for returning users by increasing token lifetime.

Showing realistic placeholder content (ala Facebook and Pinterest) while data loads.

The breadth of options is intimidating — between all these possible targets, how do you decide what to improve, and prove that it actually worked? What if you spend the whole quarter speeding up the API, but your users don't even notice? With so much to choose from (and so little time to do it!), performance is as much of a project management problem as a technical one.

To simplify the problem, I like to break efforts into three categories: measurement, best practices, and key projects.