Fortunately someone (Load Impact) took actual measurements to see what this looked like in the real world – AJAX GET or POST – which is best?. For details check out their analysis report (PDF) (warning, contains gory geek details). The short version, what they observed is that not only was HTTP POST (multiple packets) not slower, it was faster. This is definitely contrary to the basic mental model of how this should work.

If you are into front end performance and or TCP/IP go check it out, it would be great get solid explanation of why they are seeing these results. On the flip side, if there is a flaw in the testing it would be good to identify that and come up with a new test.

Related posts:

1. XMLHttpRequest (XHR) Uses Multiple Packets for HTTP POST?
2. Recommended Reading: Steve Souders, High Performance Web Sites
3. PHP Count Performance

I wasn’t convinced by the list in his response, but it did make me wonder what exactly it would take to do this in plain Javascript. Using Phil’s layout as a model here is what I came up with (I added extra spaces to make it more readable):

<div id="last_tweet">Loading last tweet ...</div>

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js">
</script>

<script>
function twitter_callback_function( tweet ) {
    var name = tweet[0].user.name.split(' ', 1);
    $('#last_tweet').html(
        '<div class="me">' +
        '<a href="http://twitter.com/' +
        tweet[0].user.screen_name + '">' +
        '<img src="' + tweet[0].user.profile_image_url +
        '" align="left" width="40" border="0"/> ' +
         name[0] + ' on Twitter</a></div><div class="msg">' +
        tweet[0].text + '<div class="powered">Powered by' +
        ' random bits of Javascript</div></div>'
    );
    $('#last_tweet').addClass('last_tweet_box');
}
</script>

<script src="http://twitter.com/statuses/user_timeline/josephscott.json?callback=twitter_callback_function&count=1"></script>

There are 4 parts to this. The DIV that will hold the last tweet display, a copy of jQuery, a Javascript function to build the last tweet display and the JSON encoded (with callback function and tweet count specified). jQuery wasn’t required, I included make things easier on myself.

With a little extra CSS we can style it to look very much like Phil’s:

.last_tweet_box {
    background-color: rgb(51, 153, 255);
    display: block;
    font-size: 12px;
    padding: 5px;
    width: 165px;

    border-radius: 10px;
    -moz-border-radius: 10px;
    -webkit-border-radius: 10px;
}
.last_tweet_box .me {
    background-color: #fff;
    height: 45px;
    padding: 5px;

    border-radius: 10px;
    -moz-border-radius: 10px;
    -webkit-border-radius: 10px;
}
.last_tweet_box .me a {
    color: #444;
    font-size: 12px;
}
.last_tweet_box .me a img {
    border: none;
}
.last_tweet_box .msg {
    background-color: rgb(0, 51, 153);
    color: #fff;
    margin-top: 3px;
    padding: 5px;

    border-radius: 10px;
    -moz-border-radius: 10px;
    -webkit-border-radius: 10px;
}
.last_tweet_box .powered {
    color: rgb(170, 170, 170);
    font-size: 11px;
    padding-top: 5px;
    text-align: right;
}
.last_tweet_box .powered a {
    color: #ccc;
}
.last_tweet_box .powered a img {
    border: none;
}

The result is pretty close visually to what Phil had done.

I’ve talked with Phil about Kynetx and I’ll be watching to see how things develop. There are some interesting possibilities in the area they are working in. But this example of showing your last tweet doesn’t do a good job of showing off their strengths.

Related posts:

1. CSS Border Radius Percentages and Elliptical Borders
2. Detecting Client Side Time Zone Offset Via Javascript
3. Javascript

When using XMLHttpRequest, browsers implement POST as a two-step process (sending the headers first and then the data). This means that GET requests are more responsive – something you need in AJAX environments.

The claim is that even the smallest XHR will be sent using two packets if the request is done over HTTP POST instead of HTTP GET. I don’t remember ever having heard this claim before.

Let me first say that performance issues for POST vs. GET probably shouldn’t be your top factor for deciding which one to use. Make sure that you understand the implications of each and pick the right method for your request. For most people I suspect the biggest factor will involve caching, not performance. I was going to leave a comment on the article about this, but Simon beat me to it.

I wasn’t the only one who wanted to find out more about XHR POST using multiple packets. Fortunately someone else already asked that question and the author replied:

2. My claim is based on research done by Iain Lamb, cofounder of the Oddpost webmail startup that was acquired by Yahoo! and eventually became the basis for the all-new Yahoo! Mail.

