Site Optimized for Chrome and Firefox
Site Optimized for Chrome and Firefox
Site Optimized for Chrome and Firefox
Site Optimized for Chrome and Firefox
The MMS API was deprecated on July 29, 2015. Get more information about our supported APIs.
x
/apis/sms-mms /apis/mms/docs
The Device Capabilities API was deprecated on July 29, 2015. Get more information about our supported APIs.
x
/apis/device-capabilities /apis/device-capabilities/docs
/site/website/application-resource-optimizer/docs/best-practices/text-file-compression/index.xml

Introduction

Compressing text files makes them smaller and faster to send, and unzipping files on a mobile device has low overhead. So, it is recommended that you compress text files while they are being sent over wireless networks.

This Best Practice Deep Dive gives you some background on the different methods for text file compression, looks at the issue of when it is most beneficial to use compressions, and provides a recommendation for using text file compression to make your app pages render faster.

Background

Compression is a technique that is used to reduce the number of bits needed to store or transmit data.

The text files that may be compressed include a variety of different file types, including HTML, JavaScript, CSS, .txt, and more. Text compression typically works by finding similar strings within a text file, and replacing those strings with a temporary binary representation to make the overall file size smaller.

Research has shown that compressing text files over 850 bytes improves downloading enough to overcome the overhead incurred in decompressing the files. When compressing text files under 850 bytes, however, the extra overhead is not worth the effort, so the Best Practice recommendation is to compress text files over 850 bytes.

HTTP 1.1 compression, which uses the gzip and DEFLATE algorithms, is widely supported. Web servers should be configured to serve appropriately compressed responses for this type of compression.

However, the cost (in time and battery usage) of decompressing data should be balanced against the gains in transport efficiency. When configuring HTTP 1.1 compression, consider the following.

  • Most image formats (especially JPEGs) do not benefit from compression, however SVG does.
  • Most other media formats (for example, audio and video) do not benefit from compression.
  • Very small files (for example, files less than 1k) generally do not benefit from compression.

For more information on W3C recommendations, see W3C Mobile Best Practice recommendation for transfer compression.

The Issue

A large percentage of mobile apps serve text files uncompressed, which affects the performance of the app.

In order to compress the files, compression needs to be supported, and there needs to be an agreement that it is alright to exchange compressed files. The agreement has the following parts:

  • The app sends an Accept-Encoding: gzip, deflate header that tells the server that it accepts compressed content. The Accept-encoding header is just a request, not a demand. If the server does support compressed content, the app will accept the uncompressed version of the text.
  • The server sends a Content-Encoding: gzip response if the content is actually compressed: If the server does not send the content-encoding response header, it means that the file will not be compressed when it is sent. This is the default on many servers.

The most common compression schemas are 'gzip' and 'deflate'. Major mobile platforms provide support for gzip and deflate, but implementation will differ.

Best Practice Recommendation

Compressing large files will speed up download times, thus making the page render faster. The Best Practice Recommendation is to compress text files whenever possible.

You can use AT&T ARO to make sure that your app compresses a significant number of text files. AT&T ARO runs automated tests for uncompressed text files. If over 5% of the text files that your app sends are not compressed, the app fails this test.