Web Performance 101: HTTP Headers

hypertext transfer protocol, or http, was first introduced by tim berners-lee in 1991. the initial version http/0.9 was designed to facilitate data transfers between a client and server. the protocol works on a request-response model over a tcp connection, but it’s evolved over the years to include several improvements and advanced features. the latest version is http/2, which has introduced major advancements that prioritize web page performance and speed.

this article discusses an important component of the http model – headers. before you continue, read this detailed blog post to understand how http works .

what are http headers?

there are three main components that make up the request/response structure. this includes:

• start line
• headers
• body/content

based on the type of the http message, the start line includes the method, path, status code, and protocol version. the http headers are added next and defined as name-value pairs separated by a colon. these headers are used to send additional parameters along with the request or response. the body of the message will include the data to be sent with the request or the data received along with the response.

there are different types of headers and we can group these based on its usage into 4 broad categories:

• general header
• request header
• response header
• entity header

1. general headers

headers that can be used in both requests and response messages and that are independent of the data being exchanged. some of the common general headers include:

1.1 cache-control

cache-control is a general header type that can be used to specify caching preference during the response-request cycle. the directives specified in the header must be strictly implemented when caching by the client and server.

for example, to cache a static file on a web page, you can define the header using the format below:

cache-control: public, max-age=31536000

• max-stale: client accepts expired content and allows you to configure response's expire time in seconds.
• max-age: specifies the maximum time for which a resource is considered fresh.
• min-fresh: client expects a response that’s fresh for at least the specified number of seconds.
• no-cache: the server must validate the cache content before sending it to a client.
• no-store: the cache is not allowed to store the request and response data.
• no-transform: the cache should not transform the stored content. for example, changing the image format to save space.
• only-if-cached: the client requires only cached content and the request does not check with the origin server for fresh content.
• must-revalidate: the fetched resource must be validated to ensure it is not stale.
• public: the response can be cached anywhere – private or shared cache.
• private: the response must be stored in private cache; shared caching is not allowed.
• proxy-revalidate: applies to shared caches, the response must be validated for freshness.

there are a few other header directives that are not part of the http caching standards. these are called extension cache-control directives; immutable is an example. the immutable directive indicates that the response body will remain unchanged so the client need not validate the content again.

1.2 connection

the connection header specifies if the http connection should remain open once the data exchange has completed. it sets up a persistent connection, which can be reused by subsequent requests.

to keep the connection open, the header is sent in the following format:

connection: keep-alive

the header directives include:

• keep-alive: the connection is persistent and once established, it remains open for all subsequent requests.
• close: this value instructs the client or server to close the connection.

1.3 transfer-encoding

transfer-encoding specifies the format or encoding to be used when transferring the content in the body of the message. for example, to indicate the file should be compressed, the header is sent in the following format:

transfer-encoding: compress

you can also specify multiple encoding formats separated by a comma. the directives for this header include:

• chunked: the content is split into chunks before transferring it to the client or server.
• deflate: the content is compressed using deflate compression algorithm.
• gzip: this is another compression format based on the unix gzip program.
• identity: indicates the content doesn’t need compression or modification.

2. request header

these headers define parameters for the data requested or parameters that give important information about the client making the request. some of the common request headers include:

2.1 accept-encoding

this request header specifies the encoding that the client supports. for example, to indicate the client understands multiple encoding, the header format will be:

accept-encoding: deflate, gzip;q=1.0, *;q=0.5

the values accepted by the header are:

• gzip
• compress
• deflate
• br (brotli algorithm)
• identity
• * (default header value)
• ;q= (q values weighting)

2.2 if-match

the if-match request header indicates a conditional request. the header returns the requested response only if it matches the etag (a unique identifier for a resource) or list of etag values specified in the header.

for example, to return a resource from the server that has any of the following etags, the header will be in the following format (where “w/” indicates a weak etag value that may not match byte for byte).

if-match: w/"67ab43", "54ed21", "7892dd"

2.3 if-modified-since

the header is another conditional request. the server will return the requested resource only if it has been modified after the specified date. if-modified-since is used only with a get or head request. for example, to return a request that was modified after october 1, the header is sent in this format:

if-modified-since: sun, 1 oct 2017 01:28:00 gmt

the request header accepts the following values in the date parameter:

if-modified-since: <day-name>, <day> <month> <year> <hour>:<minute>:<second> gmt

2.4 range

the range header specifies the part of the document/resource to be returned. it can be used to request partial content split into different ranges or just a single section of the content. for example, to get the data between a specific number of bytes, the header format will be:

range: bytes=200-1000, 2000-6576

to request from multiple parts of the same content, the header should be in the following format:

range: <unit>=<range-start>-<range-end>, <range-start>-<range-end>, <range-start>-<range-end>

2.5 user-agent

the user-agent request header provides details about the client application including the software version, application type, operating system, etc. the common user-agent header request will be in the following format:

user-agent: mozilla/<version> (<system-information>) <platform> (<platform-details>) <extensions>

here is an example of a firefox user agent string:

mozilla/5.0 (platform; rv:geckoversion) gecko/geckotrail firefox/firefoxversion

3. response header

these headers contain information about the incoming response. some of the common response headers are:

3.1 accept-ranges

this response header lets the client know that the server supports range requests. the header value specifies the unit of the range value. for example, if the range request is sent in bytes then the header format will be:

accept-ranges: bytes

3.2 etag

etag is a unique identifier for the requested resource. it makes it easy to identify the version of a cached resource and helps to keep track of updates made to the resource. an etag generated for an image on the web page will be sent along with other response header format:

etag: "<etag_value>"

for example:

etag:51baf2f08d0b59d55196aba274562dcc

3.3 location

the location response header indicates a page redirect and is sent along with a 3xx status response. it specifies a url to which the page redirects. the header format is as follows:

location: <url>

3.4 vary

this response header specifies the set of request header values to determine whether the cached resource that was requested should be revalidated. for example: to serve the mobile version of a cached resource, we can use the following vary header value so that it checks the user-agent header before serving the resource.

vary: user-agent

4. entity header

the entity headers describe the content that makes up the body of the message. some of the common entity headers are:

4.1 allow

the allow entity header is used to list the methods that are accepted by the requested resource. for example, the following header values specify that the http methods that are relevant to the resource.

allow: get, post, head

4.2 content-encoding

the entity header indicates the type of encoding that was used in the message body. the header is sent in the following format:

content-encoding: gzip

multiple encoding types can be listed in the same header:

content-encoding: deflate, gzip

4.3 content-length

this header specifies the size of the entity or the message body. the header format is:

content-length: <length>

for example:

content-length: 3495

here the length is in decimals of octets.

4.4 expires

the expires header indicated the date and time for which the resource may be considered fresh. for example, if a resource is stale after 10 ^th october, then the header will be:

expires: wed, 21 oct 2015 07:28:00 gmt