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

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.

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.

How One AI-Driven Media Platform Cut EBS Costs for AWS ASGs by 48%

How One AI-Driven Media Platform Cut EBS Costs for AWS ASGs by 48%

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

Related articles:

Latest Articles

How Optimizing Kafka Can Save Costs of the Whole System

Kafka is no longer exclusively the domain of high-velocity Big Data use cases. Today, it is utilized on by workloads and companies of all sizes, supporting asynchronous communication between even small groups of microservices.  But this expanded usage has led to problems with cost creep that threaten many companies’ bottom lines. And due to the […]

29th September, 2024
Migrating Volumez RedHat VMs into Amazon Linux 2 for higher effective discounts rate of Saving Plan

A cloud data infrastructure company relied on extensive use of multiple instance types to test its products. But this made it difficult to optimize costs – a fact which had begun to impact their ability to scale the business.   The GlobalDots team helped the company identify and implement a new infrastructure configuration that both saved […]

19th September, 2024
How Yuki Achieved SOC 2 Compliance 6x Faster

Overview A fast-growing Snowflake optimization platform was missing out on customers because they didn’t have the right data security compliance. Through multiple consultations and extensive vendor-testing, the GlobalDots team selected a solution to provide both tech and human support, helping the company achieve SOC 2 compliance within just 3 months – and win new customers […]

16th September, 2024
Agile Content partners with GlobalDots to revolutionize CDN management ahead of IBC 2024

New partnership between Agile Content and GlobalDots promises to introduce automated multi-CDN solutions, optimizing content delivery and easing provider management for broadcasters worldwide. Amsterdam, Netherlands, September 9th, 2024 – Agile Content, a leading provider of digital TV and video distribution solutions, proudly announces its strategic partnership with GlobalDots, a global leader in cloud performance optimization and […]

Miguel Fersen Director for Iberia and LATAM, GlobalDots
12th September, 2024

Unlock Your Cloud Potential

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

    GlobalDots' industry expertise proactively addressed structural inefficiencies that would have otherwise hindered our success. Their laser focus is why I would recommend them as a partner to other companies

    Marco Kaiser
    Marco Kaiser

    CTO

    Legal Services

    GlobalDots has helped us to scale up our innovative capabilities, and in significantly improving our service provided to our clients

    Antonio Ostuni
    Antonio Ostuni

    CIO

    IT Services

    It's common for 3rd parties to work with a limited number of vendors - GlobalDots and its multi-vendor approach is different. Thanks to GlobalDots vendors umbrella, the hybrid-cloud migration was exceedingly smooth

    Motti Shpirer
    Motti Shpirer

    VP of Infrastructure & Technology

    Advertising Services