Every time a client sends an HTTP request, it has to send all associated cookies that have been set for that domain and path along with it. Most users have asymmetric Internet connections: upload-to-download bandwidth ratios are commonly in the range of 1:4 to 1:20. This means that a 500-byte HTTP header request could take the equivalent time to upload as 10 KB of HTTP response data takes to download. The factor is actually even higher because HTTP request headers are sent uncompressed. In other words, for requests for small objects (say, less than 10 KB, the typical size of a compressed image), the data sent in a request header can account for the majority of the response time.
The latency can be higher at the beginning of a new browser session. To minimize net congestion, TCP employs the "slow start" algorithm for new connections. This limits the amount of data that can be sent by the initiator of the connection before the data must be acknowledged by the recipient. If the initiator sends more than that amount of data over a new connection, an additional RTT is incurred. On Windows, the limit is about 3000 bytes, the equivalent of two packets. Therefore, to avoid the penalty of additional RTTs, and optimize for TCP slow start, a client request should fit into two packets.
The best way to cut down on client request time is to reduce the number of bytes uploaded as cookie data.
Keeping cookies as small as possible ensures that an HTTP request can fit into a single packet.
For resources that must be sent with cookies, keep the cookie sizes to a bare minimum. Ideally, an HTTP request should not go beyond 1 packet (approximately 1500 bytes), The most widely used networks limit packets to 1500 bytes. To keep the request size within this limit, no one cookie served off any domain should be more than 1000 bytes. We recommend that the average size of cookies served off any domain be less than 400 bytes.
Serving static resources from a cookieless domain reduces the total size of requests made for a page.
Static content, such as images, JS and CSS files,
don't need
to
be accompanied by cookies, as there is no user interaction with these
resources. You can decrease request latency by
serving
static resources from a domain that doesn't serve cookies. This
technique is especially useful for pages referencing large volumes of
rarely cached static content, such as frequently changing image
thumbnails, or infrequently accessed image archives. We recommend this technique
for any page that serves more than 5 static resources. (For pages that serve
fewer resources than this, it's not worth the cost of setting up an extra
domain.)
To reserve a cookieless domain for serving static content, register a new domain name and configure your DNS database with a CNAME record that points the new domain to your existing domain A record. Configure your web server to serve static resources from the new domain, and do not allow any cookies to be set anywhere on this domain. In your web pages, reference the domain name in the URLs for the static resources.
If you host your static files using a CDN, your CDN may support serving these resources from another domain. Contact your CDN to find out.
Many Google properties, including News and Code (this site), serve static resources, such as JS files and images, from a separate domain, www.gstatic.com. No cookies can be set on this domain. For the News homepage at news.google.com, you can see the cookie in the request header in this screen shot:
But for www.static.com, which is used to serve the News logo .gif file, no cookie headers appear in the request or response:
|
