Front-End Optimization, Monitoring & Deployment Engineer All-In-One
01 Jul 2013
TL;DR
Why doesn’t front-end ops need to be a separate role? Because the developers building your pages know those pages best, know what tooling is needed and should be thinking about how those pages perform. How do you get those folks interested in and caring about performance and ops? Well, good luck with the ops part, but to get developers to espouse performance, create fast-feedback loops that allow performance data to be visualized. That visualization is the enzyme that allows digestion of data. Once you have that feedback loop established, keep the data fresh and the atmosphere enthusiastic.
The Back-story
A recent article in Smashing Magazine about front-end ops struck a chord with me. The piece, by Alex Sexton, argued in part that front-end ops should be a distinct role, differentiated from front-end development. While it was truly refreshing to see an enumeration of these tasks, I felt conflicted about the introduction of a new role. It has taken time, but in my current role, I have been able to provide an environment where the front-end developers can perform all the tasks tasks Alex mentions. I come from the development side myself, but am passionately interested in operations. I have done my best to create a work environment where we can do all the things that make us professionally satisfied, and, unsurprisingly, those same things make our products better.
Enabling Your All-In-One
The first step to enabling this environment was to set the foundation: continuous delivery. Just to clear the air, we’re not delivering to production continuously and our process isn’t perfect, but we’ve done enough to create a feedback loop for the team. The build process takes care of everything from minification, concatenation, and running Compass to the automated functional testing grid, deploying wars, and flushing/warming caches. It has been my experience that once CI is configured, deployment mechanics fade into the background. The system is not self maintaining though. Instead of creating an explicit role to keep things running, team members who are interested in contributing self-identify and I assure time is allotted. An analogy I have frequently used is to the flywheel in a single piston engine - the engine wouldn’t be able to continue to function without the flywheel.
After automating our deployment pipeline, we shifted our focus to monitoring. RUM data is one of the most enlightening pieces of monitoring information we can collect from the browser. The initial effort of implementation was low because the dozen lines of javascript to access and calculate stats from the Navigation Timing API is well defined. With basePage (responseStart to responseEnd) and frontEnd (responseEnd to loadEventStart) data* for all our pages, the team has the measurements and historical data to determine if we’re making the site faster. Once RUM monitoring logic is embedded in pages, it’s largely self-sustaining - though there is certainly more to quantifying perceived page performance.
This brings me to an important point about how we use monitoring data. We use graphs to visualize the performance of our most popular pages. Those graphs don’t just sit on a web page somewhere, they gets displayed on a dashboard in a highly trafficked area. The data is refreshed every minute and typically shows the past week. This helps keep the topic of performance in the weekly and often daily conversation. I won’t go into the cultural benefits of using dashboards to visualize data, but suffice it to say we’ve seen those benefits first-hand. If you want a cheap dashboard display, check out this post about building a kiosk.
As I alluded to above, tracking page load performance is only raw performance data and if the front-end team’s interest ended at RUM data, we would be doing ourselves a disservice. For example, what if content below the fold was loaded before the content above the fold or if the first image in the homepage carousel was the last to load? Enter WebPageTest.org. This free and open source tool gives the front-end developer all the measures they need to understand the anatomy of a page load. Especially of interest is the ability to see a filmstrip of page load progress snapshots correlated to the waterfall chart. Here’s a view of the Amazon.com homepage first view. The team saw the value of this type of analysis immediately, though I will admit that it is the least well integrated into our overall process, and therefore requires the most overt effort to sustain. We are still in the process of establishing a good cadence of WebPageTest use, but the ability to compare filmstrips from test runs on different dates allows us to benchmark the gains.
Separating the front-end developer from performance and optimization concerns will only do the developer - and team - a disservice. I would argue that it is leadership’s responsibility to make time for these activities. Possibly more important is to create a feeling of purpose, imperative and enjoyment for these tasks. While premature optimization is a bad thing, a well rounded developer will consider performance ramifications when laying out a page. The team will build performance into the page, much the same way quality should be built into a process.