我們是否應當bundle source code?

3ldk

webpack這類tool的出現, 就係想減少http request來加速

webpack自己劈頭就講:
this solution is hard to scale because loading too many scripts can cause a network bottleneck

但偏偏有人又要整個mini-css-extract-plugin出黎, 想增加http request來加速
理由竟然係bundle會變慢, 將css分開獨立http request, 咁就可以同時下載js和css, 從而變快

既然係咁, 一開始就咪bundle, 所有js同css拆開有咁細得咁細, 幾十個js 幾十個css 同時download咪仲快過只拆一個js同一個css?

以上兩套理論係咪好矛盾? 究竟應唔應該bundle?

justlazy

以前 network bottleneck 在於每個 request 要 establish 一個 TCP connection，個 overhead 好大。自從有咗 HTTP2，multiple requests to the same host 只需要 establish 一個 connection，呢個問題已經唔存在。

分開 JS 同 CSS 嘅好處係個 client 可以淨係 load 咗 CSS 先，之後到 HTML，最後先等理論上較 bulky 嘅 JS bundle load 起。寫得好嘅 web app 用呢種方法比 user 嘅感覺係最舒服。所以 CSS 同 JS 一般應該分開。

3ldk

所以就係話, 係咪唔好bundle? 排除css唔考慮, 淨係諗js, 在http2情況下, 10個細js一齊download, 係咪會快過download一個大js?
既然係咁, 不如唔好bundle

hihihi123hk

webpack這類tool的出現, 就係想減少http request來加速

webpack自己劈頭就講:
this solution is hard to s ...
3ldk 發表於 2020-1-24 10:48

但偏偏有人又要整個mini-css-extract-plugin出黎, 想增加http request來加速
理由竟然係bundle會變慢, 將css分開獨立http request, 咁就可以同時下載js和css, 從而變快

人地係個用法唔係你想像中咁樣，主要用途係將Optional Dependency 嘅 JS/CSS 拆出黎用 Html Async load (即係冇完成一個 Page Load 唔爛畫面嘅情況），Async 意思即係可以允許 Browser 係未 Load 到個 Js/Css 就可以繼續向下 Render

呢類 JS/Css 基本上在 SSR 情況下都冇需要用，亦可以 Render 完整版面

另外，就係 大 Bundle 與 多個碎 File，Bundle file size 較大行 gzip 會比較有效率

（因為每個 gzip 咗嘅 result 都會放不同 Hash Table 入去）

要是你不信

試下用一個普通OS，你有一個大 Zip 裝住 N 樣野 vs N個細 Zip；N 個細 Zip 加埋一定大過一個大Zip

via HKEPC IR Extreme 4.2.3 - iOS(4.0.2)

trade4epc

我覺得反正一定用 async, 減少 http requests 點都好 d, 所以應該 bundle.