Web Performance 101: HTTP Headers, Part 2
Web Performance 101: HTTP Headers, Part 2
Welcome back! We continue our series on web performance and HTTP headers by looking at the three types of HTTP Headers: caching, compression, and security.
Join the DZone community and get the full member experience.Join For Free
xMatters delivers integration-driven collaboration that relays data between systems, while engaging the right people to proactively resolve issues. Read the Monitoring in a Connected Enterprise whitepaper and learn about 3 tools for resolving incidents quickly.
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 :
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 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
2. To indicate cache validation on the origin server, we can use the option:
3. To specify where the type of caching is to be used, that is, whether the resource can be stored on any cache or, specifically, a private cache, set the following options:
Cache-Control: private Cache-Control: public
4. 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:
5. If a cached resource needs to be validated for freshness before serving, then we use the following parameter:
Pragma is an outdated header, that 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.
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:
- 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 or 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.
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.
2. Hop-by-hop headers: The hop-by-hop headers are neither retransmitted between proxies nor are they 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 Or 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.
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. These headers help patch any security vulnerabilities and provide 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 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 https://www.google-analytics.com
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 a MiTM attack using forged certificates.
Public-Key-Pins: pin-sha256="cUPcluytzOJAhhneDttWpY3oBAkE3h2+soZS7sWs="; pin-sha256="M8HztCzM3elUkjdekjkfdppqweHkmjAHKhpGPWE="; max-age=5184000; includeSubDomains; report-uri=https://www.example.org/
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.
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.
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
Published at DZone with permission of Kameerath Kareem , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.