Every page load on the web browser involves several connections to the server usually numbering in the hundreds, each of which ideally involves a request to the server and a response from the server. In order to speed up the page load times, you will need to reduce both the number of requests as well as the size of the request and the response.

Each request made to the server uses the HTTP protocol which in itself is a stateless protocol. In the strictest sense of the protocol, each request from the client is considered as an independent transaction that is not dependent on any previous request that might have been made by the client. This stateless feature of the protocol allows the connections to be dropped and recreated without too much disruption thus allowing for a very loose but yet stable exchange of content between machines.

But most of the modern-day browsing involves some kind of state. Most features of interactive browsing such as shopping carts, logged in sessions, customer tracking all depends on some kind of a stateful behavior between server and client. This stateful behavior is usually mimicked using several different technologies such as HTTP pipe-lining, Cookies, AJAX and URL rewriting.

This requirement to have the ability to recreate the connection and the state means that certain data needs to be resend with each and every request to the server. The HTTP request has the ability to hold several different kinds of data. Some of the important ones are

Cookies: HTTP or Web Cookies are a small piece of text data stored on the client machine or web browser that can be identified by the server. This is attached and sent with every request to the server.
URL/URI Rewriting: The URL of the resource can have additional information in terms of parameters. The data is passed along to the server as a string of keys and values.
Form Fields: The data from forms can be encoded and passed along as parameters. In case of large amounts of data, it can be also be streamed to the server.

The stateless nature of the HTTP protocol means, the client has to resend a whole lot of data including the cookies while making a request. Depending on the amount of data, it can make the overall page load slower, mostly because two reasons.

Upload Speed: Most times the upload speed and bandwidth is severely limited when compared to the download speed. This means that uploading even a small amount of data can take substantially longer.

Compression: Request from the client is usually uncompressed unlike the response from the server. This is usually not bad if the request is small as the compression would not yield much reduction in size anyways.

Reducing the page load times involves a lot of things and factors. The request upload time is just one of those factors, but can still affect the over all time it takes to load the entire webpage. As each web page can contain hundreds of request, minimizing the number requests is very important. But you can also increase the overall speed by decreasing the size of each of these requests.

It is important to understand as to the size of data we are talking about. The amount of data that can be sent in a single request is very limited. That means if the data is over the limit, then it is split into two or more requests. Most commonly accepted limit of a header packet is around 1500 bytes or 15 KB which is not much.

You should keep the amount of data, both in the cookies and the request headers to a minimum such that it can fit into a single request packet. There are three important parts in the HTTP request that you can work towards minimizing or optimizing.

Cookies: They are usually the major part of a request. Whenever possible avoid using cookies. The average size of your cookies must ideally be below 400 bytes.
Resource URI : Rewriting URLs to store data and state means it can grow very long. A URL with a large number of parameters and values can run into hundreds of bytes. Usually, the GET field (the URL) and the HOST field in the request object can be minimized to reduce the overall size.
URL Length: Keeping the length of the page URLs to a minimum has many advantages. One of them being that it will reduce the size of HTTP referer field in the request when a subsequent request is made from the page.
Browser Fields: These are fields set by the browser. As a user you probably can configure your browser or a proxy to minimize these values, but from the server perspective you don’t really have much control over it.

Minimize Request Size

We will see the various different things you can do to each of these fields to optimize its size. Remember that not all of these methods will always be possible or viable depending on your webpage and requirements.

Cookies

Server Side Cookies: Whenever possible you should try to use server-side cookies. This will reduce the need to have large client side cookies. You can ideally use a unique identifier so that you can look up data on the server-side rather than having to send all the data with every request.

Delete Cookies: You should remove unwanted cookies or unnecessary data from the cookies whenever possible. It is important to keep cookies up to date and concise.

Remove Duplicate Values: It is probably related to the above point. Keeping the cookies current also means removing duplicate values and entries.

Correct Domain Path: Always use correct path for your cookies. It is often easy to dump all the values into the top-level or root (/), but it means it will get send with every request even if it is not necessary for that request. Use appropriate and most specific paths for the cookies.

Cookie-less Domains: When possible, use a different domain usually a sub-domain to serve static content. Static content like images, media, CSS and JavaScript do not need cookies to work. Using a domain with out the support for any cookies can minimize request size. This means that the cookies used with the HTTP pages will not be shared with static content and thus be needlessly sent along with the request for static content.

Resource URI

Minimize Parameters: If your URL uses parameters to send state to the server, then try to minimize the parameter keys and values that are sent.

Avoid Duplicates: You will surprised to know many times there can be duplicates of parameters in the URL, if you are not careful. Eliminate all duplicate variables in the URL string.

Smaller Parameter Keys: Use smaller keys when possible. For example, a key named current_client_date can probably be reduced to a single character c. While descriptive parameter names are human readable, it adds substantially to the size of the request.

Encrypt/Encode Values: Encoding parameter values can substantially minimize request size. If a parameter can have a set of possible values, then you can reduce it further as long as the server can map it back to the original value. For example, if the possible values of a parameter are running, started, stopped then it can be encrypted to 0,1 and 2 with each mapping to the corresponding value.

Resource URL length

The URL of the page is often send in the request header as the HTTP referer field, when a request is made for another page or resource, for example when somebody clicks on a link on the page. This means a long and descriptive URL can add to the overall size of the subsequent requests made from the page.

The challenge here is to find a happy medium between having a human readable descriptive URL and one that is small enough to save on the overall request size.