也許嘗試HTML Compressor，這是一個前后表，顯示它可以做什么（包括Stack Overflow本身）：

對不起，markdown沒有表格的概念

它提供了許多選擇，可以優化您的頁面，包括腳本最小化（ompressor，Google Closure Compiler，您自己的壓縮器），它是安全的。默認選項設置非常保守，因此您可以從中開始并嘗試啟用更具侵略性的選項。

該項目記錄得非常好并得到了支持。

以下是對您的問題的簡短回答：您應該縮小HTML，CSS，JS。有一個易于使用的工具，稱為grunt。它允許您自動執行許多任務。其中JS，CSS，HTML縮小，文件連結和其他許多人。

這里寫的答案非常過時，甚至有時沒有意義。從2009年開始，很多事情發生了變化，所以我會盡力回答這個問題。

簡短的回答 - 你一定要縮小HTML。它今天微不足道，并提供大約5％的加速。對于更長的答案閱讀整個答案

在過去，人們手動縮小css / js（通過運行一些特定的工具來縮小它）。這個過程很難實現自動化，并且肯定需要一些技巧。知道現在很多高級站點都沒有使用gzip（這是微不足道的），人們不愿意縮小html是可以理解的。

那么為什么人們縮小js，而不是html？當你縮小JS時，你會做以下事情：

刪除評論

刪除空格（制表符，空格，換行符）

將長名稱改為短名稱（var isUserLoggedIn至var a）

即使在過去，這也給了很多改善。但是在html中，你無法簡短地改變長名，在那段時間里幾乎沒有什么可評論的。所以唯一剩下的就是刪除空格和換行符。這只會帶來少量改進。

這里寫的一個錯誤的論點是，因為內容是用gzip提供的，所以縮小是沒有意義的。這是完全錯誤的。是的，gzip減少縮小的改進是有意義的，但是如果你可以正確修剪它們并且gzip只是重要的部分，你為什么要gzip注釋，空格。這就像你有一個存檔文件夾，它有一些你永遠不會使用的垃圾，你決定只是拉鏈而不是清理和壓縮它。

另一個為什么毫無意義地進行縮小的論點是它很乏味。也許這在2009年是如此，但在此之后出現了新的工具?，F在您無需手動縮小標記。對于像Grunt這樣的東西，安裝grunt-contrib-htmlmin（依賴@kangax的HTMLMinifier）并配置它來縮小你的html 是微不足道的。你只需要2個小時來學習咕嚕聲和配置一切，然后一切都在不到一秒的時間內自動完成。聽起來1秒鐘（你甚至可以通過grunt-contrib-watch自動完成任務）對于大約5％的改進來說并不是那么糟糕（即使使用gzip）。

還有一個論點是CSS和JS是靜態的，HTML是由服務器生成的，所以你不能預先縮小它。這也是真正在2009年，但目前更多的和更多的網站都看起來像一個單頁的應用程序，其中，服務器是薄客戶端是做所有的路由，模板和其他邏輯。所以服務器只給你JSON，客戶端呈現它。這里有很多關于頁面和不同模板的html。

所以完成我的想法：

谷歌正在縮小HTML。

pageSpeed要求你縮小html

這是微不足道的

它提供了約5％的改善

它與gzip不同