The Minification Process

While with minification you can strip all the symbols that only take space, but are useless when the browser parses the file, there are some other techniques, which in fact aren’t so simple, to speed up the loading process. By minification you get rid of the white spaces, tabs, new lines, etc., but the file may remain too large.

Useless Rules

Yes, sadly the browser doesn’t need all those white spaces, actually web developers need them. Just because this makes the file more readable, or readable at all. However most of the web applications have one large CSS file, typically named layout.css, main.css or whatever, that contains all the rules for the entire application. In many of the cases one page of a site doesn’t need all the rules for the site, so a possible solution is to remove all of the rules that aren’t used.

There are tools that may help you do the job. Such a tool, that I’m using is the Firefox add-on – Dust-Me Selectors. Of course there are a lot other tools doing the same job, so it’s up to you to pick up one.

After removing all those useless rules you’ll see that the size of the file can be something like 20% of the size of the source file. This is interesting to note, because most of the time the minification cannot give you such performance benefit. In fact this comes with some issues.

One Request or What?

This is the dilemma of the web programming, isn’t it? However thus you can split the main CSS file to few smaller files, but they are named differently so you cannot expect the browser to cache them when the user visits the site for the first time.

The case must be, of course, tested against various situations, so you can decide what suits you. However the typical scenario is to optimize only few of the pages, as they might be the most visited – as for example the homepage. If two of the pages are mainly visited, than you can make custom, small, CSS files for them with only the necessary rules, and let the other pages with the main CSS file. If you’ve a lot of returning visitors, you can be sure the custom files will be cached (if the client cache is turned on) and the second time somebody visits the “homepage” for example the page will load faster.

Yes that’s the reality and when they become more and more bigger the web pages becomes to be irresponsible. The bitter reality is that you load any functionality that slows down the first user impression, but is needed only when you click on a button and so on. That’s a problem because you can load only that chunks you need in the beginning and than after a few seconds to load everything else. Some web applications have more than 100K of javascript which become really bad.

Separate logic

What you can do is to separate the logic into one or more files. Even when the user thinks everything is on the page and he can interact with the application and than to start to load the rest of the functionality.

That’s a pretty good technique. Nobody can start interacting on the 5th second of the load process. Usually the user looks at the interface starts to explore the app and after approximately the 10th second he start interacting with the page.

Lazy loading

There are various techniques of loading JavaScript on demand. So I wont cover it, but that pattern of loading it latter when needed is really powerful.

The problem is that the library supports so many protocols, controls and tools that you probably never use in your application and because of this the size of the resulting, compressed javascript file is around 700K, which is too big for any javascript file at all. That makes your site slow and the user experience is really awful!

The solution is to cut that functionality that you don’t use, which is not so easy. You’ve to be careful doing this, just because you can crash you application by removing something that seems to be useless but in fact isn’t.

I’ve used this technique and managed to make the resulting javascript file up to 400K. And this is really simple – just add the files your application don’t need to the .cfg file you use for compression. Usually this fils is in the /build directory of OpenLayers.

Even more – I’ve seen some other developers managing to reduce the size up to 300K and that’s more than twice which is really very good result.

The other thing I’d like to do with that library is to explore with care the code inside and to optimize anything I can. There are too many style reflows in some classes and that’s what’s visible on the first look. I suppose there are much more things to optimized in it.

I’ll start doing my research and optimization and I’ll let you know what happens in numbers!