Compression

• Your origin server(s). This is known as origin server compression.
• Our edge servers. This is known as edge server compression.
• Our cloud.

Origin Server Compression #

1. The client’s request must contain an Accept-Encoding request header set to one or more of the following values:
   br | gzip | deflate | bzip2
   Example: Accept-Encoding: br, gzip, deflate
2. The web server(s) associated with your origin configuration must support the compression method defined within the Accept-Encoding request header.

Edge Server Compression #

Enabling Edge Server Compression #

1. Create or modify a rule that identifies the set of requests on which compression will be enabled.
2. Add the Compress Content Types feature (compress_content_types) to it. Set it to the desired set of content types.

• Rules:
  The following configuration enables edge server compression for the 4 sample content types described above.

  

• CDN-as-Code:
  The following sample rule enables edge server compression across all requests for the 4 sample content types described above.
  JavaScript./routes.js

  Copy

  1export default new Router().match(
  2  {},
  3  {
  4    response: {
  5      compress_content_types: [
  6        "text/plain",
  7        "text/html",
  8        "text/css",
  9        "text/javascript",
  10      ],
  11    },
  12  }
  13);

Cache Implications #

How Does Compression Work? #

1. Does the request contain an Accept-Encoding header?
   • Yes: Does it contain a supported compression method?
     • Yes: Proceed to step 2.
     • No: Our edge servers will check whether an asset compressed using that method has been cached. If this check results in a cache hit, then our edge servers will serve it immediately. Otherwise, it is a cache miss and our edge servers will retrieve it from your origin configuration or the Edgio cloud. Skip to step 3.
   • No: Requests that are missing the Accept-Encoding header are served in an uncompressed format. This response is derived from either an origin server, the Edgio cloud, or cache.
2. An edge server on the POP closest to the client will check to see if the requested content has been cached and if it still has a valid TTL.
   • Cache Miss: If a cached version of the requested content is not found, then the request will be forwarded to an origin server or the Edgio cloud. Proceed to step 3.
   • Cache Hit & Matching Compression Method: An edge server will immediately deliver the compressed content to the client.
   • Cache Hit & Different Compression Method: If the client requests a supported compression method that is different from the cached content’s compression method and the request is eligible for edge server compression, then an edge server will transcode the asset to the requested compression method and deliver it.
   • Uncompressed Cache Hit: If the initial request caused the asset to be cached in an uncompressed format, then a check will be performed to see whether the request is eligible for edge server compression.
     • Eligible: An edge server will serve the uncompressed content to the client. After which, if the request is eligible for caching, an edge server may compress the requested content and then cache the compressed version. Your caching policy dictates whether the compressed asset is eligible to be cached.
     • Ineligible: An edge server will immediately deliver the uncompressed content to the client.
3. The request will be forwarded to either an origin server or the Edgio cloud. Either entity will provide a compressed or uncompressed response according to whether it can apply compression. Edgio will serve the response to the client. Your caching policy dictates whether the response will be cached.

Applying Brotli Compression through the Edgio Cloud #

1import { brotliCompressSync } from 'zlib'
2
3const BROTLI_ENCODING_REGEX = /\bbr\b/
4
5// This function will respond with Brotli encoded body if the user agent
6// accepts Brotli.
7// Prior to invoking this function, evaluate all the custom criteria that you want to apply
8// (e.g. content type, caching, size of the response, etc). If all those are satisfied then
9// invoke this function which will then check if the downstream is Brotli compatible and
10// if so compress the body and respond with it, returning true, otherwise returning false.
11// You can of course optimize this to first check the downstream compatibility
12// before even considering other criteria.
13const sendBrotliEncoded = (req, res, body) => {
14  const acceptEncoding = req.getHeader('Accept-Encoding')
15  const acceptBrotliEncoding = BROTLI_ENCODING_REGEX.test(acceptEncoding)
16  if (!acceptBrotliEncoding) {
17    return false
18  }
19
20  const encodedBody = brotliCompressSync(Buffer.from(body))
21  res.setHeader('content-length', Buffer.byteLength(encodedBody))
22  res.setHeader('content-encoding', 'br')
23  res.send(encodedBody)
24  return true
25}

1const useBrotliEncoding = /* Evaluate all the custom criteria that you would like to apply */;
2  if (!useBrotliEncoding || !sendBrotliEncoded(req, res, body)) {
3    res.send(body)
4  }

Compressible Types #

• The Content-Type header contains any of the following values:
  • text/html
  • application/x-javascript
  • text/css
  • application/javascript
  • text/javascript
  • application/json
  • application/vnd.ms-fontobject
  • application/x-font-opentype
  • application/x-font-truetype
  • application/x-font-ttf
  • application/xml
  • font/eot
  • font/opentype
  • font/otf
  • image/svg+xml
  • image/vnd.microsoft.icon
  • text/plain
  • text/xml
• The URL ends with one of these file extensions:
  • .css
  • .js
  • .html
  • .eot
  • .ico
  • .otf
  • .ttf
  • .json
  • .svg