Web Performance Calendar

I attended the Velocity conference recently where it was announced that from next year onward there would no longer be any performance focused content at Velocity, all performance content would instead be being included in the Fluent conference, O’Reilly’s web development conference.

Whilst this wasn’t necessarily a major shock as the amount of performance content had been massively reducing over the last few years it still seemed a symbolic statement about a change in the industry. Velocity was the original web performance conference, in fact Steve Souders, while describing the history of Velocity, said that when it was first being created he was arguing that it should be called the Web Performance Conference.

So, from having its own dedicated conference, web performance has now become just another element of web development?

Does this mean that performance is no longer a thing?

There are actually a couple more bits of data that back this up.

Firstly, my own practical experience. I run a performance focussed development consultancy and over the last few years the amount of companies we speak to requiring specialist performance consultancy has reduced. That is, we are having less people speak to us simply about trying to identify, validate and resolve performance issues. Increasingly we are talking about performance as just an element of a development project.

Secondly, the experience seen over the last Black Friday weekend (2015) was that there were nowhere near the amount of high profile performance failures as seen in previous years (it remains to be seen at the time of writing whether this trend continues in 2016).

So, this suggests two possible situations…

1) Performance problems have gone away

There is a certain validity to this statement. Ahead of this year’s Black Friday we conducted a series of webinars with UK retailers of various sizes to assess their concerns and readiness ahead of peak events.

A common theme that came out of many of these webinars was that the companies were not too concerned about performance issues during peak events; not because they had resolved their capacity issues but because they had managed to get more control over the traffic they were having to manage.

To do this they had taken some important steps, all of which we have long recommended as part of performance best practice.

• Understand the nature of traffic you receive and how that traffic is triggered. In most cases the traffic was self-generated, being triggered by their own marketing activity.
• Understand the level of traffic you can handle, even if that is only based on the amount of traffic you have previously successfully handled.
• Liaise with the wider business to limit traffic by things such as staggering email marketing campaigns, coordinating email and other media campaigns to minimise overlap, extending the length of special offers etc.

It is the third item, I think, in particular that has had an impact. We are seeing the agile and devops spirit of communication being spread much wider within businesses than was the case a few years ago. It was very refreshing to hear the talk of IT departments working pro-actively with marketing departments to ensure optimal revenue.

2) People have solved their own performance problems

It has been said before, and indeed I have said this myself, that performance is like security – it requires a degree of specialist knowledge in order to understand the issues and tooling that are at the source of the issues.

This is true but there is also a fundamental difference between between performance and security. Security is a constantly moving target, there is a malignant enemy out there that is actively trying to create new problems for you, it is a consequence of illegitimate activity. Performance is different, it is a consequence of legitimate activity and once resolved should stay resolved.

To that end, once the methodologies for addressing performance issues are understood they can be applied in multiple situations. These elements are not beyond the capabilities of a good developer, given time and space to do so.

I have long campaigned for performance to be classified as a first class citizen and the impression I get is that is now starting to happen. Developers are taking these things seriously and are building them into the development process. Several companies mentioned having spent dedicated sprints or projects within the last year just focused on performance improvements and others mentioned that performance criteria were set as part of the development of replacement systems.

These two factors I would say has led to a change in culture within development. Performance has become more an element of standard development. What used to be best practice for performance is now becoming standard practice and is better understood – both as a problem and the solution – by a much wider group of development teams.

Performance problems are not going away, usage is increasing and systems are becoming more complex and delivering ever more functionality but performance challenges are better understood, tooling is in wider use and developers are giving the problem more focus.

To this end performance becomes part of the mainstream challenges of being a developer alongside the many other challenges that have to be handled when building a system. Hence we are seeing the movement away from the dedicated performance focused conference that Velocity was originally to performance being just another element of a wider development conference like Fluent.