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
orapplication/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
andIf-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
- To understand how cache modes make it easier to cache content, see Using cache modes.
- To enable Cloud CDN for your HTTP(S) load balanced instances and storage buckets, see Using Cloud CDN.
- To learn about invalidating caches, see Cache invalidation overview.
- To find GFE points of presence, see Cache locations.