在什么階段你壓縮/最小化JavaScript？

Question

在用戶請求頁面時構建或“動態”（可能具有緩存）。

每個人的優勢/優勢是什么？

Answer 1

當站點從dev移動到實時服務器時。

我總是在開發服務器上有一個未壓縮的JS版本，在實時服務器上有一個最小化版本。

這樣做的好處是在開發時我可以遇到JS問題並且非常簡單地修復它，但是我需要通過最小化器來運行每個更改的腳本，但對我來說並不是那么多。

Answer 2

構建或部署到舞台環境時是壓縮javascript的好時機。 這樣您就有機會在舞台環境中測試它並捕獲可能發生的任何錯誤。

有時，壓縮時會出現錯誤。 您可能希望包含在壓縮之前運行的命令行版本的jslint，以確保js通過。 這將最小化但不能消除所有壓縮錯誤。

Answer 3

我想，除非你在JavaScript中添加動態數據，否則即時運行將是不必要的（在這種情況下，有更好的方法）。 這只是一筆不必要的開支，只會減慢頁面加載速度。

就個人而言，我在部署/構建應用程序時會這樣做，這實際上是一次性的事情。

Answer 4

我說你有源代碼控制中的js文件，當你開始自動構建時，作為構建腳本的一部分，它通過壓縮器運行所有的javascript文件。 這樣，當您將其部署到測試/暫存環境時，您就擁有了最新的腳本，但也進行了壓縮以進行性能測試，就像他們進入生產階段一樣。

Answer 5

我同意如果JS沒有改變，那么即時可能並不是真正必要的（並且會占用一些cpu周期）。

可能會涉及一些中間件，可以檢查JS是否已經更改並僅在請求時壓縮它（甚至可能將各種JS文件組合成一個結果）。

部署時的好處還可能是在JS鏈接中添加一些時間戳或隨機字符串作為參數（例如.../scripts.js?t=cdkjnsccsds7sc8cshcsjhbcs ）。 這樣，當JS更改時，您使用不同的字符串，並且不會出現緩存問題，因為它是一個新的URL。 CSS也一樣。