Tag Archives: Computing

OpenLayers extreme optimization. Cut, compress and deploy!

Make it really faster!

Following several posts I wrote recently, this one will describe you a simple and robust tutorial how to optimize OpenLayers. My goal is pretty simple. I’d like smaller library but still with everything must work correctly. The fact is that OpenLayers comes with more that what I need so I’m going to exclude some files from the build process.

Step 1

This procedure I found here, and what I made is to copy/paste the whole list described there. The problem is that immediately the application stopped working, but in the same time I could catch what errors were stopping it and simply I was able to include again those files needed by my application.

Step 2

Even when I excluded everything from the library, there are some files I don’t need but that enter the resulting build. That’s because they depend on classes I need and the builder is simply adding them. The solution, even stupid enough, is to comment them all.

Note that on every step you need to check if the application is still fully functional. That’s a bit annoying, but it comes on the price of faster app.

Step 3

Change the compiler! Actually now OpenLayers is using JSMin, but I personally use Google Closure Compiler with it’s default level of optimization. Thus the resulting OpenLayers is 312K and still fully functional. After GZip it becomes even smaller and the load time is pretty good.

JavaScript optimization. Optimizing IF statements.

IF statements in JavaScript and the normal world!

In fact every normal developer will try to make his code as readable as possible. In a normal world a JavaScript IF statement will look like so:

if ( expression ) myFunc();

where expression is something that can be either true or false and myFunc is just an example what can be called if the expression is true.

But that’s JavaScript?!

Yes, and just because is JavaScript every single character is important. Actually you can convert the row above with that one bellow:

expression && myFunc()

Than if expression is faulty myFunc() will not be called. That is really extreme and in the same time is quite clear to read.

CSS sprites. Go beyond the limits with base64!

Why should I optimize CSS?

In fact how and why should I optimize CSS is the right question. Actually CSS is simply one ore more files loaded from the server to the client, usually a browser, with CSS specific rules that must be applied by the browser to the web page you’re seeing. That’s in general. Of course there are exceptions when CSS can be inline or added directly to the HTML tags, which is bad practice because thus the HTML markup becomes larger and even worse the browser cannot cache it and than load it quickly. In fact that’s why usually the CSS of a web page is put in one single file. Primary because that makes only one request to the server and in second hand because it can be cached by the browser.

Just because the nature of the CSS is that firstly it’s loaded and than executed one of the primary techniques of optimizing it is to make it smaller and therefore load faster. There are several methods of doing so. Enabling GZIP support of the web server and minifying the file are the most common ones. But one of the tricks you cannot optimizing just for second is using the so called CSS sprites.

CSS sprites

What are these? To answer this question I’ll simply try to give you an example. Let’s assume there are three CSS classes each one with its own background image. This makes four requests to the server. One for the CSS file and one per every background image. But what we’d like to achieve is to make less requests as we can. Than one of the things we can do is to make one single image and to change only the background-position CSS property to position it on the right place and to make it appear correctly.

Be careful! When you join all of the images into one single CSS sprite you may add one class with that background-image and every other class with only background-position property. Than every DOM element with that background must have both class names. Only than you can be sure the server will make two requests. One for the CSS file and one for the sprite.

base64 to encode images

In other hand most of the web projects are pretty big, and unfortunately it’s too difficult to make only one single sprite just because it’s too difficult to manage it after the project has become very large. That’s why mostly in the practice there are several sprites for the main components. But the problem is that again there are more HTTP requests.

Is there any way to make only one request?

Yes there is. Simply by converting your CSS sprite into a base64 encoded image. In breve base64 is an encoding where you can practically make any data into a string. Thus the image can be represented by a string containing the same information as the image. Hopefully most of the browser, except of course MSIE, does read the so called data urls, or:

<img src="data:image/png;base64,..... " />

and that’s enough to get started with base64 and the single request. The sprite has become a string!

CSS and base64

The natural question is now how to merge all this? You now have one CSS file with one or more sprites. Than you can convert them into a base64 encoded strings and put them all into the CSS.

There is a problem, of course, what happens with MSIE. As I said before MSIE doesn’t read base64 encoded images. Hopefully there is a solution described very well by Stoyan Stefanov in his blog post here.

Finally …

now there is only one request and everything works pretty fine. This technique can be really helpful to someone who’s trying to optimize the CSS performance to the limits.

