Previously, we talked about how important it is to reduce HTTP requests if you want to have fast-loading web pages.
Have a look at our chapter on HTTP caching for details on how to establish an effective caching strategy.
/* This is the original CSS code.
Including comments, lots of white space, ... */
Taken together, all of these (and a couple more) measures are referred to as "minification". And they aim for one goal: less characters and therefore smaller file sizes, a cornerstone metric for fast-loading web pages.
If you're using an application framework like Ruby on Rails or Django, you might already have a minification tool on board. Check your framework's documentation to see if it has something like this built in.
Grunt & Gulp
If you're using Grunt or Gulp as part of your workflows, there are lots of plugins out there to "uglify" and minify.
If you prefer a standalone Desktop application for this job, you should take a look at tools like CodeKit and Prepros.
Including CSS in Your Pages
You might be tempted to think that including CSS is a real no-brainer. And you're almost right. But the "critical rendering path" (the way browsers go about rendering a page) offers some opportunities for optimization.
By default, the browser has to wait until all CSS resources are downloaded before it can start rendering a page. Broadly speaking, this means the more CSS you have, the later will your page start to get painted.
However, there are a couple of things we can do to optimize this.
Media Types and Queries
When including your styles, the media attribute can be very helpful. For example, by marking it as "print" the browser will not have to wait until it is downloaded and parsed.
Another way to make CSS a so-called "non-blocking resource" is to use a media query. The browser can then decide on its own if it has to download the CSS (and thereby delay rendering of the page). In this example, the rendering will only be blocked on smaller screens where this particular CSS is really needed:
Since the browser (by default) has to wait for all CSS to be loaded, it's important to provide it as quickly as possible. We've already discussed a couple of things you can do: minify your CSS files and compress them using GZIP.
However, there's also another very simple way to make sure the browser receives CSS as early as possible - by including it early in the HEAD section of your HTML document. This way, the browser will start downloading CSS as soon as possible.
Don't Use @import
CSS allows to "import" additional stylesheet files right from within a CSS file:
However, you should by all means try to avoid this mechanism. The reason for this advice is simple: the CSS @import delays rendering of the page!
To give you an example, let's say you include a file named "styles-1.css" in your page. If somewhere in that file, the @import statement is used to load additional CSS from "styles-2.css", the process is slowed down immensely:
First, as usual, styles-1.css has to be downloaded and parsed.
Only after parsing is finished will the browser notice that another file, "styles-2.css" is referenced.
It then has to download and parse this file, too, before it can finally start rendering the page.
Of course, the @import statement was once invented for a good reason: it allows to keep your CSS modular, in separate files. This underlying principle is perfectly reasonable and you shouldn't abandon it!
However, production CSS is not the right place for it. Take a look at the Sass and Less preprocessor frameworks where an @import mechanism is also available - but without the negative side-effects.
Loading Scripts at the Bottom
Including Scripts with ´async´
<script src="page.js" async></script>
This solution should cover most needs. If you want to explore this topic even further, there is lots of reading material on the web like this article by Patrick Sexton.
Including libraries from one of these CDNs has a couple of advantages:
Reliability and speed: its hard to beat these services when it comes to reliability and speed.
Parallel HTTP connections: browsers limit the number of simultaneous connections to the same server; if you're requesting from a second source (one of these CDNs in this case), the browser can start more parallel downloads. (Read more about this in our chapter on Content Delivery Networks.)
Browser caching: most importantly, chances are that the browser can deliver this from its cache! Given the popularity of jQuery, for example, it's not unlikely that the visitor has already downloaded this resource on a different website.
Loading Scripts Only Once
Although this piece of advice is rather obvious, it's remarkable how often it's still not heeded: especially in larger teams, it's not uncommon that different developers include the same third-party library multiple times. It goes without saying that this an especially tragic waste of bandwidth.
Many application frameworks offer a central function to handle library imports. Part of this is also that it protects you against duplicate inclusions.
Get our popular Git Cheat Sheet for free!
You'll find the most important commands on the front and helpful best practice tips on the back. Over 100,000 developers have downloaded it to make Git a little bit easier.
As the makers of Tower, the best Git client for Mac and Windows, we help over 100,000 users in companies like Apple, Google, Amazon, Twitter, and Ebay get the most out of Git.
Just like with Tower, our mission with this platform is to help people become better professionals.
That's why we provide our guides, videos, and cheat sheets (about version control with Git and lots of other topics) for free.