up

Zoompf's Web Performance Blog

Note: Archived Content

This is the archived version of the Zoompf blog. Since our acquisition by Rigor, all our new research and posts on web performance are being published on The Rigor Blog

Establish a Performance Culture with Front-End Ops

 Mark Isham on September 5, 2013. Category: Internal Development

B 1221985

At Zoompf we talk with a lot of web teams doing great things, but are continually amazed by how often we hear something like this:

“I totally get the value of fast performance, but (insert name here) won’t let me spend any time on this.”

It’s little wonder so many top websites are struggling with slow performance. In a blog post from May 2013, Steve Souders from Google concluded that “The adoption of performance best practices has been flat or trending down”, despite years of well publicized industry research and evangelism to the benefits.

The lack of urgency in the web development community to improve front end performance continues to confound us, despite the large body of research showing a direct correlation to increased sales and customer satisfaction with a highly performing website. Most telling is the research from Bing showing a 4.3% increase in revenue for each 2 second improvement in their tests. In many cases performance optimization is a far more cost effective way to increase online revenues then adding new features, so why are we still waiting?

Clearly there is still some cultural inertia that remains to be overcome.

Recently, though, we’ve seen signs of hope that a movement is starting. For the last few years, the concept of the “DevOps” culture has been gaining steam, stressing a closer collaboration between development and TechOps then the historical “throw it over the wall and pray for the best” approach to software deployments. Mike Loukides from O’Reilly published a great (and free!) eBook on DevOps last year that you may want to check out called What is DevOps.

The stakes were raised again in June when Alex Sexton, an engineer at Stripe, published a fantastic article outlining his dream for a “Front-End Ops” position. Among other things, this position would “own front-end performance”, adding a level of focus and accountability to this neglected discipline. While he admits not every company can afford to dedicate a person exclusively to this role, even focusing one day a week would deliver real and measurable value.

This article is worth a full read, but here are some notable sections I wanted to highlight:

  • “A front-end operations engineer would own external performance. They would be critical of new HTTP requests, and they would constantly be measuring file size and page-load time. They wouldn’t necessarily always worry about the number of times that a loop can run in a second — that’s still an application engineer’s job. They own everything past the functionality. They are the bridge between an application’s intent and an application’s reality.”
  • “When the application’s features are someone’s priorities, and that person has a full plate, they will typically deprioritize the critical steps in delivering their application most successfully to the end users.”
  • “A front-end operations engineer will be a master of the build tool chain. They’ll help run and set up the continuous integration (or similar) server but, more specifically, they’ll set up the testing instances that their application runs on and then, eventually, the deployment instances”
  • “A front-end operations engineer would live in a dashboard that feeds them data. Data is king when it comes to speed.”
  • “The front-end operations engineer would encourage a very small tolerance for errors. Any error that happened would be investigated and either fixed or logged differently.”

And it goes on and on. The value of what Alex is proposing here can not be understated. Without clear ownership, a problem will rarely get addressed.

In some ways, this makes me think back to the early days of Software Engineering when developers focused primarily on features and testing was an afterthought. Of course everyone agreed the software should be high quality, but without clear ownership of that quality, the buck was passed around as “not my fault” when problems occurred.

The same can be said today for front-end performance. While everyone agrees its important, if nobody “owns” the problem, it rarely will be addressed. And the results seen in the landscape back this up, website performance has a LONG way to go still.

The Front-End Ops role in the DevOps culture is a well placed idea to add accountability for a known problem that has a demonstrably positive ROI benefit. Its past time to get this movement building!

Bravo Alex for a thought provoking article.

Zoompf helps web teams automatically find and fix over 400 common performance problems for mobile and desktop websites. To run a free analysis of your site, check us out at https://zoompf.com/free.

Comments

Have some thoughts, a comment, or some feedback? Talk to us on Twitter @zoompf or use our contact us form.