Faster CSS through Refactoring


Large CSS files can drastically increase page loading times...
Start reading  

Large CSS files can drastically increase page loading times. In order to prevent this and to keep the CSS file small and maintainable in the future, it is possible to refactor the CSS and thereby, among other things, increase page speed.


Refactoring is a term from software development and stands for improving the code without altering the behavior of the software. CSS refactoring, by minimizing loading times, does not just make the website faster but also simplifies future changes to the CSS.

This means that we improve the structure of the CSS code but keep it doing the same thing after refactoring. At a first glance, that may seem like a waste of time since the website’s appearance remains the same. In many cases however, it‘s worth good money. Not just because it helps lowering traffic costs, but also because page speed has become an SEO & marketing factor a long time ago.

Building a CSS file often also involves some experimentation in terms of design - changing positions, adjusting font sizes, etc. This can easily lead to unnecessary lines of CSS, as the following example shows. 

HTML

<div id="arrow­title­up">You</div>
<div id="arrow­title­down">Us</div> 

CSS

#arrow­title­up{    position: absolute;    top: 74px;    left: 54px;    width: 60px;    font­size: 30px;    font­weight: bold;   color: #343534; 

#arrow­title­down{    position: absolute;   top: 141px;    left: 43px;    width: 60px;    font­size: 30px;    font­weight: bold;    color: #55b093;  }

Example: http://codepen.io/sebastianmaier/pen/GLCcF

Here, 4 necessary lines of code turned into 8. If such repetitions recur within a CSS file, it can significantly increase in size. The larger the files, the longer the loading times of the website.

In addition to that, a CSS file like that is also higher maintenance. In order to just change the font size from 30px to 29px, in this case you would have to change it in two places.

The four lines from the example above can be swapped to a separate class. This is what a first step toward improvement could look like:

HTML

<div class="arrow­title" id="arrow­title­up">You</div> 
<div class="arrow­title" id="arrow­title­down">Us</div>

CSS

.arrow­title { 
 position: absolute;
 width: 60px;
 font­size: 30px;
 font­weight: bold;
}
#arrow­title­up{
 top: 74px;
 left: 54px;
 color: #343534;
}
#arrow­title­down{
 top: 141px;
 left: 43px;
 color: #55b093;
}

Example: http://codepen.io/sebastianmaier/pen/dyloF

During refactoring, it is recommended that you check your code for any kind of repetition.

For example, it’s often possible to consolidate fonts. Instead of using the command color: #55b093 over and over again for every ID or class, we could use a class .text-color-green.

Charmingly, future changes are then only required in one place in the CSS, and that saves us a few lines of code in the CSS.

Complete example code


At smooster we work adhering to strict quality guidelines. Refactoring is an integral part of that, especially for larger projects. The following example is from refactoring an older version of our own website:  

Without refactoring: http://codepen.io/sebastianmaier/pen/kbgcu
With refactoring: http://codepen.io/sebastianmaier/pen/vKEro

As a result of this refactoring, we were able to save 33 lines of code.


Further thoughts: Dynamic Stylesheet Languages & CSS Testing

In traditional software development, refactoring includes the following points:

  • Readability
  • Clarity
  • Comprehensibility
  • Extensibility
  • Avoiding of redundancy
  • Testability

Points 1-5  

The points 1-5 help us with further changes to the CSS - especially if those aren’t always implemented by the same person. Loading time can be improved by taking point 5 into account.

Approaches like LESS or SASS, in which you don’t write purely in CSS anymore, can be helpful with these steps. Here it is possible, for example, to use variables, so recurring values have to be changed only in one place in the code.  

An example for LESS:

Particularly those CSS commands that include browser prefixes can be simplified very beautifully using LESS; this may not make the CSS file smaller, but it increases the readability of the code.

CSS

  ­moz­transform: rotate(90deg); 
 ­ms­transform: rotate(90deg);
 ­o­transform: rotate(90deg);
 ­webkit­transform: rotate(90deg);
 transform: rotate(90deg);

Instead of copying the CSS commands to the respective places where they are needed and changing the values, we can simplify it in LESS as follows:

CSS

.transform­rotate(@deg: 90deg) { 
  ­moz­transform: rotate(@deg);
  ­ms­transform: rotate(@deg);
­  o­transform: rotate(@deg);   ­webkit­transform: rotate(@deg);   transform: rotate(@deg); }

Now anywhere in the CSS file .transform-rotate() can be selected, and LESS then replaces it with the individual commands.

CSS

.a_class_name { 
  .transform­rotate();
}

In case we want to provide a different value, for example, 45deg, with LESS we can now write it as follows:

CSS

.a_class_name { 
  .transform­rotate(45deg);
}

Without LESS we would’ve had to insert 6 lines of code. LESS really does make the revision much more comfortable and readable, or what do you think?  

You can see the complete example here:

without LESS http://codepen.io/sebastianmaier/pen/diLKH
with LESS http://codepen.io/sebastianmaier/pen/vEqof

Point 6 - Testability

From a technical perspective, point 6 is a pretty interesting aspect, on which opinions differ. Our goal in refactoring is to only change the structuring of the source code, but not – in the case of the CSS – to change the appearance or effect of the CSS. Of course, this has to be checked. There are two ways of doing so – by manual visual inspection or by automated examination. Especially with larger projects, it’s hard to tell whether a change has the same effect on all subpages, and checking manually is virtually impossible.  

This is where automated checks come in – an approach that is becoming more and more widespread in software development. You basically write a small program which checks automatically whether the h1 on the home page still has the given values, such as the font size of 20px, font color #000000, and a line height of 40px. This is repeated for all areas of the website. This program can then be started again and again to make sure our refactored CSS hasn’t changed the website’s appearance. Now we can refactor the CSS and then run the program as a test. If it shows no changes, we were successful. In case we made a mistake during refactoring after all, the small program would notice and show us. These tests usually require basic programming knowledge.  

However, the use of automated tests for CSS is disputed.
http://stackoverflow.com/questions/342579/css-unit-testing

Selenium would be such a tool for testing CSS:
http://www.seleniumhq.org/

You can find more about CSS testing on the following sites:

I would love to hear about your experiences with CSS refactoring.


(Images used in this article: Free Photos)

2014.08.22 written by

comments powered by Disqus