程式碼壓縮:它做什麼以及何時值得努力

你的 JavaScript 檔案是 500KB。壓縮後,它是 150KB。檔案的 70% 發生了什麼?

主要是空白、註解和長變數名稱。人類需要但瀏覽器不需要的東西。

壓縮移除什麼

空白。 縮排、空行、額外的空格。瀏覽器不需要它們。

註解。 對開發者有用,對瀏覽器不可見。消失了。

長名稱。 calculateTotalPrice 變成 a。customerData 變成 b。相同的邏輯,更少的字符。

死碼。 有些壓縮器移除從未執行的程式碼。

實際節省

對於 JavaScript:

• 空白和註解:30-50% 的大小減少
• 變數重命名:另外 10-30%
• 死碼移除:變化很大

對於 CSS:

• 主要是空白和註解
• 更短的選擇器有幫助但有風險(它們可能匹配其他元素)

對於 HTML:

• 較不顯著的收益
• 通常只是空白移除

何時壓縮

生產網站。 總是。更快的載入時間,更好的使用者體驗,更低的頻寬成本。

API 回應。 有時。JSON 壓縮節省頻寬但使除錯更困難。

內部工具。 也許。開發速度可能比載入時間更重要。

何時不壓縮

開發環境。 除錯壓縮的程式碼很痛苦。保留原始碼映射或在開發期間不壓縮。

可讀性要求。 有些開源專案為了教育目的保留可讀程式碼。

微小檔案。 壓縮 1KB 檔案幾乎沒有節省,並增加了建置複雜性。

超越壓縮

Gzip/Brotli 壓縮。 壓縮的程式碼進一步壓縮。大多數伺服器自動處理這個。

程式碼分割。 只載入每個頁面需要的程式碼。比一個巨大的壓縮包更好。

Tree shaking。 打包器移除未使用的匯出。只匯入你需要的。

這些技術結合使用。壓縮,然後壓縮,然後智慧地分割。

Source Map

壓縮的程式碼無法閱讀。a.b(c,d) 在除錯時什麼都不告訴你。

Source map 將壓縮的程式碼連接回原始原始碼。你的瀏覽器開發工具在執行壓縮程式碼時顯示可讀程式碼。

在開發中保留 source map。根據你是否希望使用者看到你的原始碼來決定是否將它們部署到生產環境。

常見問題

損壞的變數名稱。 壓縮器有時會破壞需要保持完整的名稱(如字串中的 API 金鑰)。配置排除。

順序相依的 CSS。 積極的 CSS 壓縮可能會重新排序規則並改變樣式如何層疊。

非同步問題。 積極的死碼移除可能會破壞動態載入的程式碼。

在部署前測試壓縮的建置。未壓縮時有效的東西在處理後可能會損壞。

---

壓縮是廉價的效能。建置工具自動處理它。設定一次,永遠享受更小的檔案。