前言

身為一位前端工程師或多或少都有聽過 Webpack 這套前端打包工具吧，為了讓最終打包的檔案不會過于龐大，Webpack 可是下了非常多的苦功，例如：利用 Code Splitting 產出一個又一個的 chunk 讓網頁不會一次載入一份很大 JS包。

然而今天的文章其實不是要講 Code Splitting，而是要講一個比較深入的原理：Tree Shaking。

什么是 Tree Shaking？

什么是 Tree Shaking？Tree Shaking 就字面上翻譯來看就是搖晃樹木，在 Webpack 的世界中我們通常都會設定一個 Entry Points 來告訴 webpack 要從哪個文件開始往其他文件進行打包，如果用 Tree 的概念來看就是一個主干配上很多的樹枝。

Dynamic Language & Static Language

接下來講個跟 Tree Shaking 比較無關的小知識，但這個小觀念可以幫助我們了解為何要在 JavaScript 上執行 Tree Shaking 并不是我們想像中的那麼容易。

接下來講個跟 Tree Shaking 比較無關的小知識，但這個小觀念可以幫助我們了解為何要在 JavaScript 上執行 Tree Shaking 并在程式語言中有分為 動態語言(Dynamic Language) 以及 靜態語言(Static Language)，被歸類在 Dynamic Language 中比較常見的有 JavaScript、PHP、Python 等語不是我們想像中的那么容易。

在編程語言中有分為 動態語言(Dynamic Language) 以及 **靜態語言(Static Language)**，被歸類在 Dynamic Language 中比較常見的有 JavaScript、PHP、Python 等語言，至于被歸類在 Static Language 比較常見的有 C++、Java 等語言。

在 Dynamic Language 中由于我們可以動態的載入非常多東西，例如 function、object 等，對于 Tree Shaking 來說這種會動態載入的東西實在是太難捉摸了，這也讓 Dynamic Language 的 Tree Shaking 很難達到最完美。

Dead Code Elimination

在開始講 Tree Shaking 原理之前必須要了解一個技術：死碼刪除(Dea誒 Code Elimination)。

在 ??compiler?? 的領域中，為了達到執行時間的優化，在代碼編譯的過程中 compiler 會將對于最終結果沒有影響到的代碼刪除，進而達到執行時間的優化，這段過程稱之為 Dead Code Elimination。

乍看之下 Dead Code Elimination 在做的事情好像就是 Tree Shaking 要做到的事情，就是要刪除無用的代碼，但兩者其實還是有著些微的差距，接下來就要講講 Tree Shaking 的原理。

Tree Shaking 原理

Tree Shaking 其實是 Dead Code Elimination 的一種新的實現原理，在上面的 Dynamic Language 的觀念中提到 Dynamic Language 的特性就是可以動態載入任何東西，因為這個特性讓 Dead Code Elimination 相當難實現，因為 complier 永遠不知道到底哪些程代碼是對最終結果不會有影響的。

所以 Tree Shaking 其實要做到的不會像 Dead Code Elimination 那樣死板板的要刪除對結果不會有影響的程式碼，而是要保留會需要用到的代碼，這樣也可以達到類似 Dead Code Elimination 的效果，只是兩者的原理還是有一些差異，而這就是 Tree Shaking 的原理。

ES6 module v.s commonJS

上面提到 Tree Shaking 的原理最主要的目的就是要保留會需要用到的代碼，而這點在早期的 JavaScript 其實是無法實現的，但是在 ES6 誕生后有一個非常重要的概念叫：ES6 modules。

由于 ES6 modules 的誕生，我們可以在每個文件的最上方先引用即將會需要用到的東西，所以這些 bunbler 就可以藉由這些?? import file?? 很快速的知道可以保留哪些文件，進而達到 Tree Shaking 的效果。

這時候讀者可能會有另一個問題了，在 ES6 module 還沒誕生以前我們也可以利用 commonJS 來進行 module 的導入，為什麼 ES6 module 可以做到 Tree Shaking 可是 commonJS 無法呢？

其實是因為 ES6 module 有著非常多的特性，讓 bundler 可以針對這些特性來進行靜態的分析：

• module 必須要在頂層被 import。
• module 內部會自動被定義為 strict mode。
• module name 不能動態改變。
• module 內容為 immutable 無法在其他文件中被動態新增或刪除內容。

因為這些強限制在，所以 ES6 module 就可以讓 bundler 做到 Tree Shaking 的效果，而 commonJS 則無法達到此點。

改善 import 與 export 方式

我們都知道 ES6 modules 的 export 方式有分 ??named export??? 以及?? default export??，這兩種方法適用于不同的使用場景，也會對 Tree Shaking 后的文件內容有著非常大的差別。

default export

named export

乍看之下 ??default export??? 跟?? named export?? 在寫法上好像沒什麼太大的差別(除了直接在項目前面加上 export 的寫法比較不一樣外)，最終都是需要用一個物件來包裝輸出，但兩者在 Tree Shaking 后的結果可是有著蠻大的差別，接下來就看來一下 Tree Shaking 過后的結果吧！

default export 經由 Tree Shaking 后的結果：

named export 經由 Tree Shaking 后的結果：

可以看到上面兩張圖，雖然 Tree Shaking 都有把 multiply 這個 function 移除了，可是 ??default export??? 相較于 ??named export??? 還是新增了不少變量來處理 ??function parameter??，這樣就不是一個完美的性能優化。

所以假如讀者在開發時確定一個文件會需要同時輸出很多項目，不管是對象也好函數也罷，這時候都建議用 ??named export?? 的方式進行輸出這樣才能達到最好的性能優化。

改善第三方組件的 import 方式

最后再來看一下 import 第三方組件的最佳方式，在前端開發的過程中為了不要重復照輪子很多時候都會使用大神所開發好的第三方組件來加速開發，但第三方組件的 ??import?? 方式其實也會影響到最終的 bundle size。

接下將以 ant design 這套 UI library 來進行說明。

首先是利用官方文檔的說明來進行 import，其實 antd 本身就有針對其 module 進行 Tree Shaking 的性能優化，所以我們原則上是可以放心的使用官方文檔的教學進行 ??import??? 的，接下來我們利用 ??webpack-bundle-analyzer?? 來進行檔案分析。

可以發現 antd 的文件大小高達 ??842.15KB???，而且裡面還跑出了許多跟 Button 無關的 component 文件，這顯然是一個不好的 ??import??? 方式，沒想到照著官文檔的方式進行 ??import?? 也沒辦法達到最好的性能優化。

但這其實也不是 antd 的錯， antd 本身就有做好 Tree Shaking 的動作，詳細的說明可以參考 antd 的官方文件，但是這邊的事例故意沒有在項目的 bundler 設定檔中開啟 Tree Shaking 的功能，進而導致 antd 的 Tree Shaking 失效。

雖然 bundler 沒有開啟 Tree Shaking 功能讓整體的 bundle size 過大，但我們其實也可以自己手動做這件事，這時候只要我們改成從 antd 的 es folder 進行元件的單獨 ??import?? 就可以讓最終的 bundle size 差非常多，寫法如下。

接著我們一樣使用 webpack-bundle-analyzer 來進行項目分析。

可以發現整個 antd 的文件大小少了非常多，只剩下 ??74.8KB??? 而且與 Button 無關的其他 component 都沒出現了，所以同一種第三方組件不同的 import 方式真的會讓整體的性能差距非常大，這個就是比較好的第三方組件 ??import?? 方式。

package.json 中的 sideEffects

在 Webpack 的 Tree Shaking 配置中，有一個可以在 ??package.json??? 中配置的叫 ??sideEffects???，這個 ??sideEffects?? 的配置主要是讓 Webpack 這種 bundler 知道此項目是否可以做 Tree Shaking 的動作。

假如設定為 ??false??? 就代表可以將所有的文件進行 Tree Shaking，若讀者知道有哪些檔案是不能做 Tree Shaking 的，這時候只要在 ??sideEffects?? 內用一個數組將不能做 Tree Shaking 的文件路徑寫上去，這時候 bundler 就只會針對這個數組以外的文件進行 Tree Shaking。

Webpack 中的 usedExports

在 Webpack 的官方文件中要達到 Tree Shaking 的效果除了在 ??package.json??? 中加上 ??sideEffects??? 外，還可以使用 ??usedExports??。

在官方文件中有這麼一段說明：

如果說 sideEffects 在做的事情是把不能做 Tree Shaking 的樹枝移除，那 ??usedExports?? 在做的事情就是把樹枝上沒有用到的樹葉移除，所以 usedExports 其實才是在做真正的 Tree Shaking。

useExports 利用 terser 這套工具進行項目的 side effects 偵測，假如打包過程中發現此弎既沒有 side effects 且某些代碼又沒有被引用到，則該代碼就會在之后的 ??uglify?? 被移除，藉此達到真正的 Tree Shaking 效果。

而 usedExports 的設定方式也非常簡單，只要在 Webpack 的配置文件中，在 ??optimization??? 內加上?? usedExports: true?? 這時候就可以將 usedExports 的功能打開，寫法如下：

小結

今天介紹了 Tree Shaking 的相關基本觀念，雖然說身為一位前端工程師不一定要懂這個概念，畢竟現在很多主流的框架都已經先把 bundler 的相關 ??config?? 都寫好了，但了解這些工具背后在做的事情也能幫助到自己在開發時可以稍微省思一下要如何改良自己的代碼，進而提升整體的打包后的性能。

像是上面提到的 import 與 export 方式，引用第三方組件時可以如何引用達到最小的 bundle
size，有了這些概念在開發時就可以提升整體的性能 ，所以筆者也建議目前正在學習網頁開發的讀者都可以稍微了解一下 Tree Shaking 的概念喔。