The importance of web page loading time is undoubted. Website speed optimization is able
to boost user experiences, improve customer loyalty, reduce bounce rate, increase conversions, and take your website to better positions in SERP.

When it comes to speed optimization techniques, the use of HTTP caching is a very important one that every developer knows about. Little but very important caching “assistants” are HTTP headers. Today, we will discuss the role of HTTP caching in speed improvement, what HTTP headers are, and take a special tour of cache-related HTTP response headers.

Reducing network requests with HTTP caching

When a user visits a web page, all its resources need to be retrieved from the server so it is displayed in the user’s browser. These include the images, the text, the CSS styles, the JS scripts, and other assets. Repeated round trips between the browser and the server on every request can put an unnecessary load on the system and substantially slow down your website performance.

Luckily, it is not necessary to fetch everything from the server with every single visit — here is where the caching technique comes in. The copies of the resources are stored in the HTTP cache (also known as “web cache” or “disk cache”). Next time the resources are requested they are served from there. If the requested asset is in the cache, the request is intercepted and the resource copy is served to the client. The reusing of the previously fetched resources significantly relieves the load on the web server and reduces the time needed to display a web page in the user’s browser.

Of course, web page assets do not stay the same forever, so caching requires the right configuration. You can avoid the fetching of outdated resources by configuring their expiration at specific times. While making these settings, developers need to define which website elements usually remain unchanged (for example, the logo) and which are more dynamic (for example, the scripts), and how often they change.

Indeed, for the caching to be carried out properly, the communication between clients and servers needs to be effective. Just like in every other communication, the effectiveness depends on the timely and full delivery of the necessary information. How to provide this?

A set of rules that describe how a web browser and a web server can communicate with each other are defined by the semantics of the Hypertext Transfer Protocol (HTTP). Among other things, the HTTP protocol defines the main mechanisms of cache control.

The HTTP protocol is based on a request/response model between clients and servers. The client connects to the server and sends a request with some additional information. The server issues a response with the requested data and some additional information as well. This additional information is held in HTTP headers that we are now moving on to.

What are HTTP headers?

HTTP headers are a series of key-value pairs that help the client and the server exchange the needed additional information about the web page’s resources. A typical HTTP header includes a name, a colon (:), and a value. Before the value, there is whitespace, which is ignored. A header name is case-insensitive, which means that "Cache-Control" would be the same as "cache-control."

According to developer.mozilla.org, several groups of headers can be distinguished based on their mission:

Request headers

Headers of this type include extra information about the resource that needs to be fetched or about the client that is making the request.

Response headers

Headers of the response type contain the information about the location of the response, the server that provides it, and other response-related information.

Representation headers

Representation HTTP headers hold the information about the particular representation, or version, of the resource that is sent in an HTTP message body.

Payload headers

HTTP headers of this type hold information about the payload data that might refer to the content amount or the encoding applied.

Cache-related HTTP response headers

Let’s take a closer look at some of the most important headers meant for providing information about the HTTP responses. The headers that your web server adds to the outgoing responses are actually the most significant part of the HTTP caching setup. HTTP response headers are important for identifying the cache layers used in particular requests.

Example of HTTP response header from Google.com:

When it comes to naming specific response headers, they are listed on the IANA (Internet Assigned Numbers Authority), but developers and vendors can add their own proprietary (also known as custom) headers. Here are some examples of common cache-related HTTP headers that are not proprietary.

Cache-control

The Cache-control HTTP headers contain the instructions (or directives) for caching. They allow every resource to have its own caching policy. Headers of this type are used both in responses and requests. For responses, it specifies how and for how long browsers and other caches should cash the response. Here are some of the most common directives that can be provided by the Cache-control headers in HTTP responses:

• Must-revalidate
  This directive shows that the resource requires validation on the server once it becomes stale. Without revalidation, it cannot be sent to the client. Its outdated copy becomes no longer valid to be used by caches.
• Proxy-revalidate
  This one is similar to the above-mentioned must-revalidate but is meant for proxies or other shared caches.
• No-cache
  This means that the resource can be cached but revalidated on every request to be checked for “freshness.” No-cache is mutually exclusive with no-store.
• No-store
  This directive indicates that the resource cannot be cashed in any way. It is especially great for resources with sensitive data. No-store is mutually exclusive with no-cache.
• No-transform
  With no-transform, the response body cannot be modified in any way. For example, proxy or browser features are not allowed to minimize the files.
• Public
  This directive shows that the resource can be cached by any cache (browser cache or intermediate cache). “Public” is mutually exclusive with “private.”
• Private
  This one is for browser caching only. The resources cannot be stored in the intermediate cache. “Private” is mutually exclusive with “public.”
• Max-age
  This one indicates the maximum time that a resource remains fresh and can be reused from the moment the request is made. For example, max-age=60 shows the resource can be used again for the next 60 seconds.
• S-maxage
  This directive is used for shared caches ( "s-" stands for shared). It overrides the max-age or the expires.

Expires

The Expires header contains the date or time when a specific object should be considered outdated and needs to be refreshed from the source. This header is ignored if the response contains a Cache-Control: max-age or Cache-Control: s-maxage header. The Expires header is losing popularity with modern browsers and is often used as a fallback since there is a more modern Cache-Control header. In order to prevent caching, there is a practice to set the time in the past or put the null value.

Age

The Age header specifies how much time in seconds the resource has spent in the cache.

ETag

The ETag header shows if there have been changes to content. It resembles a serial number that the browser sends to the server in order to check if the resource has been changed. If the number returns the same, this means no changes.

Last-Modified

Similar to ETag, the Last-Modified header checks if the object has changed but its approach is time-based. It includes the date and time at which the resource was last modified.

Example of HTTP response headers for the Drupal CMS created by the HTTP Response Headers add-on module:

Final thoughts

By providing the right caching information, cache-related response headers help websites run faster. If you need help in configuring all the details of caching for your website, contact our team of professional developers. Waiting to hear from you!