Imagine coming into work on your first day as a front-end designer or dev and getting your Rails development system up and running for the first time. You’re really excited to start working on something in the app or website that you’re responsible for. After firing up Terminal or a Git GUI, you pull down the latest code and start making some changes to the stylesheets. It just so happens that the stylesheets are written in Sass and they’ll need to compile somehow. Since you are using Rails, that would be the asset pipeline. You hit save and go to the browser, hit refresh…
Anyone that has worked on a Rails project using Sass knows that compile time can get painful pretty quickly. When I came onboard at Treehouse I realized that we were in that boat. When I went in to start making my first style changes I had to wait 30 seconds for the page to refresh. I didn’t realize what caused it at first, but eventually learned it was the stylesheets compiling that were bogging things down. Once we started working on the redesign or our marketing site and other things, this compile time got all the way up to 50 seconds at times.
When I was coding the new marketing skin, I actually added a separate stylesheet to load into
so that I didn’t have to wait for the huge one to compile each time I hit save and refresh. It’s not very good practice to load that many stylesheet on a large production site, but it was worth it to be able to work without waiting so long between each compilation.Something had to change
As the months went on I decided that at some point we’d need to clean up what was going on in these stylesheets. I’d startup small projects with a few of my coworkers to slowly chip away at organizing our Sass and making things a bit more sane. Part of this even included deleting assets from v1 of our marketing site and app. Yikes! As I was going through this process, the compile time wasn’t really changing. The more I cleaned things up, the more I expected things would compile faster. I moved styles into smaller partials, deleted unused code, etc. Just this week I got our marketing stylesheet down to a single stylesheet again and deleted the secondary one. I figured that if I forced myself to feel the true pain, I’d find a solution faster.
I started doing some research online and stumbled across some blog posts that mentioned using sprockets instead of @imports for Sass partials. I wasn’t sure if this was a good solution or not, but the way Sprockets worked had me curious. I read more documentation on Sprockets and embarked on a journey to give them a try in our stylesheets. I’d have tried anything at this point.
Sprockets to the Rescue
The asset pipeline treats Sass @imports differently that it treats Sprockets. In the case of imports, each save will go through and compile all the imports each time, no matter which partial you’ve saved. The way that Sprockets are treated inside stylesheets is that only the partial you’ve saved will recompile and then be injected onto the page locally when you refresh. Sprockets are the default way of loading multiple partials into a single file for production. We were already using this for our JS, but the stylesheets used Sass imports instead.
An example of sprocket manifest syntax compared to Sass @import
The only slightly annoying thing about this is that you then need to import all your non-code-outputting partials, like variables, mixins, etc at the top of all the partials so that they have access to them. You cannot import them above a sprocket manifest reference, it won’t work. Although this seemed annoying at first thought, it actually makes things really simple and flat. When you open a partial, you can see what it has access to right away. If you need it to have access to the animation gem, just @import animation at the top and its ready to go.
On the left you see an attempt to import above the sprockets manifest. This won’t work, you must start the file with Sprockets at the top, like on the right.
After getting all the stylesheets converted and adding in all the necessary imports, I began testing how it effected compilation. You won’t believe the difference it made. This change will probably have a larger impact on our front-end development than anything else ever has. Once I changed a file and refreshed the page I wanted to jump for joy, giddy like a school boy. The page compiled and refreshed in only a 2-3 seconds! That’s an improvement of 47 seconds. This is huge.
Designers rejoiced!
To put this change into perspective a bit. If I was spending my whole day in code, changing styles or adding new pages, I might refresh 50 times in a day. This is in no means exact. If each compile was taking an average of 50 seconds before, that’s about 41 wasted minutes per day, and about 164 wasted minutes per 4-day work week, and 656 minutes per month, and 7,872 minutes per year. That’s almost 16.4 8-hour work days per year! Across a design team of 9 designers, that could possibly be 147.6 work days wasted in a year across the entire design team. When you only work a 4-day work week you have to be more efficient, so the new 2-3 second compile time is much better!
Now our designers, and any other designer/front-end dev that happens to read this blog, can save the sanity of their entire team by thinking twice about how they’ve compiled stylesheets in the app or site they are working on. Don’t just let things be as they are, always challenge and refactor things you’ve done in the past.