Dynamic compression

Dynamic compression works with global external HTTP(S) load balancer (classic) to automatically compress responses served by Cloud CDN between the origin and the client. The size of the data sent over the network is reduced by 60% to 85% in typical cases.

The size reduction reduces the time it takes to download content. For important assets like stylesheets (CSS), scripts (JavaScript), and video manifests (HLS/DASH), this can reduce page load and video start times.

You can learn more about the benefits of compressing responses in the Web Fundamentals guide.

Example use cases

Dynamic compression directly reduces the size of data sent from the Cloud CDN edge to the client. This can directly do the following:

  • Reduce the size of CSS and JavaScript, helping web pages render faster and reducing the time to First Contentful Paint, an important web performance metric.
  • Have a large, positive impact when caching REST API responses, such as JSON payloads. These payloads compress well due to the repeated keys, whitespace, and braces. Caching public APIs for 5-10 seconds is a popular approach to reducing origin load while maintaining the freshness of data.
  • Improve playback start time for video delivery and join latency for live streaming. Large live playlists (manifests) have a significant amount of repeated data, including the host + path prefix of each segment, as well as the HLS or DASH playlist metadata. The faster the playlist loads or playlist updates can be downloaded, the less time a client is waiting to parse and start downloading the referenced video segments. HLS and DASH playlists often see a total size reduction of more than 90%.

Enable compression

You can enable compression on a backend service or a backend bucket.

Before you begin

  • Make sure that you have a Cloud CDN-enabled global external HTTP(S) load balancer (classic) and a backend configured. If you don't have Cloud CDN currently configured, you can follow one of the setup guides.
  • Your backend has compressible content ready to serve, such as web assets or video manifests between 1 KiB and 10 MiB (inclusive).
  • Make sure that clients don't rely on fetching partial content with range requests or with strong ETags. These are incompatible with dynamic compression.
  • You have the IAM Compute Load Balancer Admin role (roles/compute.loadBalancerAdmin), which is required to make changes to your backend configuration.

Enable compression on a backend service or backend bucket

Console

Enabling dynamic compression in the Google Cloud console is not yet supported.

gcloud

For backend services, use the gcloud beta compute backend-services create or gcloud beta compute backend-services update command with the --compression-mode flag.

For backend buckets, use the gcloud beta compute backend-buckets create or gcloud beta compute backend-buckets update command with the --compression-mode flag.

For a new backend service, use the create command:

gcloud beta compute backend-services create BACKEND_SERVICE_NAME \
    --compression-mode=AUTOMATIC

For an existing backend service, use the update command:

gcloud beta compute backend-services update BACKEND_SERVICE_NAME \
    --compression-mode=AUTOMATIC

For a new backend bucket, use the create command:

gcloud beta compute backend-buckets create BACKEND_BUCKET_NAME
    --compression-mode=AUTOMATIC

For an existing backend bucket, use the update command:

gcloud beta compute backend-buckets update BACKEND_BUCKET_NAME
    --compression-mode=AUTOMATIC

