Made Tech Blog

Optimise SCSS Sprockets Performance in Rails

We build rich websites at Made. In production, the SCSS we write is precompiled, minified, gzipped, and served from Amazon S3. However, in the development environment we’re without any of this magic, and the rails app server can sometimes feel like it’s ground to a halt.

Why is it so slow?

Sprockets will refresh every new or updated asset on every page load. This alone could be the cause of your slow down, depending on the number and complexity of your SCSS files. However, if that’s not the case, and your SCSS is relatively small then you probably aren’t using Sprockets to its full potential, and relying too much on LibSass to compile all your SCSS into one file.

How to improve that first page load time

Your main performance gain is going to come from better organisation of the number of files you @import in each of your SCSS files so:

Now you have stripped down your SCSS imports, the next gain is to, if you aren’t already, use the full power of Sprockets.

As mentioned earlier, Sprockets will recompile every updated or new asset on every page load, so by using Sprockets properly only the file you’ve changed or added will get compiled. This is most evident in the of your rendered HTML. The second example is more performant, because it only refreshes the individual files, which can then be cached out by the browser.

Finally, you ought to be really stringent on the 3rd party vendor mixin library imports, for example Compass. If you simply “@import ‘compass'” you get a whole lot of cruft you might not necessarily need, so you should only include the features you need.

How have we achieved better SCSS compilation perf. in our apps?

We have improved our precompilation time by abstracting all our common @imports into one common file, which then gets included at the top of each new SCSS partial.

Additionally we cut down the number of 3rd party imports – mainly Compass – to the bare essentials.

Were there gains?

Once all the SCSS files had been moved over to this way of working the gain in page load speed was instantly obvious.

Pages that were taking 50 seconds to load were now rendering in a fraction of the time.

When you think about the bigger picture, all those wasted seconds waiting for a page to load over the course of a project are really going to add up.

Whilst in front end development, say you reload a page 100 times during its build, and through better stylesheet management you save an average 20, that’s 34 mins. That 34 mins over the course of a project, with say 10 unique pages soon becomes 6 hours. 6 hours lost to page loads which could be easily saved.

So, saving this time will ultimately benefit everyone.

About the Author

Avatar for Seb Ashton

Seb Ashton

Lead Software Engineer at Made Tech