Web Performance Calendar

The world of web development is strikingly different today than it was when I started my career. Today, you don’t usually need to argue for performance, everyone knows that it’s important. Through efforts like Velocity, the Performance Advent calendar, and local performance meetups, the word has gotten out loud and clear: performance matters. It matters to your users, it matters to your bottom line. That’s a great thing.

Companies around the world now take web performance seriously, though there are still many questions around how to implement a culture of performance in the industry. Many companies rightly start by having a performance team. It was like this when I was at Yahoo, and it’s like this at Box today. The performance team is usually tasked with scavenging the web application and finding ways to improve performance. They investigate and keep tabs on the total number of HTTP requests, the total byte size of various types of assets, and measure latency. They look at endless amount of charts to figure out what’s going and maybe even have automated testing that tracks YSlow or PageSpeed scores. They file bugs against other developers to fix bottlenecks. They investigate CDN usage and opportunities for tuning.

Yet should the performance team be the only people who care about performance at the company? Is it really just the responsibility of a subset of developers? Absolutely not, and this is where some companies struggle to get a good culture of performance in place.

What we do

If you think logically about what web application developers do, it generally boils down to one thing: implement new features. Yes, there are bugs to fix (the result of someone’s failed attempt to implement a new feature), but primarily our job involves adding new features to a product. That, in turn, means adding more code to the product. Adding more code to the product necessarily makes it slower (more bytes is slower than less bytes). Somewhere else in the company you have a performance team whose job it is to make things faster. You make things faster by removing code. And therein lies the problem. Who wins this tug of war? Where does performance fall in the list of priorities vs. getting new features out?

In truth, the only way to create a culture of performance is to make it everyone’s responsibility. I say the same thing about accessibility, maintainability, security, scalability, and any other measure of quality code. Unless all of these things are everyone’s responsibility than it ultimately falls down to a smaller group of people (the performance group, the accessibility group, etc.) to be watchdogs for everyone else.

The three steps

That doesn’t mean these groups are good or effective, it does mean making sure everyone is on the same page regarding priorities and how effective features are built. While performance is an important aspect of development, it’s not the only consideration. To that end, I prefer to build features using a three-step process:

1. Make it work – You cannot ship something that doesn’t work, so this is always top priority. Making something work means it is completely functional and meets criteria related to security and scalability (something can’t be insecure or not scalable and being said to “work”). At this stage, I don’t worry too much about performance or anything else other than getting some to a fully functional state.
2. Make it pretty – The next step is to focus on the aesthetics of the feature. That means visual design, interaction design, accessibility, and as well as the maintainability of the code (also a kind of aesthetic). Knowing that the underlying functionality works frees you to make changes and be confident that, if something breaks, it has to do purely with the aesthetic changes you’ve made.
3. Make it fast – This last step is going back and measuring what you’re made to determine if it’s fast enough. Often, adding the visual components will add bulk to the feature and that can slow it down. This is the point where you look at where you can trim the fat, sand down the rough edges, and make every byte count. That may mean revisiting some of the design decisions or even the basic algorithm or implementation.

Using these three steps during development helps me to focus in on the goal of my work, which is to create a new feature that is aesthetically pleasing to the end user and also fast enough to satisfy whatever metrics we are tracking along with it. Each step brings along its own set of responsibilities.

Whenever you start to mix steps together, that tends to be where tension is introduced. If you make the fastest possible thing to start and then add UI on top of it, you inevitably slow it down and upset everyone. If you start by working on getting the UI correct but don’t have underlying functionality working, you can get caught in a tight spot of not having enough time to make the thing work.

Conclusion

Building a culture of performance inside of a company is important. Just as important is how you build it and what the expectations are within the entire development team. In the end, performance needs to be everyone’s responsibility, not just a few people on one team. A performance team is great to have as a resource and a group that keeps everyone else honest, just like a security team or an accessibility team. But ultimately, we need to get everyone on the same page in understanding where performance fits into the development lifecycle.

The three steps I laid out, make it work, make it pretty, make it fast, are a good way to get started. Focusing on the process of development, understanding when certain things need to be focused on, helps everyone do their job more effectively. Even if you don’t use these exact three steps, make sure you have a good development plan in place so there is no doubt as to when performance is to be focused on.

We all can’t be doing everything all of the time, so understanding how each aspect fits into feature development ensures the highest quality all around.