Amazon CloudFront
Developer Guide (API Version 2014-11-06)
Did this page help you?  Yes | No |  Tell us about it...
« PreviousNext »
View the PDF for this guide.Go to the AWS Discussion Forum for this product.Go to the Kindle Store to download this guide in Kindle format.

Serving Compressed Files

Amazon CloudFront can serve both compressed and uncompressed files from an origin server. Serving compressed content makes downloads faster because the files are smaller—in some cases, less than half the size of the original. Especially for JavaScript and CSS files, faster downloads translates into faster rendering of web pages for your users. In addition, because the cost of CloudFront data transfer is based on the total amount of data served, serving compressed files is less expensive than serving uncompressed files.

CloudFront doesn't compress the files itself. Instead, it relies on receiving compressed files from your origin. The process for serving compressed files depends on whether you're using a custom origin or Amazon S3:

  • Custom origins – CloudFront relies on the origin server to respond to requests with compressed files. For more information, see How CloudFront Serves Compressed Content from a Custom Origin.

  • Amazon S3 origins – Amazon S3 doesn't compress files automatically, so you must create separate compressed and uncompressed versions of the files that you want to server in compressed format. In addition, you develop your web application to rewrite URLs when viewers request compressed content. For more information, see Serving Compressed Files from Amazon S3.

How CloudFront Serves Compressed Content from a Custom Origin

If you want to serve compressed content from a custom origin, you must configure your web server to compress your content using gzip; CloudFront doesn't support other compression algorithms. When a viewer requests a compressed file from CloudFront—when the request includes Accept-Encoding: gzip in the request header—CloudFront caches the file that is returned by your origin, regardless of whether the file is compressed. When a viewer requests the same file but without Accept-Encoding: gzip in the request header, CloudFront caches a separate version of the file, again regardless of whether the file is compressed.

The value of the Accept-Encoding request header must be gzip. If the request header includes additional values, for example, deflate or sdch, CloudFront removes them before forwarding the request to the origin server. If gzip is missing from the Accept-Encoding field, then the Accept-Encoding field in the request that CloudFront forwards to your origin is empty, and your origin returns an uncompressed version of the file. For more information about the Accept-Encoding request-header field, see "Section 14.3 Accept Encoding" in Hypertext Transfer Protocol -- HTTP/1.1 at http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html.

Here's how CloudFront commonly serves compressed content from a custom origin to a web application:

  1. You configure your web server to compress selected file types. For more information, see Choosing the File Types to Compress.

  2. You create a CloudFront distribution.

  3. You develop your website or web application to access your content by using CloudFront URLs.

  4. A viewer requests your content. The viewer adds the Accept-Encoding: gzip header to the request. This indicates that the viewer supports compressed content.

  5. CloudFront directs web requests to the edge location that has the lowest latency for the user.

  6. At the edge location, CloudFront checks the cache for the object referenced in each request.

  7. If the file is in the cache, CloudFront returns the file to the web browser. If the file is not in the cache:

    1. CloudFront forwards the request to the origin server.

    2. The web server compresses the file and adds a Content-Encoding: gzip header to the response. (The file name is the same, regardless of whether the content is compressed.)

    3. The web server returns the compressed file to CloudFront.

    4. CloudFront returns the file to the viewer and adds it to the cache. CloudFront caches separate versions based on whether the viewer request contains an Accept-Encoding: gzip header.

    5. The viewer uncompresses the content and displays it.

Serving Compressed Files from Amazon S3

Amazon S3 doesn't automatically compress files as web servers do. If you want to serve compressed content and you're using Amazon S3 as your origin, you need to store compressed and uncompressed versions of your files in your Amazon S3 bucket. You also need to develop your application to intercept viewer requests and change the request URL based on whether the request includes an Accept-Encoding: gzip header.

Here's how you use CloudFront to serve compressed content when you're using Amazon S3 as your origin:

  1. You create two versions of each file, one compressed and one uncompressed. To ensure that the compressed and uncompressed versions of a file don't overwrite one another in the CloudFront cache, give each file a unique name, for example, welcome.js and welcome.js.gz.

  2. You upload both versions to Amazon S3 and specify Content-Type and Content-Encoding headers:

    Content-Type

    If you're using the Amazon S3 API to upload files, include a Content-Type header to specify the MIME type of each file. The default MIME type is binary/octet-stream.

    If you're using the Amazon S3 console to upload files, Amazon S3 automatically figures out the content types of the files by default.

    Content-Encoding

    Add a Content-Encoding header field for each compressed file and set the field value to gzip.

    For an example of how to add a Content-Encoding header field by using the AWS SDK for PHP, see Upload an Object Using the AWS SDK for PHP in the Amazon Simple Storage Service Developer Guide. Some third-party tools are also able to add this field.

  3. You create a CloudFront distribution.

  4. You develop your application to evaluate whether a viewer request includes Accept-Encoding: gzip in the request header. If so, your application changes the object URLs to request the compressed version of the object.

  5. A viewer requests a file. The viewer adds the Accept-Encoding: gzip header to the request. This indicates that the viewer supports compressed content.

  6. Your application determines that Accept-Encoding: gzip appears in the request header and changes the CloudFront URL to request the compressed version of the file.

  7. CloudFront directs the request to the edge location that has the lowest latency for the user.

  8. At the edge location, CloudFront checks the cache for the file referenced in the request.

  9. If the file is in the cache, CloudFront returns the file to the web browser. If the file is not in the cache:

    1. CloudFront forwards the request to Amazon S3.

    2. Amazon S3 returns the compressed file to CloudFront.

    3. CloudFront adds the file to the cache and serves the file to the viewer.

    4. The viewer uncompresses the content and displays it.

Serving Compressed Files When Your Origin Server Is Running IIS

By default, IIS does not serve compressed content for requests that come through proxy servers such as CloudFront. If you're using IIS and if you configured IIS to compress content by using the httpCompressionelement, change the value of the noCompressionForProxies attribute to false so IIS will return compressed content to CloudFront.

In addition, if you have compressed objects that are requested less frequently than every few seconds, you might have to change the values of frequentHitThreshold and frequentHitTimePeriod.

For more information, refer to the IIS documentation on the Microsoft website.

Serving Compressed Files When Your Origin Server Is Running NGINX

When CloudFront forwards a request to the origin server, it includes a Via header. This causes NGINX to interpret the request as proxied and, by default, NGINX disables compression for proxied requests. If your version of NGINX includes the gzip_proxied setting, change the value to any so NGINX will return compressed content to CloudFront. For more information, see the NGINX documentation for the module ngx_http_gzip_module.

Choosing the File Types to Compress

Some file types compress well, for example, HTML, CSS, and JavaScript files. Some file types compress by a small percentage but not enough to justify the additional processor cycles required for your web server to compress the content. Some file types even get larger when they're compressed. File types that generally don't compress well include graphic files that are already compressed (.jpg, .gif), video formats, and audio formats. We recommend that you test compression for the file types in your distribution to ensure that there is sufficient benefit to compression.