- CSS goes in the
- Compress and Minify content for deployment
- CSS Preprocessors are awesome
As with all guidelines there are exceptions that I afford. I’ll cover them in the relevant areas below.
In addition to that it also lightens the load on your own site, as you’re not having to serve a larger file that includes whichever library you’re using.
Little things like this don’t seem important, but can have unforseen consequences if you don’t properly consider them. Which leads nicely to the next point.
CSS goes in the
An example of this in action is a project I worked on over a year ago, called ReferenceIt. There are a few key things to note. The first is in this cut down version of the
<head> <link rel="stylesheet" media="screen" href="https://referenceit.org/-assets/css/site.live.css" /> <script src="//cdnjs.cloudflare.com/ajax/libs/modernizr/2.5.3/modernizr.min.js"></script> </head>
<head> element? Well, yes. Which leads to my first exception to this guideline. HTML5Shiv and Modernizr need to be in the
<head> in order to get Internet Explorer to understand HTML5 elements.
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js"></script> <script src="/-assets/js/site.live.js"></script> </body>
Compress and Minify Content for Deployment
There are really two different stages to a site. Development of the project and the live version of a project. Each has it’s own nuances that need to be taken into consideration. For instance, when developing something you want to be able to quickly identify what is causing problems if something goes wrong.
By the time you’re launching a project such problems shouldn’t exist, which affords us the ability to make some savings in terms of space. We do this using the wonderful technologies of compression and minification.
I’ll stick with the example I used above, ReferenceIt. You saw in the footer there was a reference to a file called
site.live.js. You can view it here. As you can see, it’s pretty clustered together. I didn’t write this file. The file I wrote can be viewed here.
CSS Preprocessors are Awesome
I mentioned above that the CSS for ReferenceIt starts out quite differently. That’s because I didn’t write it as CSS at all. Instead I used a language called LESS, a language that builds upon CSS but is compiled into the CSS that browsers know and love. Nowadays I use SASS/SCSS, but the principles remain the same.
Preprocessors allow you to us a load of fantastic things in addition to the CSS you know and love. The biggest features for me:
- Automatic CSS Compression
- Usage of Variables
Automatic CSS Minification
This is probably the biggest win for me. I can write CSS that is perfectly human readable and have it compressed into the file I want to be served to browsers. This makes tweaking things nice and easy too. Save, upload, done.
Usage of Variables
Variables are handy for a lot of things. I mainly use them to store colours and dimensions, which allows me to quickly change the layout or design of a site by changing just a few elements of code.
Think of mixins as functions and you’re pretty much there. Rather than writing multiple lines of
border-radius CSS you can just call a function and have it work it all out for you. I use this with great results in 960-LESS, a flexible grid framework I now use in SCSS.
I couldn’t do preprocessors justice in this post, there’s too much to cover for it to be just a part of a larger topic. Chris Coyier has done a great series of articles on this topic however, and they are well worth a read:
And That’s A Wrap
I wanted to take a bit of a more in-depth look at ensuring that everything that can be done to save in terms of file space has been done. It’s important to get this aspect of things right before I talk about the next area of how to optimise your site, which will be dealing with caching of files and a few other technical areas which go hand in hand with caching files.
As always your comments are appreciated, both below in the comments area and on twitter.