The compression-mode can be one of the following:

  • AUTOMATIC: Automatically compresses the content.
  • DISABLED (default): Disables compression.

    • API

    For backend services, use the Method: backendServices.insert or Method: backendServices.update API call.

    For backend buckets, use the Method: backendBuckets.insert or Method: backendBuckets.update API call.

    Use one of the following API calls:

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices

    PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets

    PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets/BACKEND_BUCKET

    Add the following snippet to the JSON request body:

    "compressionMode": AUTOMATIC

    The compression-mode can be one of the following:

  • AUTOMATIC: Automatically compresses the content.
  • DISABLED (default): Disables compression.

    • Within a few minutes, your configuration propagates to all edge locations. Compressible content served from the backend is compressed before being delivered to the client.

    Compression modes

    The default compression mode is DISABLED. Only backends with a loadBalancingScheme of EXTERNAL can configure a compression mode other than DISABLED.

    AUTOMATIC mode allows Cloud CDN to choose the best compression method based on the following:

    • The client's accepted encoding
    • The response's anticipated compression ratio
    • Cloud CDN's compression speed (throughput)

    Cloud CDN determines the compression level to balance total download size and CPU cost on the client. Higher compression levels do not always benefit performance, especially on lower-powered mobile devices.

    When is a response compressed?

    Only gzip compression is currently supported. If the client includes gzip in its list of Accept-Encoding encodings, Cloud CDN uses gzip to compress the response; otherwise, Cloud CDN doesn't compress the response.

    Responses are currently only compressed if they are cacheable.

    Compressible content types

    Dynamic compression applies to the following MIME types, based on the Content-Type HTTP response header. Responses that don't have a Content-Type response header aren't compressed.

    Common content types and their MIME types include the following:

    • HTML content: text/html
    • Stylesheets: text/css
    • JavaScript: application/javascript
    • JSON: application/json
    • HLS playlists: application/x-mpegURL or application/vnd.apple.mpegURL
    • DASH manifests: application/dash+xml

    The following table summarizes how the MIME type affects compressibility.

      Compressible MIME types
    Exact match application/x-javascript
    application/x-sdch-dictionary
    application/javascript
    application/xml
    application/csv
    application/json
    application/json+protobuf
    application/signed-exchange
    application/vnd.apple.mpegurl
    application/wasm
    application/x-plist
    application/x-protobuffer
    application/x-protobuf
    application/x-nacl
    application/x-pnacl
    font/ttf
    font/otf
    font/eot
    image/svg+xml
    image/pwg-raster
    image/x-icon
    image/vnd.microsoft.icon
    video/vnd.mpeg.dash.mpd
    application/dicom+json
    audio/mpegURL
    application/dash+xml
    application/vnd.ms-sstr+xml
    Pattern match application/*+xml
    text/*
    application/*mpegURL

    Image and video formats (such as image/jpeg, image/png, and video/mpeg4) are almost always already compressed, so Cloud CDN doesn't compress them. Re-compressing an already compressed response rarely reduces file size, and clients might exhibit unexpected behavior when receiving a response of this kind.

    When is a response not compressed?

    Dynamic compression doesn't compress a response when the response has one or more of the following characteristics:

    • No Content-Type header matching a compressible content type
    • No Content-Length header

    • Smaller than 1 KiB

      The time spent compressing and decompressing often offsets any benefits. There is also less content to compress, which can reduce the effectiveness of compression (a lower compression ratio).

    • Larger than 10 MiB

    • A Cache-Control: no-transform directive

    Range requests

    When dynamic compression is enabled on a backend, range support is disabled:

    • Range and If-Range headers are removed from all requests.
    • Accept-Ranges: bytes headers are removed from all responses.

    This prevents serving incorrect partial content to clients because there is no way to be sure whether a client expects a range of bytes from the compressed or uncompressed form of a resource.

    ETags

    When dynamic compression compresses a response, any strong ETag headers are weakened, as required by RFC 7232 section 2.3. For example, ETag: "xyzzy" is replaced with ETag: W/"xyzzy".

    Vary header

    If a response has the potential to be compressed (depending on the request), the response is served to the client with a Vary: Accept-Encoding header.

    Billing

    When a response is compressed by Cloud CDN or Cloud Load Balancing, the relevant cache egress or internet egress (respectively) is measured against the final compressed bytes sent to the client.

    If you are serving a large amount of compressible responses, this can result in a reduction in your monthly egress fees, as well as increased performance for end users.

    Metrics

    When compression is enabled, the existing https/response_bytes_count metric under loadbalancing.googleapis.com reports the compressed response size.

    You should expect to see a drop in total response bytes (and egress throughput).

    If you are serving a large amount of text-based content that compresses well, such as HTML, CSS, JavaScript, or JSON, you might see a large drop in response bytes.

    For more information, see Monitoring.

    What's next