Ovalpixels Blog about Web-Building » http

Building fast web sites with Yahoo!’s Exceptional Performance Team

georgi — Sat, 15 Nov 2008 01:50:59 +0000

Yahoo!’s Developer Theater has always been a priceless resource for web designers and developers. But what I have found the most useful video for me was Steve Souders’ High performance websites presentation. For those of you who don’t have the time to watch the whole video – here is a short summary.

Like many things in our Universe, web performance obeys Pareto’s 80-20 principle – 20% of the elements of a website cause 80% of the effects on the performance. And if we try to slightly reduce the time spent on loading those 20% of the elements, we can get much more than 20% increase in speed.

Are servers the root of all evil?

And as most of you probably already guessed – most of the server-side elements are not within those 20%. If you slightly improve ( or think you have ) your PHP algorithms or your SQL queries, you will probably gain benefits which are close to the statistical error. ( Here we are not talking about drastic changes or bug fixes in faulty software which shouldn’t have been there in the first place ).

Speed up the browser

What turns out to have the greatest impact on loading times and user experiences are the elements which load into the browser. And writing speed enhancements for the browser is out of our scope right now – we can just try to adapt our web pages, so that it is easier for it to parse and display. Here are my top 5 rules which have given me fantastic results.

Number of HTTP requests

If we are to believe Yahoo!, 80% of the time spent loading a web page is taken by downloading the entities of that page – mainly css, javascripts and images. The problem here is that we have too much unimportant (for the users) data sent back and forth, also known as headers. Even the smallest image has its request and response headers traveling with it across the Net. So, my advice is – combine your javascript and css files and use css sprites’ images. These are image maps which hold all of your images in one file and thus only this single file is sent over with its headers. Read more on css sprites here.

Expires header

This technique is very simple, yet very powerful and rarely used. Expires headers tell the browser that the entity it has requested *will not be changed* until some date. In practice, this means that the browser will not download that entity, if it already has it in its cache – 0 bytes transfered. Be careful, though, if you need to change something on the fly ( especially when still developing a site ), you will have to change the name of that file, so that the browser doesn’t think it already has it in the cache. This can easily be avoided using a simple versioning technique ( a link to some-file.js can look like some-file.js?version=1.0 and can later be changed to some-file.js?version=1.1 which will instantly make the browser fetch the file again as the url has changed ).

So, here – simply set a far-future Expires header on static content.

GZip

Also very useful, especially on large text files (like css and javascript files). This will effectively compress your content on the server, then send it to the browser which will uncompress it and use it. But be careful – don’t use this on images as it can be counter-productive. All A grade browsers support gzipped responses, so no worries about compatibility here.

Javascript and CSS

You should already know this but just in case – compress and minify your javascript and css files; put css at the top and javascript at the bottom. Simple, heh?

Flush it!

Well, the only server-side technique in my top 5 – flush your output buffer early ( just after the tag ). This is very helpful on sites rich in html and text content because it will send the of the html document fast enough so that the browser may start downloading the respective css files ( which you have put in the head, as described in the previous rule ) and underlying css images before the rest of the document has been transfered. Otherwise, you may end up in a situation where the whole HTML document needs to be received before css and the images can start being fetched.

This is just a sneak overview of the techniques – for a thorough list and technical help, please visit yahoo’s site

Highly responsive ajax applications without excess requests and bandwidth waste?

georgi — Sat, 15 Nov 2008 00:42:17 +0000

Ajax is not as powerful as one would imagine

If you have ever tried to develop a robust ajax application, you have probably reached a point where you want the client to be notified about a change on the server in “real time”. The most simple example – you need to create a chat application and want the client to instantly receive new messages upon their arrival on the server. And, if you like me, are not a fan of Flash ( which may be one of your major flaws ) and want to achieve this using only ajax techniques, you have found out that is not that simple.

There is no real channel between the server and the client

In that case you have no real permament connection between the server and the client and there is no real way of “triggering” events or sending data from the server to the client in any traditional way. Moreover, ajax does not support the client “listening” and waiting for a server’s call ( well, that’s a client after all ). You googled for some time, asked some fellow developers and almost all you could find was – “Just use javascript’s (notorious) setTimeout() or setInterval() function to repeatedly poll the server and check whether there is new data for the client”.

Like, for example ( using jQuery ) :

function read(){
  jQuery.ajax( {
    'url'     : 'chat/read/',
    'cache'   : false,
    'dataType': 'json',
    'success' : function(messages){
      //if there are new messages - write them on the wall
      if( messages ){
	//write messages to the chat wall
      }
    } );
  }
}
 
setTimeout( function(){ read() }, 2000 );

( I will not show any server-side code examples as they are simple enough – the method being /chat/read/ would just read from the database and return new records. Moreover, what we have here is not what we’re trying to achieve – the example here is for descriptive purposes only. )

