A (better) alternative to @import in child themes

Traditional guidance (including on this site) when creating a child theme has been to use an @import rule in style.css to import the CSS from the parent theme, so that you can then add your own style rules after that.

A recent post from Konstantin Kovshenin has had me rethinking that. He highlights that using an @import rule requires the two stylesheets (the child theme and the parent theme) to load in series rather than in parallel, which adds time to your page load speed.

To overcome this, he recommends enqueuing the parent theme stylesheets instead, so that the two files can download in parallel, reducing your page load time. You can drop this snippet directly into the child theme’s functions.php without needing to change anything:

Note that because WordPress loads the functions.php file of your active theme before going on to load the rest of the theme, having this snippet in functions.php will ensure that the parent theme CSS is still loaded before your child theme CSS (important if you want to redeclare any existing CSS rules).

Because the inclusion of the the parent theme’s CSS will only be of use while the child theme is active, it is very appropriate to put this function in the functions.php file of the child theme.

So, whenever you create a child theme in future, seriously consider enqueuing your parent theme’s CSS instead of @importing it.

2 thoughts on “A (better) alternative to @import in child themes”

  1. Will Patton says:

    Hey Dave,

    I too think that including the parent styles via enqueue rather than by @import is a much better approach for performance reasons. Also feels to me that it fosters better coding standards which have an emphasis on improved performance which can only be a good thing :D

    Including them separately and parallelizing the download makes much more sense however nothing beats serving up only a single minified css file. All the major caching plugins support combine/minify but I have been in the situation (and so have you) where caching plugins are not allowed. In those situations I suggest people to use a plugin called ‘better WP minify’ which will handle it and is allowed on hosts that do not require caching plugins. I’m pointing no elbows or anything here but I’m talking specifically about WP Engine lol.

    And just as a sidenote there are some ways of flattening css @import statements serverside with very minimal performance impact (less of an impact on it than an @import statement has anyway). I use Google’sMod_pagespeed module on my servers which is capable of doing this on-the-fly for me. It’s also got a TON of other extremely useful performance benefits too but I think I’ll save my ranting about the benefits of mod_pagespeed for another day lol

    Great suggestion, man, hopefully some others will take note and start enqueuing parent styles in future :)

    1. Yes, it can be a pest to have limitations placed on you like that, but they do it for a good reason I suppose, so I can’t get too annoyed about it.

      While I get the motivation behind a single minified CSS file, I’m actually not that keen on them, because I like keeping things organised into appropriate CSS files, and being able to read them with ease, even if I can do that myself by viewing the files on the server, rather than the minified version served up in my browser. It bothers me when I’m trying to inspect someone else’s code and I can’t (easily) because it’s minified. I think I’d rather take the performance hit and have everything legible on the front-end, both for me and for others.

      Interesting news about mod_pagespeed though. I’ve not looked into that before.

Leave a Reply