HTML・CSS・JavaScriptをすべて1つのHTMLファイルにまとめた、いわゆる「單一 HTML」的網站，有時候會需要製作。
單一 HTML 很方便。
- 因為只有一個檔案，所以容易散布
- 只要放到 GitHub Pages 等服務上就能運作
- 不需要擔心 CSS 或 JavaScript 的載入路徑
- 也容易離線儲存
另一方面，如果把所有 CSS 和 JavaScript 都直接寫進 HTML 裡，檔案大小就會愈來愈大。
這次我試著把這個單一 HTML 做成「自我解壓縮格式」，看看實際使用感受會有什麼變化。
這次測試的內容
這次拿來作為壓縮對象的網站如下。
壓縮前的網站如下。
程式碼內容如下。
壓縮後的網站如下。
程式碼內容如下。
結果
檔案大小如下。
狀態大小壓縮前214KB壓縮後48KB從 214KB 變成 48KB，明顯變小了。
單純計算的話，大約縮到了 22% 左右的大小。
不過，實際用瀏覽器打開時的體感速度幾乎沒有差異。
什麼是自我解壓縮格式
這裡所說的自我解壓縮格式，簡單來說就是以下這種結構：
- 先把原本的整個 HTML 壓縮
- 將壓縮後的資料嵌入另一個 HTML 裡
- 在瀏覽器打開時，用 JavaScript 進行解壓
- 顯示解壓後的 HTML
也就是說，HTML 檔本身仍然只有一個。
只是內容不再是直接寫原本的 HTML，而是改成持有壓縮資料，以及用來還原它的 JavaScript。
概念上大概像這樣：
<html>
<head>
<meta charset="UTF-8">
<title>自我解壓縮 HTML</title>
</head>
<body>
<script>
// 讀取壓縮後的資料
// 用 JavaScript 解壓
// 以原本的 HTML 形式顯示
</script>
</body>
</html>實際上因為還會包含壓縮資料與解壓處理，所以會再複雜一些。
實際使用感想
最大的感想是：
檔案大小確實小很多，但開啟所需時間幾乎沒有變化
這次的案例中，壓縮前是 214KB，壓縮後是 48KB。
只看數字的話，效果相當明顯。
不過，實際在瀏覽器中打開時的使用感幾乎相同。
我認為原因在於，原本的 HTML 只有 214KB 左右，對現代瀏覽器與網路環境來說，本來就不算很大的檔案。
另外，自我解壓縮格式還會多出以下處理：
- 讀取壓縮後的資料
- 透過 JavaScript 解壓
- 套用解壓後的 HTML
因此，雖然傳輸量變少了，但解壓處理會多一些。
以這次的大小來看，那個差異還不到能明顯體感出來的程度。
與單一 HTML 的相容性
我覺得自我解壓縮格式和單一 HTML 的相容性相當好。
特別是當 HTML 內直接寫了 CSS 和 JavaScript 時，壓縮效果會很好。
HTML、CSS、JavaScript 都是文字，因此會反覆出現許多相似字串。
例如：
- class 名稱
- 函式名稱
- CSS 屬性
- 縮排
- HTML 標籤
- JavaScript 語法
這些都具有很高的重複性，因此很好壓縮。
所以，當單一 HTML 變得很大時，改成自我解壓縮格式可以縮得相當小。
如果有嵌入圖片，效果會比較小
另一方面，如果 HTML 內有用 Base64 等方式嵌入圖片，壓縮效果就會變小。
特別是 PNG、JPEG 這類圖片，本身就已經是壓縮過的格式。
因此，即使把它們嵌進 HTML 再壓縮，也不會縮很多。
像這次這樣以 HTML、CSS、JavaScript 為主的單一 HTML，效果會比較大。
但如果是圖片資料佔大部分的 HTML，即使改成自我解壓縮格式，變化也會非常小。
也就是說，自我解壓縮格式特別適合以下情況：
- HTML 很大
- CSS 直接寫在 HTML 內
- JavaScript 直接寫在 HTML 內
- 文字量很多
- 嵌入圖片很少
反過來說，以下情況就比較不容易看出效果：
- Base64 圖片很多
- 已經有很多壓縮過的資料
- 原本的 HTML 就很小
優點
改成自我解壓縮格式的優點，果然還是能把檔案大小變小。
尤其是如果像 GitHub Pages 這類服務上公開的是單一 HTML，能在維持單一檔案的前提下做到輕量化，就很方便。
因為不需要拆成外部檔案，所以也能保留單一 HTML 的優點。
優點整理如下：
- 仍然可以用單一 HTML 的方式散布
- 可以縮小檔案大小
- 如果是以 HTML/CSS/JavaScript 為主，壓縮效果很好
- 可以直接放到 GitHub Pages 等服務上
- 不需要管理外部檔案
缺點
另一方面，也有缺點。
最大的問題是，內容會變得不容易直接閱讀。
如果是壓縮前的 HTML，用瀏覽器的「檢視頁面原始碼」或文字編輯器打開，就能直接確認內容。
但改成自我解壓縮格式後，內容會變成壓縮資料。
因此，即使看原始碼，也無法立刻看出原本的 HTML 結構。
另外，由於初次顯示時需要用 JavaScript 解壓，所以在 JavaScript 被停用的環境下就無法顯示。
缺點整理如下：
- 原始碼變得不易閱讀
- 不容易除錯
- 需要 JavaScript
- 會增加解壓處理
- 不太適合 SEO 用途
- 可能會讓人對安全性有所疑慮
特別是如果是像 Qiita 文章或教材這種希望讀者能閱讀原始碼的用途，我認為還是另外保留一份壓縮前的 HTML 比較好。
實際使用感受
實際用起來，在正常作為網站打開時，幾乎沒有違和感。
即使打開壓縮後的頁面，外觀和操作感也幾乎和壓縮前一樣。
這次的例子中，打開所需時間也幾乎沒有差別。
所以從使用者角度來看，
幾乎可以當作一般 HTML 頁面使用
會是這樣的感覺。
不過，從開發者角度來看，壓縮後的 HTML 就不太好編輯了。
因此，營運方式上感覺可以採用下面這種做法：
- 開發時使用壓縮前的 HTML
- 發佈時產生自我解壓縮 HTML
- 同時管理壓縮前與壓縮後兩種版本
不要直接編輯壓縮後的 HTML，而是從原始 HTML 產生會比較安全。
適合哪些用途
我認為自我解壓縮格式的單一 HTML 很適合以下用途：
- 個人製作的工具
- 用 GitHub Pages 發佈的小型 Web 應用
- 可離線使用的 HTML 工具
- 想用單一檔案散布的 HTML 應用
- 以 CSS / JavaScript 包含完整功能的頁面
- 比起原始碼可讀性，更重視散布大小的情況
反過來說，以下用途就不太適合：
- 重視 SEO 的頁面
- 希望讀者閱讀 HTML 原始碼的教材
- 需要頻繁直接編輯的頁面
- 大量使用 Base64 嵌入圖片的頁面
- 希望在 JavaScript 無效環境下也能顯示的頁面
壓縮前與壓縮後的比較
這次比較下來，大小變化很大。
壓縮前：
壓縮後：
大小如下：
- 壓縮前：214KB
- 壓縮後：48KB
縮小了很多。
另一方面，開啟所需時間幾乎沒有變化。
也就是說，以這次的範圍來看，
成功達成輕量化，但體感速度提升幾乎沒有
就是這樣的結果。
總結
把單一 HTML 做成自我解壓縮格式後，對於以 HTML、CSS、JavaScript 為主的檔案，可以壓縮得相當明顯。
這次的例子中，從 214KB 縮小到 48KB。
另一方面，用瀏覽器打開所需的時間幾乎沒有變化。
因此，與其把它看成是提升顯示速度的方法，不如把它視為：
在維持單一 HTML 的前提下，將檔案縮小以便散布的方法
會比較合適。
特別是對於把 CSS 和 JavaScript 全部包含在 HTML 裡的網站，效果會很不錯。
相反地，如果 HTML 內嵌了圖片，由於圖片本身通常已經被壓縮過，所以變化就會比較小。
結論是：
如果想把單一 HTML 的散布大小縮小，自我解壓縮格式是相當有效的
我認為如此。
不過，開發與除錯建議在壓縮前的 HTML 上進行，只有在發佈時才使用自我解壓縮格式，這樣的運作方式比較好。
補充
留言區的內容看起來相當不錯。
原本我以為沒辦法安全地做到，所以放棄了那個方法，但有人用很巧妙的方式確保了安全性。
就我個人而言，會想加入一個處理：把二進位資料中最後一個可解讀成 </noscript 的位置，暫時在二進位層級轉成空字串，並在記錄轉換後索引的位置的同時重複處理，之後再還原回去。（與 Base64 相比，會採用輸出較短的那個方案；如果沒有可解讀的位置，就不加入還原處理）
因為看起來很有幫助，如果可以的話，也建議大家順便看看留言區。
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
