This Front End Ops Animal

Up front, this blog post would not exist without the amazing work and progress towards pushing the Front End Ops agenda by such trailblazers as Wesley Hales and Ryan Bridges, who gave a cool talk at the Velocity 2013 conference in Santa Clara, California. Of course there are countless awesome developers committing to the projects associated with this trend.

That brings us to an interesting point made during this talk, which is how do we serve our assets in a logical way, to take advantage of caching and minification as best we can. That is, why would we minify all of our CSS or JavaScript assets into one CSS or one JavaScript file with every build, when logic would dictate that there have only been some incremental changes to some of the discrete files that make up the larger, compounded, minified file. For example, why minify everything into one file if the source of our baseline libraries (CSS boilerplate and resets, JavaScript libraries such as jQuery and associated plugins) does not change? If we minify all of this and redeploy to one CSS file and one JS file with each deploy, we are invalidating the caching mechanism and effectively forcing new downloads or our new minified assets to all users after each deploy.

Once we have sorted out how we plan to manage our assets, only minifying and redeploying the essentials with each build, how can we baseline our progress? There's a great tool called LoadreportJS (GitHub repo is here). Additionally SpeedreportJS gives us some additional visualization tools. Both of these JS options rely on PhantomJS (which gives us a headless WebKit instance, scriptable for automated client side web page testing).

When it comes down to it, these tools give us the opportunity to get a baseline on our specific web application, and that is an essential point. Each application is its own unique animal, and we need to establish that unique point of reference, rather than compare it to other reports or trying to establish some sort of generic target performance metric, which would be neither here nor there. So a concrete, individualized zero state and target end state needs to be established for each unique application. That is essential.

So that's an interpretation of the break-neck pace of the evolving front-end ops role from here on the ground. I'm fascinated by the fast moving rate of progress in this space. I'll be doing my honest best to integrate these learnings in an effort to merge ops tasks into my more traditional front end developer work-flow.