How I Shrank my CSS by 84kb by Refactoring with ITCSS

Before the refactor, my CSS weighed 111kb. After the refactor, it weighed 27kb.

When I relaunched my personal website at the beginning of the year, I wasn’t happy with the code quality. I’d been working quickly to get it launched on time, and some of my CSS had gotten sloppy. I decided that, as soon as I had some spare time, I’d refactor it.

I’ve used several different CSS architectures in the past, but a personal site is a perfect opportunity to experiment, so I decided to try the ITCSS methodology proposed by Harry Roberts. There’s very little about it online — what looks like a primer on Creative Bloq is actually a plug to get you to buy their print version, where the real information is published (as if they were looking for ways to make themselves even more irrelevant). Despite this, on the basis of Roberts’ reputation as a front-end architect, I decided to dig up whatever I could find and give it a try.

I was able to cobble together the basics by watching this talk that Harry Roberts gave at a meetup in Serbia:

Here are the slides, which I found helpful.

Full disclosure: I didn’t follow the methodology to the letter, but rather adapted it to my own uses. That’s the beauty of choosing a CSS architecture like ITCSS, BEM, or OOCSS rather than a full-on framework like Bootstrap or Foundation — you have the flexibility to pick and choose what works for you.

What Problem is ITCSS Solving?

CSS specificity is a double-edged sword. When harnessed properly, the cascade is hugely helpful in crafting lean, non-repetitive code. When misused or misunderstood, it leads to tangled stylesheets that are constantly fighting against previously-defined styles. It’s the difference between following a current or swimming upstream.

The CSS specificity graph, from Harry Roberts’ ITCSS deck.

The ITCSS architecture forces you to write your code in specificity order. The name — Inverted Triangle CSS — refers to the narrowing focus of each layer: base elements are styled first, followed by reusable objects, followed by more specific components, et cetera.

The Toolkit

ITCSS doesn’t prescribe its own tooling — you can use it with Sass, LESS, PostCSS, whatever — but I think it’s particularly useful if you’re using a preprocessor.

I stuck with my usual kit and used Sass as a preprocessor and Gulp as my build system.

Organization

Everything happens in a master Sass file, which calls partials in a specific order.

• Settings. These are preprocessor variables for later use.
• Tools. These include all the mixins and functions.
• Generic. This includes all the third-party CSS used throughout the site.
• Base. These are element styles — no classes or IDs. Base typography styles go here, as well as anything needed to style raw elements.
• Objects. I’m a fan of object-oriented CSS, though I suppose you could remove this layer if you don’t use it. This layer is mostly layout-driven, and doesn’t include anything cosmetic. I included structural objects such as `.inner` and `.container` here, as well as some oft-repeated constructs such as `.post`s and `.hero`.
• Components. This is mostly a cosmetic layer — this is where I included more specific styling instructions for objects. Without the components layer, the site would still have its structure, but would look like a gray-box wireframe.
• Trumps (no relation). These are styles that override other styles, and should be used very sparingly. Color overrides, forced floats, and text alignment classes can go here. This is the only place in your CSS that the `!important` tag is acceptable.

The inverted triangle, from Harry Roberts’ ITCSS deck.

Now, to be honest, I cheated a little. I included some cosmetics in the objects folder and kept components pretty lean. All told, this is what my file structure looked like:

/settings
    _variables
/tools
    _clearfix
    _hidetext
    _sizing
    _typography
    _vertical
    _cover
/generic
    _boxsizing
    _media
    _monokai
    _normalize
    _typecsset
/base
    _images
    _links
    _page
    _typography
/objects
    _inner
    _images
    _hero
    _container
    _content
    _sidebar
    _header
    _footer
    _posts
    _pagination
    _categories
    _home
    _links
/components
    _hero
    _categories
/trumps
    _home
    _media
    _single
    _index

Roberts recommends keeping stylesheets on a single layer, without folders, since that compels future developers to make intentional choices about where files belong rather than allowing them to get lazy and just dump everything into a “components” folder.

Since this is a personal project and I’m the only one who will ever touch the code, I decided to organize everything into folders. Oh, and also because I’m neurotic when it comes to code organization and a flat structure would drive me crazy.

Results

Much of the refactoring process involved breaking apart existing code into different segments — the element itself, the layout object, the aesthetic component — and finding repetition that could be abstracted away.

All told, this process removed 84kb from the site’s stylesheet, dropping it from 111kb to 27kb.

Refactoring CSS naturally led to some additional changes. Often, when the structure of some CSS is unwieldy, it’s a sign of an underlying problem with the HTML. The whole site is now leaner and faster than it was before.