23rd October, 2013
5 Min read
Book a Demo
Minimizing request overhead for each page to load simply means two things: keeping cookies and request headers as small as possible, and serving static resources from a cookieless domain. In a nutshell, a cookie diet to avoid net congestion.
Image 1 – Minimizing request overhead means keeping cookies and request headers as small as possible
Reduce your AWS costs by over 50%
Discover your Cloud Saving Potential – Answer just 5 simple questions. AppsFlyer, Playtika, Lufthansa, IBM, top leading companies are already using our FinOps services.
The request overhead post is a continuation of series about Google’s web performance best practices advice. Please see our post on caching and on minimizing round trip time. Practices are explained with the goal of eliminating components that are slowing down your webpage and adding to the page load time, where milliseconds matter, and your revenue depends on it. Practices are a companion to understanding Google’s Page Speed tool results, along with the rules that fall into six categories.
Where do Cookies come from, anyway?
First of all, cookies are plain text and contain no code. They proved convenient in the early days of the web for enabling the server to recognize if two requests came from the same browser. It was a token of a sort, inserted into the page once that the page was requested, and passed back with the next request. (Lou Montully from Netscape is granted a patent for cookies, and introducing the concept to the web communication in 1994).
A web server specifies a cookie by sending an HTTP header called “Set-Cookie” in a format of a string. The cookie value, however, is stored in a HTTP header called “Cookie”. If there are multiple cookies for the given request, then they are separated by a semicolon and space.
What happens to the cookie is defined by options after the cookie value, also separated by a semicolon and space and each specifies rules about when the cookie should be sent back to the server. The first option is “expires”, which indicates when the cookie should no longer be sent to the server and therefore may be deleted by the browser. Without the expires option, a cookie has a lifespan of a single session. The next option is “domain”, which indicates the domain(s) for which the cookie should be sent. Another way to control the cookie is to specify the “path” option. Similar to the domain option, path indicates a URL path that must exist in the requested resource before sending the cookie header. The last option is “secure”. Unlike the other options, this is just a flag and has no additional value specified. A secure cookie will only be sent to the server when a request is made using SSL and the HTTPS protocol.
Now, every time a client sends a HTTP request, it comes with all the cookies set for that domain and that path. Since HTTP request headers are sent uncompressed, requests for small objects (i.e., less than 10 KB), the data sent in a request header can account for the majority of the response time, and the latency is usually higher at the beginning of a new browser session. According to Best Practices, “the best way to cut down on client request time is to reduce the number of bytes uploaded as request header data.”
Downsizing the Cookie
Two actions suggested for minimizing the request overhead is minimizing the request size, i.e. keeping cookies and request headers as small as possible, and serving static content from a cookieless domain, i.e. reducing the total size of requests made for a page. HTTP request headers include cookies, browser set fields, requested resource URL and referrer URL that can all be constrained.
For resources that must be sent with cookies, it is recommended to keep the cookie size to a bare minimum. Not one cookie served off any domain should be more than 1000 bytes. Average size recommended is less than 400 bytes.
Ideally, you should store only a unique identifier in the cookie, and use server-side storage for most of the cookie payload.
Further along, it is recommended to remove unused or duplicated cookie fields. As explained in the practices, the fields set by a cookie at the top-level path of a domain (i.e. /) are inherited by the resources served off all paths below that domain. Therefore, if you are serving different applications on different URL paths, and you have a field that applies globally to all applications on a domain, include that field in the cookie set at the top-level domain. Conversely, if a field only applies to an application served from a subpath (e.g., a UI setting), don’t include that field in the top-level cookie and force the unused data to be passed needlessly for other applications.
Static content, finally, such as CSS files or JS files, doesn’t have to be associated with cookies. There is no reason for the implementation because there is no real user interaction with these files. It is recommended (for any page that serves more than 5 static resources) that static content is served from a domain that doesn’t serve cookies. 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, it is explained in the practices. 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. Your CDN service provider may support you on this, if you are partnering with one.
To sum it all up:
- you cannot afford a slow website
- for small objects (i.e., less than 10 KB), the data sent in a request header can account for the majority of the response time
- you can reduce the overhead of the request stream
- put limitations to a cookie in an HTTP request: not one cookie served off any domain should be more than 1000 bytes
- store only a unique identifier in the cookie, and use server-side storage for most of the cookie payload
- remove unused or duplicated cookie fields
- for any page that serves more than 5 static resources, it is recommended that static content is served from a domain that doesn’t serve cookies
- reserve a cookieless domain for serving static content
- consult a CDN provider to get support with minimizing request overhead
Related articles: