The term tree shaking comes from the JavaScript world and is a form of what is otherwise referred to as dead code elimination: tree shaking allows to reduce the amount of JavaScript code to what is really needed. The term was introduced by Rollup.
The idea behind tree shaking is to imagine the various dependencies of code as a tree. On the one hand, this tree becomes bigger, more complex, and more branched over time, because more and more dependencies are added in the form of additional packages. On the other hand, older dependencies are gradually no longer integrated or used. The packages are still there but no longer “tied.”
When you “shake” this tree, everything that is not firmly attached to the trunk or branches falls to the ground – the packages that are no longer firmly tied and therefore no longer needed fall off.
In addition to minimizing and compressing JavaScript code, tree shaking is probably the most important tool for speeding up the load time of a web app – not least because it directly influences the quantity of code.
Let’s compare 170 KB of JavaScript code (compressed) with the same number of bytes for a JPEG image, as measured on a 3- to 4-year-old smartphone with a 3G connection.
In both cases, the browser needs the same amount of time for downloading, because it is the same amount of data.
But when you look at the time the browser needs for further processing of the data in each case, then it becomes clear how cost-intensive JavaScript code is. To display the image, the browser needs about 0.1 s. In contrast, the JavaScript code is first unpacked to about 500 KB of code. This code then needs about 3.5 s to parse/compile and execute: 35 times as much time!
The mechanism behind tree shaking relies on static code analysis enabled by EMS notation (<span class="hljs-keyword">import</span>/<span class="hljs-keyword">export</span>):
webpack marks these code locations on this basis so that they can be removed by tools like UglifyJS.
However, it is necessary that the source, in this case “bar.js,” is written in EMS format. In CommonJS notation, it is not possible for applications such as webpack or Rollup to perform a static code analysis on the basis of this format. Usually you don’t have any problems with files you yourself have created if in them, you use the EMS format.
The <span class="hljs-keyword">import</span> statement does not allow you to recognize whether the source is written in EMS format. This requires that you take a look at the package.json file of the dependency.
As you know, the dependency is resolved with the file that is below the “main” field, but bundlers like webpack or Rollup are looking for the “module” field to find an EMS version of the dependency.
Common dependencies in which the code is not in EMS format include:
La página de done vienes no existe en la región o el idioma seleccionados.
Visita la Página Principal de su región o traduzca esta página utilizando las funciones del navegador.
Diese Seite existiert in der gewählten Region oder Sprache nicht.
Besuchen Sie die Startseite Ihrer Region oder übersetzen Sie diese Seite mithilfe der Browser-Funktionen.
