# 討論: Webpack Chunks 實際效率分析
###### tags: `Webpack` `Web Technology` `Performance Analysis` `Profiling` `Tracing` `App` `Optimization`

:::warning
:question: **最佳化問題**: 用 lazy loading 做 code splitting 將原本 1.47MB (chunk 757) 的包拆成 761kB (chunk 187)、650kB (chunk 34)，下載時間反而增加。
:::

:::info
:mag_right: 見下圖，比較兩種打包模式，可以發現若將最大包的 Three.js 模組拆成兩份並行下載時，不僅沒有顯著縮短下載時間，還因為以下原因造成更長的等待時間:
- 需下載的封包數量變多在頻寬窄的情形會互相卡頻寬，並行效果有和沒有一樣。
- 用 lazy loading 並行下載資源可能導致跟其他不重要的資源一起搶頻寬 (如下狀況: 並行下載 chunk 被 proj-m 圖片分頻寬 (參最下圖))，不如專心等必要的大包模組載入後再並行下載其他資源。
- 如果 server 受中間 router、CDN server 影響回應時間拉長，累計的等待下載資源時間就會變得相當可觀。

#### 1. 正常 import (所有 Three.js 的程式碼都一起打包)
18 秒左右當 757 包下載完後得到第一次畫面渲染

Webpack bundles analysis:

Networking result:

#### 2. 模組 Stars、Earth 做 Lazy loading (將最大包的 Three.js 第三方模組拆分)
24 秒左右當 187 (three.module.js) 包下載完後得到第一次畫面渲染

Webpack bundles analysis:

Networking result:

:::