In the past year we noted a heavy decrease in performance, espescially for new featueres we introduced. That’s because our standard testing and sign-off process did not include performance tests and we have not yet had any good ideas (that means, realizable with an adequate amount of time and effort) how to automate it.

In the last couple of months we spent a lot of time to get back to our old standard (which we even managed to outperform in some cases), take care of not ruining the performance again by testing it before releases and treat freshly introduced performance issues with the same priority as post release bugs (that means, fix them immediately).

However, this article from Google Research states the damage is done and to a certain degree irrevertable. People don’t like to use slow features, and that’s why some of our awesome new stuff wasn’t used as much as we expected. Plus, and that’s a very bad thing, people are reluctant to use features that were slow in the past, even if they are fast now. That’s why the authors conclude:

“Because the cost of slower performance increases over time and persists, we encourage site designers to think twice about adding a feature that hurts performance if the benefit of the feature is unproven.”

We definitely will.