We often talk about fixing web performance in existing solutions. I’ll try to underline the problem of why it happens and how to predict the need for fixing performance problems at the later phases of a project development. Hence, avoid the need to fix performance, and be fast by default.

But first, why are we even interested in performance matters? It’s worth mentioning that there are lots of reasons: for business – it’s money, for developers – creating great product to use (we are all good people and want to create amazing experiences), for users – enjoying the application they were looking for.

Unfortunately, performance isn’t the first feature owners/managers/developers are going to implement in their projects. For existing products, it’s more important to add visible changes that bring more revenue. For startups – it has to blow the mind with the idea and be sold, improved, etc (another story). When you raise the question about performance, everyone says: “That will be fixed later, it’s time to push this feature out of the door!”.

Note: Not all processes are organized like this and not all teams work like this, but the problem is still present and a lot of teams face it. We can visualize this process really simply.

Feature after feature development flow diagram

Feature after feature development flow diagram

After a “Performance audit”, only one step is left before delivering a product – fix the performance issues. But here is the problem: developers were concentrated too much on delivering features, so concentrated, in fact, that they sometimes forget about basic software development principles. So, their solutions look like:

https://twitter.com/mr_mig_by/status/1060267034422976513

An architecture problem isn’t just a problem related to performance. It’s related to the product in general. With a poor architecture one day you might find yourself completely stuck. Adding new a feature or fixing a bug might take days or weeks. Tightly coupled, untested components can be really hard to change and negatively affect the application’s bottom line. @unclebobmartin has been underlining all these problems in great detail for decades. Hence, performance problems detected at the end of a project aren’t so easy to fix. We can borrow some Clean Code principles from Bob Martin, especially the Test Driven Development approach, and apply them to performance problems.

Applying these techniques, I call Performance Driven Development. With Performance Driven Development (PDD) developers deliver fast performant product during each feature development iteration. We only need to follow a handful of rules in order to reach this goal.

1. Track

Metrics for performance budgets by addyosmani

Metrics for performance budgets by @addyosmani

First, track your performance scores from the first day of feature development. There are amazing tools like Lighthouse or services like Treo.

Lighthouse audit in chrome dev tools

smashingmagazine.com audit on treo

2. Budget

Then, set a budget for JavaScript or CSS bundle sizes using size-limit or bundlesize. This is really important because, as Sam mentioned, the time to parse and compile your code will hit your performance really badly.

Note: This article about performance insurance can help with these two points.

3. Empathize

Third, emulate real user conditions and environments on a regular basis, for example once a week. Keep in mind something people rarely consider: it’s not enough to test with a clean environment, because users have different extensions turned on and can load either CPU or network with background tasks.

You can use the slowest PC/laptop/phone in office to run web application you are working on.

@slightlylate went even further and tested on Android Go, KaiOS devices.

Moreover here is chrome extension for you which can help emulate real users conditions. It’s open sourced, so issues and PR’s are welcome.

Sloth demo

And last but not least, don’t forget about clean code! PDD isn’t a new idea, @csswizardry also advocates this kind of process in his article. So, organize your process to develop good software, track and fix performance from the earlier phases of the project. It will help you eliminate performance issues earlier and assist you in delivering a great product.

Feature development cycle

Feature development cycle

P.S. If you already have this kind of development flow, don’t hesitate – share with us 🙂

ABOUT THE AUTHOR

Artem Denysov

Artem Denysov (@denar90_)

Software Engineer: @Ciklum, @EPAMSystems • Makes developers and users lives easier helping them with #webperf • Speaker • @__treo advocate.

You can find him on Twitter or GitHub

3 Responses to “Performance-Driven Development”

  1. joe GANNON

    Great article.

    A few points

    1. While I agree that development should be working this way, I feel that somehow the entire team needs to get on board and do their part as well. This needs to start at the top of the organization. There is opportunity for UX to contribute to this effort as well as product owners rather than simply leave the burden to UX. There also needs to be effort by dev to reach out to UX and product to educate them on this.

    2. Your point about testing with real connections makes sense, but I’m unable to do a Lighthouse report emulating various connection speeds. I tried the open source tool you mentioned but would love to have various speeds such as WPT.

    3. Would love if there was a place to share ideas on how teams out there are moving from A to ideal state as you mention. We need more of this dialog and a way to engage all parties beyond developers if we are to be successful.

  2. Joe Gannon

    OOps – I meant …here is opportunity for UX to contribute to this effort as well as product owners rather than simply leave the burden to developers.

  3. Frank van Gemeren

    Thanks for your article.

    I also wrote a blog post about keeping track of performance, and other non-functional requirements, during development at trivago: https://tech.trivago.com/2018/10/12/building-fast-and-reliable-web-applications/ .

    We’re currently working on tracking performance-over-time per page load to answer questions like “are we having memory leaks”, “how’s our reflow/repaint after 2, 5, 10 seconds” etc etc.

    An idea that I just had: maybe we can add it to RUM. It’s currently only a puppeteer script running as part of our CI process.

Leave a Reply

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>
And here's a tool to convert HTML entities