Is that what we call highly-responsive, flexible applications, you’d ask? No. This technique has several drawbacks:

it sends http requests from the client to the server and gets response ( most of the time empty ones ) on every X number of seconds. X usually is a far too small number and that can translate into way too much wasted bandwidth, if we are talking about a high-traffic website and if we need that polling done for multiple actions
it can eventually make the client hang-up as most modern browsers ( except for Chrome – or at least – what Chrome pleads ) don’t have smart javascript garbage collection and all those requests can be quite costly.
it is not really highly-responsive – it has a lag of 2 seconds which may be enough to make the users nervous
this just doesn’t feel like the right way of doing things

Comet

Well, I need to be honest – the Comet technique ( also known as long-polling ) seems like nothing new but I personally was not aware of it’s power till recently ( Eelco pointed it to me ). But you will be amazed how many open- and closed-source projects have no idea that it is out there and do not try to use it. And it is simple – you make a request to the server, it gets it and just… waits. Waits till there is meaningful data to be returned or returns something less useful ( like null ), if the request is about to timeout. On a standard apache configuration that would mean 5 minutes – you can make just one single request on every 5 minutes, not on every 2 seconds ( which a traditional ajax app would do ). That is 150+ times less requests, less bandwidth, less javascript functions’ calls and the application would feel much more responsive.

There is, however, a small side note to mention…

PHP Sessions are not keen on long-polling

And, if you hadn’t read this post, you’d have had some hard time finding this out. It is just that in every normal application, you can be 97% sure you will be using sessions. And in most of the time, you will rely on the built-in php sessions’ handler. So far, so good. But the small problem is that you cannot simultaneously be running different scripts ( or more than one instantiation of a script ) which use one and the same user session ( that, again, was a discovery by Mr. Pagebaker ). PHP will just queue all subsequent requests which try to interact with that session, until the first one has been closed. Well, that is not much of an asynchroneous technique either then. Getting back to our chat application – if you want to long-poll the server and wait for new messages ( what we will call read() ) and simultaneously send new messages to the server ( write() ), the application will not write() until the read() request has finished ( which we have set to 5 mins, if in the worst case there is no new data to be received ) – that is absolutely not what we need.

Frameworks to the rescue

But, as all self-respectful developers, you have adopted a php framework which provides an alternative to the native php sessions’ handler – be it file, database or any other geeky approach. I’d prefer CakePHP where it is simple – just open your /app/config/core.php and find

Configure::write('Session.save', 'php');

change that to

Configure::write('Session.save', 'database');

and uncomment the few lines below that line with respective data.

So, now let’s see what we have:

Our client-side script ( jQuery again ):

function read(){
  jQuery.ajax({
    'url'     : '/chat/read/',
    'cache'   : false,
    'dataType': 'json',
    'success' : function(messages){
      if( messages.length ){
	//write to chat wall
      }
      read();
    }
  });
}

It is important to notice that even though I have not shown the write() function, you should use jQuery’s Ajax Queue Plugin, so that our write requests are kept in good order. That is not needed when we read() as no subsequent read() requests will be fired before the first one has ended.

And, our cakephp chat controller method:

public function read(){
  $lastMessage_id = $this-&gt;Session-&gt;read('Conversation.lastMessage_id');
  if( $lastMessage_id === null ){
    echo $this-&gt;Json-&gt;encode( array() );
    $this-&gt;Session-&gt;write( 'Conversation.lastMessage_id', 0 );
    exit(0);
  }
  $now = time();
  $timeout = 300;
  while(!connection_aborted()){
    $messages = $this-&gt;Conversation-&gt;read( $lastMessage_id );
    if( !empty( $messages ) ){
      $this-&gt;Session-&gt;write( 'Conversation.lastMessage_id', $messages[ count( $messages ) - 1]['Message']['id'] );
      echo $this-&gt;Json-&gt;encode( $messages );
      exit(0);
    }
    elseif( time() &gt; $now + $timeout ){
      echo $this-&gt;Json-&gt;еncode( array() );
      exit(0);
    }
    sleep(1);
  }
}

In short – we get the last message id from the user session then use it to fetch newer records from the model. If there are none and the user hasn’t left our webpage, we start looking for new messages once again and so on. We also keep track on the time we have spent so far in that iteration – we don’t want an ugly timeout, that is why we just send an empty response, if we have reached a critical level ( $timeout = 300 in that case ).

For simplicity, I do not use views in that example but it is highly recommended that you avoid using the JSON component and use views instead ( who knows, you might need a different format in the future ).

Notice the sleep(1) line – we don’t want our CPU to burn out after a few hours of work, so some time for rest is highly recommended. You may, of course, use smaller intervals but at your own risk.

That is it for now – feel free to comment and thanks for reading