Google’s Web Performance Best Practices #3: Minimize Request Overhead

GlobalDots
5 Min read

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.

cookie_mon

Image 1 – Minimizing request overhead means keeping cookies and request headers as small as possible

Image source

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.”

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
globaldots-main-cta-cdn

Related articles:

Latest Articles

FinOps Tools: Key Factors to Consider

For organizations already well-established in the cloud, vendors such as AWS and Azure often bite large chunks out of annual revenue. Monthly cloud bills accumulate quickly  – the 5 biggest cloud vendors rake in a combined total revenue of over $80 billion a year, with Microsoft and Amazon claiming the lion’s share of over $20 […]

Nesh (Steven Puddephatt) Senior Solutions Engineer @ GlobalDots
22nd November, 2023
AWS Innovations Decoded: GlobalDots’ Top 20 Picks

Join AWS experts from GlobalDots as they decode the top 20 cloud innovations you need to know in a 2 part Webinar. Gain insider insights on leveraging these transformative technologies to boost performance, tighten security, and reduce costs. Discover real-world applications to apply these advancements to your business. Reserve your spot now! 🚀 Stay Ahead: Learn […]

GlobalDots
31st October, 2023
Innovative Cloud Strategy eBook

CIOs, Infrastructure Chiefs, IT, and Security Pioneers – This guide is more than just a document. It’s a strategic blueprint for your cloud journey, including concrete steps for migration, security strategies, and proven methods to optimize cost. We’re talking about real solutions for real challenges, such as: And yes, even – Discover not just security […]

Nesh (Steven Puddephatt) Senior Solutions Engineer @ GlobalDots
22nd October, 2023
Making Cloud Compliance Easy

The Challenge: Dealing with the Back-and-Forth There are so many shared challenges when it comes to cloud compliance. The constant back-and-forth with the auditor has become a draining routine. As you dart through digital archives for necessary audit evidence, precious minutes slip away from your actual duties. Each passing hour pulls you further from your […]

GlobalDots
16th October, 2023

Unlock Your Cloud Potential

Schedule a call with our experts. Discover new technology and get recommendations to improve your performance.

Unlock Your Cloud Potential