compression

What this skill does

# Compressing JavaScript

## Table of Contents

- [When to Use](#when-to-use)
- [Instructions](#instructions)
- [Details](#details)
- [Source](#source)

JavaScript is the second biggest [contributor to page size](https://almanac.httparchive.org/en/2020/page-weight#fig-2) and the second most [requested web resource](https://almanac.httparchive.org/en/2020/page-weight#fig-4) on the internet after images. We use patterns that reduce the transfer, load, and execution time for JavaScript to improve website performance. Compression can help reduce the time needed to transfer scripts over the network.

## When to Use

- Use this when you need to reduce JavaScript payload sizes for faster page loads
- This is helpful when optimizing network transfer times, especially for users on slower connections
- Use this alongside minification, code-splitting, and caching strategies

## Instructions

- Prefer Brotli compression over Gzip for better compression ratios at similar speed
- Use static compression for assets that don't change frequently and dynamic compression for frequently changing content
- Enable compression at the server or CDN level (e.g., Nginx, Vercel, Netlify)
- Minify JavaScript before applying compression
- Be mindful of the granularity trade-off: larger bundles compress better, but smaller chunks cache better

## Details

You can combine compression with other techniques such as minification, code-splitting, bundling, caching, and lazy-loading to reduce the performance impact of large amounts of JavaScript. However, the goals of these techniques can sometimes be at odds with each other. This section explores JavaScript compression techniques and discusses the nuances you should consider when deciding on a code-splitting and compression strategy.

- **Gzip** and **Brotli** are the most common ways to compress JavaScript and are widely supported by modern browsers.
- **Brotli** offers a **better compression ratio** at similar compression levels.
- **Next.js** provides [Gzip compression by default](https://nextjs.org/docs/api-reference/next.config.js/compression) but recommends enabling it on an HTTP proxy like Nginx.
- If you use **Webpack** to bundle your code, you can use the **[CompressionPlugin](https://github.com/webpack-contrib/compression-webpack-plugin)** for Gzip compression or the [BrotliWebpackPlugin](https://github.com/mynameiswhm/brotli-webpack-plugin) for Brotli compression.
- Oyo saw a **15-20% reduction**, and Wix saw a **21-25% reduction** in file sizes after switching to **Brotli compression instead of Gzip**.
- **compress(a + b) <= compress(a) + compress(b)** - A single large bundle will give better compression than multiple smaller ones. This causes the granularity trade-off where de-duplication and caching are at odds with browser performance and compression. Granular chunking can help deal with this trade-off.

### HTTP compression

Compression reduces the size of documents and files, so they take up less disk space than the originals. Smaller documents consume lower bandwidth and can be transferred over a network quickly. HTTP compression uses this simple concept to compress website content, reduce [page weights](https://almanac.httparchive.org/en/2020/page-weight), lower bandwidth requirement, and improve performance.

HTTP data compression may be categorized in different ways. One of them is lossy vs. lossless.

**Lossy compression** implies that the compression-decompression cycle results in a slightly altered document while retaining its usability. The change is mostly imperceptible to the end-user. The most common example of lossy compression is JPEG compression for images.

With **Lossless compression,** the data recovered after compression and subsequent decompression will match precisely with the original. PNG images are an example of lossless compression. Lossless compression is relevant to text transfers and should be applied to text-based formats such as HTML, CSS, and JavaScript.

Since you want all valid JS code on the browser, you should use lossless compression algorithms for JavaScript code. Before we compress the JS, minification helps eliminate the unnecessary syntax and reduce it to only the code required for execution.

### Minification

To reduce payload sizes, you can minify JavaScript before compression. [Minification](https://web.dev/reduce-network-payloads-using-text-compression/#minification) complements compression by removing whitespace and any unnecessary code to create a smaller but perfectly valid code file. When writing code, we use line breaks, indentation, spaces, well-named variables, and comments to improve code readability and maintainability. However, these elements contribute to the overall JavaScript size and are not necessary for execution on the browser. Minification reduces the JavaScript code to the minimum required for successful execution.

Minification is a standard practice for JS and CSS optimization. It's common for JavaScript library developers to provide minified versions of their files for production deployments, usually denoted with a min.js name extension. (e.g., `jquery.js` and `jquery.min.js`)

Multiple tools are available for [the minification of HTML, CSS, and JS](https://developers.google.com/speed/docs/insights/MinifyResources) resources. [Terser](https://github.com/terser-js/terser) is a popular JavaScript compression tool for ES6+, and [Webpack](https://webpack.js.org/) v4 includes a plugin for this library by default to create minified build files. You can also use the `TerserWebpackPlugin` with older versions of Webpack or use Terser as a CLI tool without a module bundler.

### Static vs. dynamic compression

Minification helps to reduce file sizes significantly, but compression of JS can provide more significant gains. You can implement server-side compression in two ways.

**Static Compression:** You can use static compression to pre-compress resources and save them ahead of time as part of the build process. You can afford to use higher compression levels, in this case, to improve the download time for code. The high build-time will not affect the website performance. It would be best if you used static compression for files that do not change very often.

**Dynamic Compression:** With this process, compression takes place on the fly when the browser requests resources. Dynamic compression is easier to implement, but you are restricted to using lower compression levels. Higher compression levels would require more time, and you would lose the advantage gained from the smaller content sizes. It would help if you used dynamic compression with content that changes frequently or is application-generated.

You can use static or dynamic compression depending on the type of application content. You can enable both static and dynamic compression using popular compression algorithms, but the recommended compression levels are different in each case.

### Compression algorithms

[Gzip](https://datatracker.ietf.org/doc/html/rfc1952) and [Brotli](https://opensource.googleblog.com/2015/09/introducing-brotli-new-compression.html) are the two [most common algorithms](https://almanac.httparchive.org/en/2020/compression#fig-5) used for compressing HTTP data today.

#### Gzip

The Gzip compression format has been around for almost 30 years and is a lossless algorithm based on the [Deflate algorithm](https://www.youtube.com/watch?v=whGwm0Lky2s&t=851s). The deflate algorithm itself uses a combination of the [LZ77 algorithm](https://cs.stanford.edu/people/eroberts/courses/soco/projects/data-compression/lossless/lz77/algorithm.htm) and [Huffman coding](https://cs.stanford.edu/people/eroberts/courses/soco/projects/data-compression/lossless/huffman/algorithm.htm) on blocks of data in an input data stream.

The LZ77 algorithm identifies duplicate strings and replaces them with a backreference, which is a pointer to the place where it previously appeared, followed by the length of t