Filed Under: performance optimization

How to combine SCSS & CSS Files

If you're looking in pagespeed insights or in a critical render path analysis, you may see that there are many scss and css files being called prior to your initial render. Sometimes it makes sense to combine these into a single or several files. In general, you want to have one fast first render that paints the above the fold content. 

In the ideal world, we'd inline the critical css and dependency free (vanilla) javascript for a fast first render. However, when it comes to most modern websites that continue to blur the line between web pages and web apps, this isn't always possible: large css frameworks are used to generate the site layout, and jquery and other javascript functions provide core functionality or are otherwise needed for interactivity to make sense (e.g. swipe a slider). 

Loosely speaking, it goes from parse > style > script > paint. This is a big simplification, but a useful shorthand. Read more here and here.

Combining SCSS & CSS files can reduce the number of requests, and allow all the styles to be parsed and evaluated as one, rather than allowing many small re-styles as each subsequent css file arrives. Lots of Shopify themes don't necessarily lend themselves well to inlining critical above the fold CSS only, and it ends up being a net improvement to just combine them all.

DON'T BE DUMB. DO IT ONE AT A TIME.

If one of your changes breaks the SCSS compilation it can be very difficult to figure out where/what is causing the issue.

IT IS IMPORTANT TO KEEP THEM IN THE SAME ORDER.

Ideally this wouldn't be the case, but due to the cascading inheritance and specificity principals of CSS, the order matters. 

Look in theme.liquid to see the order they're called, probably looks something like this:

Here's the process: Cut and paste each file into one main file, keeping the order the same, and noting in comments the name of the original file that was the source of that section.

Then remove the call from theme.liquid for the resource.

We usually leave the file in place and a small note to posterity. 

Check the front-end each time. Changes can be subtle. Fortunately when they're split out like this they usually give a good indication of what to check (e.g. swiper.css -> check sliders etc).

And that's all there is to it - happy optimizing!