8

I know how HTTP methods work and for what they are designed, but I'm curious to know if some methods are faster than others when using just to get data.
In the team I'm working on I noticed a lot of JQuery ajax requests like this below:

$.ajax({url: "../dir/someFile.json", method: 'post', dataType: 'json',
    error: function(...){ ... },
    success: function(...){ ... }       
});

I'd obviously use a 'get' method, as no data is sent to this request. This probably happened when a teammate was copying and pasting code. This works fine also, seems there's no good reason for changing it to 'get'.

I think using 'get' method would be faster in this case, but I didn't find any source affirming that.

Marcelo Assis
  • 4,940
  • 3
  • 31
  • 53

4 Answers4

3

There is some research that shows that some browsers will divide a POST request into multiple packets. This could have a performance impact, which you'd think would make the request slower. But, under tests it seems that POST can sometimes be faster. I'm not sure why this is.

In practice however, the performance difference is negligible and you should use POST and GET as intended.

Read:

Adam
  • 39,529
  • 15
  • 101
  • 139
  • Any thoughs on other methods, like PUT or DELETE? – Marcelo Assis Aug 06 '12 at 18:33
  • 1
    No idea. As far as I know the whole concept of splitting a request into multiple packets is a browser implementation decision. So, there are no guarantees what a browser will do for PUT or DELETE. But, my guess is that PUT will be handled like a POST, and DELETE probably also like a POST, but I'm less confident in that. – Adam Aug 06 '12 at 18:39
2

At least with historical versions of IE, there is the issue of POST transferring an extra packet. Some discussion of this here:

http://josephscott.org/archives/2009/08/xmlhttprequest-xhr-uses-multiple-packets-for-http-post/

I don't know how relevant this is with the current crop of browsers, though.

Here are the results of the tests described in the article:

  • 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
Nate C-K
  • 5,295
  • 1
  • 24
  • 43
1

It might seem obvious, but when using POST versus GET, you're using one more byte in the method name.

In addition, if you have (few) data to send, using GET will URL-encode the data (this means that the number of generated & sent bytes will be higher than the data size itself) while POST will consume more byte (in general) because the request will additionally contain a Content-Type: application/x-www-form-urlencoded header, likely a Content-Length header plus the same URL-encoded data as GET.

If you have some binary data to send, the question does not hold since you can't do that with GET.

We are speaking of pennies here, but if you accumulate pennies...

In the end, the GET request will be shorter and, for the same network link bandwidth, will be faster than POST.

To send binary data, PUT will be faster than POST (based on the same logic, and because POST will use multipart/form-data encoding headers), but browser support is more limited for PUT requests.

xryl669
  • 2,970
  • 20
  • 38
0

All things being equal, there is no difference in network performance between GET, POST, or any of the other methods. It all depends on how the server handles a GET vs. POST request. A server may, for example, attempt to update a resource on POST but only search for it on GET.

Also, with GET, you can send data. In jQuery, it just gets serialized into the query string ($.get("someplace", data: { foo: "bar" }) gets sent as $.get("someplace?foo=bar")).

Gingi
  • 1,940
  • 1
  • 17
  • 31