Blog Post

Web Performance 101: HTTP Headers Part 2

Headers can affect page performance in multiple ways, but there are three major factors that can negatively and/or positively affect the digital experience

We recently reviewed some essential HTTP headers and how they are implemented in a previous blog post. Headers can affect page performance in multiple ways, but there are three major factors that can negatively and/or positively affect the digital experience :

  • Caching
  • Compression
  • Security

This article discusses how headers can help optimize website performance. We will focus on headers that help implement caching, compression, and security efficiently and how it impacts the overall digital experience.

Caching Headers

Caching is an important webpage optimization technique that can greatly impact performance. When resources are cached, it means a copy of the resource has been saved to a cache server or a local server. Caching can greatly reduce network latency, making the page render faster. There are two types of caching techniques in use today:

  • Shared proxy caching – the cached resources are stored in a shared network location. These resources are reused multiple times by different users and it cuts down the number of roundtrips to the server, reducing network congestion and latency.
  • Local caching – the cache is stored locally by the browser. The browser caches the page content which greatly reduces the page load time, as the browser does not have to make repeated requests to the web server for a resource it has already downloaded and cached.

Let’s look at the HTTP headers that help you control caching behavior:


The Cache-control header is used to define the caching policies for the session. There are several parameters that can be set for HTTP requests and response; these parameters will indicate how the client and server handle caching.

  1. To specify the cache should not be stored, we can use the following options

Cache-Control: no-store

Cache-Control: no-cache, no-store, must-revalidate

  1. To indicate cache validation on the origin server, we can use the option

Cache-Control: no-cache

  1. To specify where the type of caching to be used, that is, whether the resource can be stored on any cache or specifically private cache, set the following options

Cache-Control: private

Cache-Control: public

  1. To specify the time for which a resource is considered fresh and when it should be refreshed from the origin server, set the parameter using max-age

Cache-Control: max-age=31536000

  1. If a cached resource needs to be validated for freshness before serving, then we use the following parameter

Cache-Control: must-revalidate


Pragma is an outdated header, it serves the same purpose as the Cache-Control header which was introduced in HTTP/1.1; but unlike the Cache-Control header, the Pragma header is specific to HTTP requests and not used in the response. The header is still in use to ensure compatibility with clients who don’t support HTTP/1.1.

Implementing the relevant HTTP caching headers can help reduce the browser overhead and speed up page rendering. It can have a positive impact on the user’s digital experience; you can read about the major impact caching has in this blog post.

Compression Headers

Data compression makes data transfers more efficient, freeing up bandwidth and speeding up the page load. Compression algorithms (like gzip and Brotli) can cut down file size by almost 70% which has a huge impact on the performance of modern content heavy websites.

HTTP headers can be used to enable compression and configure the accepted compression formats. There are mainly two categories of headers depending on the type of data compression that is to be configured:

  1. End-to-end headers: This category of HTTP headers is used to set up end-to-end compression which means the message body is compressed by the server and it remains compressed till it reaches the client. The headers must be transmitted from the server to client without modification.

When the browser makes am HTTP request, it sends an Accept-Encoding header that specifies the  compression algorithm it supports.

Accept-Encoding: gzip


Accept-Encoding: gzip, compress, br

The server then sends the requested content after compression with the response header Content-Encoding. This header indicates the algorithm selected by the server from the list specified by the browser.

Content-Encoding: gzip

In addition to these headers, the response could also include a Vary header that will indicate the header that was used to decide the compression type so that subsequent requests will know the format of the cached resource.

Vary: Content-Encoding

  1. Hop-by-hop headers: The hop-by-hop headers are not retransmitted between proxies and nor is it cached. The resource is transmitted in a compressed or uncompressed format between each hop from the server to the client. This is usually done using the TE header or Transfer-Encoding header.

TE: compress, gzip , deflate


Transfer-Encoding: gzip, compress

It is highly recommended to take advantage of data compression when optimizing your website. Reducing the file size without compromising the data quality involves complex and advanced algorithms, take an in-depth look at how this works in this detailed blog post about compression techniques.

Security Headers

HTTP security headers can be used to define the security policies that must be followed during the HTTP session; it instructs the clients on how to handle the content that it has requested for. These headers help patch any security vulnerabilities and provides protection against data injection and Cross Site Scripting attacks. Let us look at some of the headers in the category.


The Content-Security-Policy header is used to specify the type of resources and scripts the user agent is allowed to load. This means that the browser can access only those content that has been approved by the website administrator. For example, we can specify a list of the source from which to download scripts.

Content-Security-Policy: script-src


Man-in-the-middle attack (MitM) can be mitigated by configuring the Public-Key-Pins header. It assigns a cryptographic key to the web server, minimizing the chance of an MITM attack using forged certificates.




max-age=5184000; includeSubDomains;



The Strict-Transport-Security header forces the browser to access the web server through HTTPS alone. The header will redirect all HTTP requests to HTTPS which means that the user is viewing only the encrypted and secure version of the website.

Strict-Transport-Security: max-age=31536000; includeSubDomains


This header prevents the browser from trying to guess the MIME type of the requested resource. X-Content-Type-Options when used along Content-Type will specify the MIME and prevent MIME type sniffing.

X-Content-Type-Options: nosniff


The X-Frame-Options header will indicate if the content within tags such as <iframe> or <object> should be allowed to load. For example, the following header will allow iframes with content from the same server to load and block those with content from a different server.

X-Frame-Options: SAMEORIGIN


This header is an added layer of security against cross-site scripting or XSS attacks. Most modern browsers have a default filter that detects potential XSS requests and this can be strictly enforced using the x-xss-protection header.

x-xss-protection: 1; mode=block

Synthetic Monitoring
Network Reachability
Workforce Experience
SaaS Application Monitoring
This is some text inside of a div block.

You might also like

Blog post

Traceroute InSession: A traceroute tool for modern networks

Blog post

The cost of inaction: A CIO’s primer on why investing in Internet Performance Monitoring can’t wait

Blog post

2024 Unveiled: Catchpoint's Predictions for APM, ITOM, OTel & Beyond