His research showed “rather baffling finding: POST requests, made via the XMLHTTP object, send header and body data in separate tcp/ip packets [and therefore,] xmlhttp GET performs better when sending small amounts of data than an xmlhttp POST.”

That is why Yahoo includes the use of GET instead of POST as one of their high performance speed optimisation rules.

Simon Willison did some looking around and found more links for this. It was mentioned here and here, so it looks like Iain Lamb did do this research, even though I couldn’t find a first person account of it. This was enough information to make me curious, but not enough to answer all of my questions. It was time to run some tests of my own.

So I updated my install of Wireshark on Windows XP, turned off all of the packet reassembly options for HTTP decoding and started testing browsers. My very simple XHR POST test page looked like this:

<button type="button" onclick="$.post('hello.txt', {name: 'Joseph'})">XHR POST</button>
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js"></script>

When the button is clicked an XHR POST request is made to hello.txt with the name=Joseph for a tiny amount of data. The domain I tested on sent along some cookies as well, but still left enough room for the tiny POST payload to fit in a single TCP packet.

Here are the results of the tests that I ran:

• IE 6 – 2 packets
• IE 7 – 2 packets
• IE 8 – 2 packets
• Firefox 3.0.13 – 1 packet
• Firefox 3.5.2 – 1 packet
• Opera 9.27 – 2 packets
• Safari 4.0.3 – 2 packets
• Chrome 2.0.172.43 – 2 packets

The short version of this is pretty easy to see, all of the browsers except for Firefox will use at least 2 packets for an XHR done over HTTP POST. When I saw that Safari sent 2 packets I figured that Chrome would as well, but I tested it anyway just to make sure.

I looked at the data size of each packet in IE 6; the first packet had 575 bytes of data and the second packet had 11 bytes of data. This lined up with the POST request which indicated that the content length was 11 bytes. The second packet consisted only of the POST data. Because Firefox sent less data in the user-agent string I increased the POST data so that it would exceed the combined total of the two IE packets to make sure I wasn’t running into any odd packet fragmentation. The second packet in Opera, Safari and Chrome was also only the 11 bytes of POST data.

If this were Myth Busters I’d call this myth confirmed. While it is true that not ALL browsers will always use two packets, it appears that the two packet process is the rule, not the exception. And with IE still the most widely used browser it’s very likely that a large portion of your users fall into the two packet category. If on the other hand 95% of your users happen to be using Firefox, then sure, you can skip thinking about this.

Related posts:

1. XHR / AJAX Performance – GET or POST?
2. Browser Stats and Five Years of Firefox
3. Recommended Reading: Steve Souders, High Performance Web Sites

function get_time_zone_offset( ) {
     var current_date = new Date( );
     var gmt_offset = current_date.getTimezoneOffset( ) / 60;
     return gmt_offset;
}

The getTimezoneOffset method of the Date object returns the difference in minutes from GMT, so dividing by 60 gives us the offset in hours. By grabbing the offset as part of a login form you can detect the time zone offset for each user automatically. An example HTML snippet might help make this more clear:

<p>
Time Zone offset: <span id="offset"></span>
</p>

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js"></script>

<script type="text/javascript">
function get_time_zone_offset( ) {
    var current_date = new Date( );
    var gmt_offset = current_date.getTimezoneOffset( ) / 60;
    return gmt_offset;
}

$('#offset').html( get_time_zone_offset( ) );
</script>

Save that as an HTML file, load it into your browser and it will show you what it detected for your time zone offset. If you do decide to use this as part of your login form be sure to filter it for only valid values. Never blindly trust data from a web browser. Keep in mind that it can be a negative number and a have decimal values (for those areas that don’t use whole hour offsets for their time zone).

Related posts:

1. Detecting Time Zone Offset
2. Showing Your Last Tweet With Javascript
3. Introducing jQuery Edit In Place (JEIP)

It works in the typical jQuery style, as a plugin off of the main jQuery object. Here’s a simple example that makes all elements with a class of ‘edit-this’ editable and sends the form data to ‘save.php’:

$( ".edit-this" ).eip( "save.php" );

Check out the JEIP page for a details on what data the XHR includes and what the expected response needs to be. There’s also a long list of options that the eip function supports.

You can dive in by taking a look at this basic demo and then downloading version 0.1.0 of jeip.js.

Related posts:

1. jQuery Edit In Place (JEIP)
2. Javascript
3. XHR / AJAX Performance – GET or POST?