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

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

Admin Globaldots
23.10.2013
image 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.”

 

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

 

globaldots-main-cta-cdn

Learn More

Long-Term LastPass Breach Sounds Alarm For Static Credentials
Identity & Access Management (IAM)
Admin Globaldots 02.03.23

LastPass’ password management service has introduced millions of users to the convenience and security of unique passwords. Across mobile and browser, LastPass promises a near-passwordless experience for millions of individuals and over 100,000 businesses. However, recent news threatens to drop a bombshell on credential-based security.  The Year-Long LastPass Dual Breach  In August 2022, LastPass released […]

Read more
You’ll Need Zero Trust, But You Won’t Get It with a VPN
SD-WAN and SASE
Admin Globaldots 12.01.23

Properly implemented, a zero trust architecture provides much more granular and effective security than legacy security models. However, this is only true if a zero trust initiative is supported with the right tools. Legacy solutions, such as virtual private networks (VPNs), lack the capabilities necessary to implement a zero trust security strategy. Zero Trust Security is […]

Read more
4 Ways Where Remote Access VPNs Fall Short
SD-WAN and SASE
Admin Globaldots 09.01.23

The Global Content Delivery Network (CDN) market is expected to grow by $42.4 billion between now and 2032.

Read more
Unlock Your Cloud Potential
Schedule a call with our experts. Discover new technology and get recommendations to improve your performance.
Book a Demo