Although trying to optimize your website to use the fewest packets as possible sound absurd, there are actually some areas where doing it may have some small benefits.  For example, small requests that can fall in the 1 or 2 packet segments.  I’m mainly taking about AJAX (XMLHttpRequest) requests, which we expect the response to be fairly instantaneous.  Every packet sent with TCP/IP has to be acknowledged by the other server and the client has to wait for that acknowledgment, so it is typically slow (more latency) compared to other protocols (such as UDP, which is along the lines of fire-and-forget).  Since AJAX requests are typically very small, it is a good area to try to improve it by trying it as small as possible.  This includes its HTTP Header data (cookies, user-agent strings, accept strings, referrers, etc.) and any Body data (POST data).  Most of that data is fairly hard to change since it’s provided by the browser, but others such as the cookie data and POST data the web developers can.  For me, I try to keep the cookie data as small as possible.  Some web frameworks allow you to store encrypted session data in the user’s cookie by default (such as KohanaPHP), which is nice in keeping that data with the user, but it adds that extra data to every request (including non-AJAX requests).  (Though one can argue that accessing the file system or database for the session data could be slower than the extra packet.)  Instead, it maybe recommended to just store the session ID in the browser (which is PHP’s default behavior).

The blog article also has an interesting link to another interesting article measuring that XMLHttpRequest uses 2 packets to send POST data (for most browsers).  You should give that one a read.  Although I don’t have websites with huge user-bases that could definitely take advantage of these techniques, it is interesting to know what is going on when the request leaves your web browser and how to optimize it such a minute scale.

At work, while working with a third-party application for generating personalized websites, the lack of information the system provided, I’ve tried using AJAX to request information from another server that can request for more information.  Upon discovering that AJAX cannot perform cross-domain requests (Same Origin Policy) due to various security issues that would arise, I’ve found something called JSONP.  Although it’s technically not AJAX (it doesn’t use the XMLHttpRequest object), it was a workable hack-ish workaround the limitations of the current state of AJAX techniques using a GET request that returns a JSON object wrapped in a Javascript callback function.

Today, I’ve discovered a proposal by Douglas Crockford for a JSONRequest service that allows cross-domain requests with requests and responses in the form of JSON, minus some of the issues that plagued XMLHttpRequest if it was usable cross-domain.  The big one would be that cookies or HTTP Authentication data would not be sent along with the request, so that prevents Cross-Site Request Forgery.  Though the proposal has been created nearly three years ago I’m surprised that it hasn’t been implemented in any browsers yet.  I hope a future version of Firefox or some browser would implement it and slowly spread its implementation.