我有一個使用快速構建的nodejs站點，我們正在嘗試優化。我們有一個帶{{{body}}}標記的layout.html文件和其他幾個html文件，它們在運行時通過快速渲染引擎合併到layout.html中。Node.js - 將HTML文件作爲構建後步驟還是在運行時更好？
我們希望再縮小HTML文件作爲構建後操作，但失敗是因爲我們在的layout.html無效的標記（標記是後有效{{{體}}}已被取代） 。
開發人員A：想解決這個標記，所以我們可以再壓縮生成後，部分原因是因爲它使得在未來的佈局文件的工作更容易，部分是因爲他們相信我們會得到更多的如果我們避免網絡服務器CPU在運行時進行縮小的懲罰，性能上的好處。
開發者B：我們應該在運行時縮小版本而不是修正標記，並且我們不會因此而遭受懲罰。他們還認爲，構建後構建會在運行時帶來快速渲染引擎的問題。
我不知道技術水平足以知道誰是對的，並歡迎來自該領域專家的答案。
用令牌來完成縮小，並不難。
我的意見是兩個開發商都錯了，是不是一個好主意來縮小HTML。
我打算參考this的帖子，@Adrian Salazar的回答。
縮小HTML的唯一好處是可以去除空白，所以不推薦使用，如果您使用的是模板，可能會發現問題（正如我所看到的那樣）。
我的建議是忘記縮小HTML，只關注CSS和JS縮小。如Adrian所說，如果您擔心HTML的長度，您可以啓用gzip壓縮您的Web服務器中的靜態文件。
所以，開發人員A是有原因的，他說，縮小在生成後，最好在未來與文件的工作，但他對錶演的第二個原因可以用gzip壓縮所要解決Web服務器。
開發人員B在我看來是錯誤的，express會提供一個靜態文件，所以不會有任何問題，並且最好的做法是在構建中縮小文件（您必須提供所有代碼對您的部署區域很好）。
總結：所以，我與開發人員A可言，我不同意的性能問題（我說），但他的意見是「的方式開發」，努力工作在開發者時間儘可能最好。
雖然我很欣賞有關HTML縮小的優點的爭論，但這個問題並不是這樣。我想要一個具有nodejs經驗的人來表達並解釋哪種方式更好，爲什麼。我知道你在幫助，但你還沒有回答原來的問題。 – gilles27
實際上，你甚至沒有真正看到縮小的廢話，它只是爲客戶端瀏覽器... – azurinko
Minify的HTML是真的不必要的，例如，如果在你的代碼中你正在管理HTML標籤，並且使用'id'作爲選擇器，你想縮小這個ID嗎？沒有意義，只有性能問題，gzip就足夠了 – Kalamarico
謝謝，但我希望對兩種方法的批評而不是第三種方法。 – gilles27