Firebug’s console.time() accuracy

Firebug’s console.time()

As I wrote in my previous post Firebug is giving the ability to test performance of any chunk of JavaScript code with its console.time() method. One of the most discussed topics about performance and one of the most recently examples given in the web is the way to instanciate a new empty array in JavaScript.

new Array() vs. []

Which one is faster? This is the question we’ve seen so many times in the web. I decided to check it with the console.time() method. For my experiment I made 100000 new arrays both way:

var arr = new Array();

and

var arr = [];

Thus the sample code of the first experiment is:

<html>
 <body>
  <script>
   console.time('profile 1');
   for ( var i=0; i < 100000; i++) {
      var arr = new Array();
   }
   console.timeEnd('profile 1');
  </script>
 </body>
</html>

and the results are 12 ms. OK, so far so good. Now I’d like to test the same construction with the other way to make new array instance:

<html>
 <body>
  <script>
   console.time('profile 2');
   for ( var i=0; i < 100000; i++) {
      var arr = [];}
   console.timeEnd('profile 2');
  </script>
 </body>
</html>

And the result is pretty much the same – 11 ms. That’s why I choose to increase the number of iterations of this loop from 100,000 to 10,000,000 and the second chunk of code using the construction arr = [] is finishing its job for around 3400ms or a little bit more than 3 seconds, while the first one is a little bit faster – 2450ms or faster with almost a second.

What if we merge both chunks?

I decided to concatenate the code in something like:

<html>
 <body>
  <script>
  console.time('profile 1');
   for ( var i=0; i < 100000; i++) {
    var arr = new Array();
   }
  console.timeEnd('profile 1');
  console.time('profile 2');
   for ( var i=0; i < 100000; i++) {
    var arr = [];
   }
  console.timeEnd('profile 2');
  </script>
 </body>
</html>

results:

and yet again the same results as if they were separated tests, which of course seems to be pretty natural.

Use console.time()!

That’s the way to get clear example of how fast your code is. Actually this is not a pure sense profile, where you can get minimum and maximum performance times but it gives pretty accurate values.

Profiling JavaScript with Firebug. console.profile() & console.time()!

Firebug and the console object

Although my impression is that most of the web developers use Firefox and most of them are using Firebug, I’m not sure that they use the full potential of this brilliant software.

Firebug’s console view

Firebug is a very powerful tool helping those like me doing his job. But what’s behind the mostly used Firebug’s tools and what’s in the API.

console.log()

For a typical JavaScript programmer the console.log() function is one of his best friends. It can dump useful information in the console tab of the Firebug making everything quite clear. But have you ever asked yourself how to improve your code, how to measure its performance against some constructions.

Performance of JavaScript

I’m sure many of us have read enough articles out in the web about JS performance. Nowadays when the web apps become bigger and bigger, this topic is rising from the bottom of the interesting topics pool. Now everybody’s concerned about it’s app performance and speed.

You’ve probably heart about some basic advices. What to use, what not to use. In a short example I’ll mention only that everybody knows that .appendChild is far slower than the innerHTML. But why is that? How can be sure it’s true.

As I wrote recently you should instantiate your new arrays in javascript with the following construction:

var a = [];

instead of:

var a = new Array();

but as I’ll write here that’s not always true.

console.profile()

One of the useful methods of the Firebug’s console object is the profile() method. It gives you the power to measure timing and performance of any JS function. As described in the Firebug’s web page:

The high-fi approach is to use the JavaScript profiler. Just call console.profile() before the code you want to measure, and then console.profileEnd() afterwards. Firebug will log a detailed report about how much time was spent in every function call in between.

With the simple construction like:

<html>
<body>
<script>
    myFunc = function() {
        var a = [];
    }				

   console.profile();
   myFunc();
   console.profileEnd();
</script>
</body>
</html>

Firebug’s profile output

The simple problem is that thus you cannot just measure some code that’s not a function. This will result in empty profile output in the console’s view:

But hopefully there comes the other method of the console object.

console.time()

It gives anything you’d like to know even if it’s not closed into a function.

Note: remember that both profile and time methods goes with their related profileEnd and timeEnd methods. You’re supposed to enclose the chunk of code you measure with that to be sure that the Firebug’s console will stop the profilers on time.

Now you can simply ask the profiler: what is faster?