Performance improvement & cost reduction with GCP Cloud CDN Dynamic compression

Introduction

We all have used compression tools like winzip , winrar in our IT lives to reduce the size of files , photos etc . The main advantages of compression are reductions in storage space , data transmission time, and communication bandwidth. Compressed files require significantly less storage capacity than uncompressed files, meaning a significant decrease in expenses for storage. A compressed file also requires less time for transfer while consuming less network bandwidth. This can also help with costs, and increase productivity.

From the perspective of CDN usecase , most customers opt-in for CDN to get advantage of accelerated web delivery . Hence compression functionality in CDN provides a multiplier effect to end user experience and improves important parameters like a page-load . To put it in perspective, 2 major advantages that a CDN customer will get by opting for compression are -

1. Performance : This is because we are sending less bytes and hence statistics like page-load time etc improve.
2. Cost Efficiency : Since one of the cost parameters of CDN is volume of traffic egress by CDN , less egress traffic will mean less CDN bill.

Google Cloud CDN provides a feature called “Dynamic Compression” which works with global external HTTP(S) load balancer to automatically compress responses served by Cloud CDN between the origin and the client. This blog primarily focuses on the dynamic compression feature of Google Cloud CDN. All modern browsers support compression and the only thing to negotiate is the compression algorithm used between web-browser and server. Nowadays, two algorithms are relevant: gzip, which is the most common one, and brotli , which is the new challenger.

At a high level , browsers send an Accept-Encoding header with the algorithm it supports and its order of precedence, the server picks one, uses it to compress the body of the response and uses the Content-Encoding header to tell the browser the algorithm it has chosen.

Test Topology

In this blog , I want to showcase the steps to enable Dynamic compression on Google Cloud CDN and also steps to verify the functionality. For the purpose of this blog , I have used a demo setup on GCP having following components-

• I have a Google cloud storage (GCS) bucket and a JSON files uploaded in bucket
• I will attempt to serve this JSON file via Google Cloud CDN
• I have end clients sending requests with Accept-encoding : gzip in this test

Below is high level representation of topology that is used to test dynamic compression on Google Cloud CDN

Load Balancer and CDN configuration settings

The idea of this blog is not to explain how Cloud CDN is configured or how https load balancer works . Readers may read following GCP documentation for the same -

• How to setup GCP HTTPS LB for external backend
• Setting up Cloud CDN

To benefit the readers , following is snapshot of my backend service which I used while testing

$ gcloud compute backend-services describe servneg — global

affinityCookieTtlSec: 0

backends:

- balancingMode: UTILIZATION

capacityScaler: 1.0

group: https://www.googleapis.com/compute/v1/projects/m-aaaa-aaaa/global/networkEndpointGroups/cdn-neg

cdnPolicy:

cacheKeyPolicy:

includeHost: true

includeProtocol: true

includeQueryString: true

cacheMode: CACHE_ALL_STATIC

clientTtl: 3600

defaultTtl: 3600

maxTtl: 86400

negativeCaching: false

requestCoalescing: true

serveWhileStale: 0

connectionDraining:

drainingTimeoutSec: 0

creationTimestamp: ‘2022–08–02T22:00:12.236–07:00’

customRequestHeaders:

- Host:storage.googleapis.com

customResponseHeaders:

- cache-status:{cdn_cache_status}

description: ‘’

enableCDN: true

fingerprint: PgKJ8FWxNHA=

id: ‘121325304488115763’

kind: compute#backendService

loadBalancingScheme: EXTERNAL

logConfig:

enable: true

sampleRate: 1.0

name: servneg

port: 80

portName: http

protocol: HTTP

selfLink: https://www.googleapis.com/compute/v1/projects/m-aaaa-aaaa/global/backendServices/servneg

sessionAffinity: NONE

timeoutSec: 30

How to Enable / Disable the Compression

Please use one of the following methods (gcloud CLI or GCP console UI ) to disable / enable the compression.

The gcloud command to enable automatic compression the same is as follows

gcloud compute backend-buckets update YOUR_BUCKET \

— compression-mode=AUTOMATIC

The gcloud command to disable automatic compression the same is as follows

gcloud compute backend-buckets update YOUR_BUCKET \

— compression-mode=DISABLED

If you wish to edit the already existing backend service using Google Cloud console (web-UI) , please follow the following

Figure : Enable / Disable Dynamic Compression for GCP Cloud CDN

How to verify compression

There are multiple ways that help the client to ensure that compression was done by Cloud CDN. Some of them are as follows -

1. Look into the response header of requests served by Cloud CDN . We will see that the response is served to the client with a Vary: Accept-Encoding header.

2. You may look into the ‘content-length’ section of the response header to conclude that the response is compressed . The same content served without compression gives me following results

Hence you can see that the content length was 6162 with compression and 115667 without compression

3. Under GCP logs , you can see the size and conclude if the compression has taken place or not . Example below shows the same file served with compression and without compression.

Points to consider

There are some important points to note for Cloud CDN compression -

1. Cloud CDN Compression applies only to objects between 1 KiB and 10 MiB (inclusive).
2. There are certain MIME types which will only be compressed like text/html , text/csv , application/json , application/javascript etc . The exhaustive list is mentioned in this link
3. If a browser is sending a request with preferred compression algorithm (via weights) like “ br;q=1.0, gzip;q=0.8, *;q=0.1 “ ; since the request is sent with preference for “br” , cloud cdn will compress the object using the ‘br’ compression algorithm .
4. If a browser sends requests with no preference weight like just sending accept-encoding as “ gzip , br “ ; Cloud CDN will use ‘br’ as the preferred algorithm of compression.
5. If a client request with accept-encoding header is sent for a object and it is a “cache-miss” ; the object is fetched from backend origin (lets say backend returned a uncompressed object) → the object is compressed by Cloud CDN → compressed copy of object is stored in cache → and served back to requesting client . Please note : first reply to such client will be uncompressed copy of object and post that CDN will have compressed copy of object in cache and the same will be served to end client.
6. If a client request is sent for a object with accept-encoding header , but the object is present in cache as ‘uncompressed’ ; Cloud CDN will compress the object with appropriate algorithm and then serve to end customer.
7. If object is more than 10MiB , Cloud CDN dynamic compression is not applicable . Hence if a customer requested a small byte-range[ ex 1–100 ] ; he will get requested byte-range served (without compression).

Closing Notes:

For existing Google Cloud CDN customers whose content lie within eligibility criteria of content that can be compressed by Cloud CDN , it is a no brainer to have this feature enabled (specially because this comes at no cost) . Post enabling this feature , customers should see a decline in egress CDN data volume and hence should be able to enjoy a reduced monthly spend on Cloud CDN.

For a category of customers , who have taken care of compression at their backend ; this feature is not of any worry . GCP cloud CDN will not attempt to compress the already compressed object being served by the backend . Hence there will not be any change to such customer’s applications.

GCP Cloud CDN’s dynamic compression is a simple automatic / disable configurable item for customers . Hence the customer is not required to give too much planning and attention for configuring this feature . Kudos to GCP for making this really ‘turn-key’ and taking away the complexity .

Disclaimer: This is to inform readers that the views, thoughts, and opinions expressed in the text belong solely to the author, and not necessarily to the author’s employer, organization, committee or other group or individual.