You built a web product, and people like it! Your customer base is growing, and you're releasing new features at twice the rate you were last year. But as traffic and customer demands increase, your app starts to get...slow. Your competitors don't beat you on features, but it seems like everything they build just runs faster. Customers and execs are grumbling, your integration tests take hours, and sales demos begin to feel a little embarrassing.
But, good news! This quarter, you're going to fix it. You have buy-in from execs to prioritize performance, and now you have the team and time needed to tackle these speed issues.
Everyone's excited at first — they've been asking to fix these issues for a while now. But then, the project gets complicated. It turns out your developers have dozens of ideas for how to improve performance, and they range in scope from replacing some icons to porting the entire thing to a new framework. One quarter isn't enough; you'll need a year to finish everyone's ideas...and you're not even sure they'll work!
Your efforts begin to stall, and your performance gains are either illusory, or hard to prove...
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.
Measurement
Measure the performance you care about. Doing this ASAP will give you insight into your problem areas, and allows you to paint a clear before/after picture for execs. This process will look different for every organization, so focus on the most important aspects of your business and monitor them:
Make sure you cover the basics, the simplest metrics to gather. Database performance, response time, throughput, time-to-first-byte. A tool like New Relic is ideal for recording these values.
Log the total time to load and render data for high-value pages.
Log the time taken for common user actions like “add to cart”, “view dashboard”, and “load new messages”.
Monitor high-value pages (especially marketing pages) with WebPageTest, and record basic results like the Speed Index in a spreadsheet every week. Do the same for a few of your competitors’ sites!
A warning: Measuring performance is exasperating — making sense of the noisy data from your tools requires patience and focus. It's easy to make mistakes in your monitoring, mistakes that can set you back until the next release if you don't catch them early.
After an acceptable amount of monitoring, your team can group up and find the worst offenders. The tools can only provide you with hints, but you have to apply your own criteria to make them actionable:
Is it critical? Your biggest spike isn't necessarily your biggest problem if it doesn't align with organization goals — for example, if customer acquisition is a priority, sign-up and billing issues may outweigh slow admin screens.
Is it difficult? Don't apply an all-or-nothing approach to performance. Be tactical in prioritizing high-ROI tasks, and don't hesitate to throw trickier ones into the icebox.
Is it mysterious? Mysterious issues have an unknown difficulty — spike them quickly (create and assign research tickets) and apply these three criteria again after some discovery.
Monitoring is my first stop on this list because it has a low initial cost, but takes time before it pays for itself. The sooner you start, the better! While you’re monitoring, you can move onto the next area...
Best Practices
Developers can usually take a look at your app and identify a few obvious improvements just based on web best practices. Maybe you're not gzipping all your assets, maybe Cache-Control max-age is too short, maybe you have obviously poor time-to-first-byte. You can spot these issues with widely-available resources like performance checklists, dev tools, and audits. While the issues you find may be difficult to fix, they’re usually easy to understand and plan around.
The best part about applying best practices is that you don't have to wait for measurement to finish — you can begin triaging these problems as soon as your team has the bandwidth. The tasks you write will range from a simple configuration change to a tricky dependency removal, and they make great tickets for developers at every experience level.
Make sure that your tasks have a clear acceptance criteria — if you have a ticket to "Gzip CSS files", it needs to include instructions for verifying that the files are gzipped. If you want to reduce unnecessary renders in a messaging UI, set up a specific flow that produces a similar render count each time, so a testing dev can reproduce it and verify the fix. It's important that if one developer is making a performance improvement, someone else in your organization can verify it. Otherwise, it may provide no benefit at all, or worse, break the user experience.
When best practices lead you astray
Best practices are signposts along the journey, but they’re not always the best directions for your journey. For example, most audit tools will rank pageweight as your largest problem, but there are scenarios where this isn’t as critical as the tool suggests:
You're always requiring sign in, allowing users to preload assets on the login page.
Average sessions last hours, making the initial load a smaller relative burden.
Your heaviest assets (fonts, analytics, images) load in the background, and don't block critical tasks.
This doesn't give you license to ignore performance problems at will, but remember your goal: Get the maximum effect from the minimum effort. Make sure the performance advice you take makes a big impact on your application.
Key Projects
With help from stakeholders across your organization, build a list of features that just don't feel fast. Whenever possible, try to attach numbers to these slowpokes — either with monitoring or manual testing and timing. Hopefully, you'll have a few clear offenders that you can target.
Once you have a prioritized list of problem areas, have both technical and user-experience team members audit them. Sometimes technical people can spot the obvious problem and find a fast solution, other times you'll need to reach a compromise like displaying placeholder content, loading less data at first, or adding a spinner.
Planning and executing key projects requires creative problem-solving, which makes a one-size-fits-all approach ineffective. Encourage your team to be imaginative and search for multiple solutions.
What’s next?
Keep it up!
Maintaining performance is an evergreen task — you'll never do it all, and you'll find (and create) more issues as you go. Establish a regular process for spotting and triaging these problems, fitting them into your work as needed.
5 Misguided Principles of Web Performance (And How to Revise Them)Tim Grant, Techbeacon A refreshing look at common web performance beliefs and where they go wrong. This article covers some of the mistakes you can make when auditing performance, and guides you around them. (There's a great TLDR at the bottom if you're in a hurry!)
Building a Web Performance CultureGreg Heidorn, Cars.com Insightful overview of how a real team dealt with performance creep, and the challenges they dealt with along the way. This article highlights the organizational and tooling issues that can make a performance overhaul so difficult.
Fostering Web Performance CultureJosé M. Pérez A pragmatic approach for approaching performance as a contributor, and introducing new processes to a team.
