Author: Brent

Here at Pedago, we take a hard look at the performance of our applications so that our users don’t have to experience any troublesome hiccups (or “jank”) that might otherwise sour a sweet learning experience.

While “performance” can cover a wide array of metrics, we tend to be extremely critical of browser overhead (script execution, rendering layout, and painting). While others have covered optimization of these metrics in great detail, we came across an unlikely jank-vector that we thought was worth mentioning.

When analyzing CSS performance in relation to browser lifecycle, there are a few notorious styles (eg: border-radius, box-shadow, transform, backface-visibility, etc) that tend to slow down frame rate. Some of these are obvious as they dramatically influence the rendering process or add additional calculations for stylistic ooomph. One might be extremely likely to overlook the rather mundane text-transform while focusing on that list, though.

We had several elements each containing a finite number of additional elements that all were performing CSS-dictated uppercasing on their text content. Now, this might not be a significantly intensive operation in itself, but combined with some excessively spastic scrolling, it degraded the user experience somewhat significantly. After we updated the content to be rendered in uppercase without the need for CSS text transformation, the improvement was obvious.

Here’s how things looked on a common mobile platform, prior to the change (FPS is the key metric, with 60FPS as an ideal target):

As you can see, we were barely hitting the 30FPS threshold and often even missing that window. Here’s what we observed after we removed the relevant text-transform styles:

As you can see, we’re now closer to consistently hitting that golden 60FPS benchmark! Granted, we were probably abusing a CSS style that was intended for narrower application, and the DOM of this particular page meant that there were a lot of them, so your mileage may certainly vary. However, this might help serve others in the war against jank!

Like any good startup, we try to leverage off-the-shelf tools to save time in our development process. Sounds simple enough, but the devil is in the details, and sometimes a custom solution is worth the effort. In this post, I’ll describe how and why we replaced the Rails asset pipeline with a Grunt-based system.

In the Beginning…

Early on, we embraced AngularJS as the foundation of our core application. We started prototyping using the Yeoman project and never looked back. If you’ve never used this project before, I highly recommend checking it out. It will save you time and tedium in setting up a development ecosystem. We fell in love with the Bower and Grunt utilities as a way to manage project dependencies and build pipelines, and we found the array of active development on the various supporting toolsets impressive. We were knee deep in NodeJS land at this point.

After we stubbed out a good portion of the UI on mock data, we had to start looking towards building out an API that could take us into further iteration. Ruby on Rails was proven and familiar, and we knew how to carve out a reliable backend in no time flat. Additionally, we wanted to take advantage of some proven RubyGems to handle common tasks for which the NodeJS web ecosystem hadn’t fully established itself. Some of these tasks include handling view responsibility, and as such relied on Sprockets for asset compilation.

At this point, we had an AngularJS project, built and managed with Grunt, contained within a Rails project, built and managed with Rake and Sprockets.

Trouble in Paradise

We quickly found ourselves hitting a wall trying to manage these two paradigms. As have severalothers.

Our hybrid Grunt + Sprockets asset pipeline included multiple build processes and methods of shuffling assets. The more we tried to get these two jealous lovers to play nice, the more they fought. Ultimately the final straw came down to minification-induced runtime errors and the lack of sourcemap compilation support in Sprockets (while somewhat supported in an on-going feature branch, sourcemaps hadn’t made it into master and required dependency changes we weren’t ready to make quite yet).

At this point it became apparent that we were wasting precious cycles dealing with things outside our core competency, and that we needed to unify these pipelines once and for all.

Unification

Our solution: say goodbye to Sprockets! We have completely disabled the traditional Rails asset pipeline, and now rely on GruntJS for all things assets-related. The deciding factors for us were the community activity and the flexibility the project provided. Here’s a Gist of our (slightly sanitized) Gruntfile.js powering the whole pipeline.

How we currently work:

We don’t use the Rails asset helpers…at all. We use vanilla HTML for our views as much as possible. Attempts to use the Rails asset helpers ended up being overly complex and ultimately felt like trying to work a square peg into a round hole.

Grunt build and watch tasks handle the the pipeline actively and passively. In development, we use the wrapper task grunt server to launch Rails along with our watches. Source and styles are compiled and published directly to Rails as they are saved. Likewise, unit tests are run continually with output to console and OSX reporters.

LiveReload refreshes the browser or injects CSS whenever published assets are updated or otherwise modified.

We no longer require our Rails servers to perform any sort of asset compilation at launch, as they’re now built by CI with the command grunt build prior to deployment. Nothing structural in our build deployment process has changed (in our case, using Bamboo to deploy to Elastic Beanstalk).

With the above, we are now constantly testing using the assets that actually make it into a production environment, with sourcemap support to handle browser debugging sessions. Upon deployment, Rails instances do not need to pre-process static assets, reducing warm-up time.

Ultimately, the modular nature of the Grunt task system ensures we have a huge array of tools to work with, and as such, we’ve been able to incorporate all the nice little things that Sprockets does for us (including cache-busting, and gzip compression) and the things it doesn’t (sourcemaps).

DIY

Feel free to steal our Gruntfile.js if you’re looking to adopt this system. We’ve also cobbled together a list of Grunt tasks that we’ve found helpful:

grunt-contrib-uglify – handles all JS concatenation, minification, and obfuscation. Despite adhering to AngularJS minification rules, we’ve found issues with the mangle parameter and must disable that flag when handling Angular code. Uglify2JS is also providing our sourcemaps.

grunt-contrib-compass – we only author SCSS and rely on Compass to handle everything concerning our styles, including compilation and minification as well as spritesheet and sourcemaps generation.