重複の可能性:
マークアップではなくアセットを縮小するのはなぜですか?
ウェブサイトの応答時間を増やすために縮小されたCSSとJavaScriptを使用しているサイトをたくさん見ましたが、縮小されたHTMLを使用しているサイトは見たことがありません。HTMLを縮小したくないのはなぜですか?
重複の可能性:
マークアップではなくアセットを縮小するのはなぜですか?
ウェブサイトの応答時間を増やすために縮小されたCSSとJavaScriptを使用しているサイトをたくさん見ましたが、縮小されたHTMLを使用しているサイトは見たことがありません。HTMLを縮小したくないのはなぜですか?
とにかく、適切に処理を行っている場合は、HTMLをgzipで圧縮して提供しているため、HTMLミニファイの成果である空白文字はそれほど重要ではありません。CSSやJavaScriptに存在する、HTMLでの縮小の簡単なターゲット(変数名など)は多くありません。HTMLのコンテンツの多くは、ページの実際のコンテンツであり、おそらく縮小することはできません(そして、他の人が指摘しているように、CSSやJSよりも頻繁に変化することはほぼ間違いありません)。
ほとんどのサイトには静的なCSSとJavascriptがあると思います。これは、更新されるたびに1回だけ縮小できることを意味します。一方、HTMLは動的に生成される傾向があります。つまり、ページリクエストごとに縮小する必要があり、静的CSSファイルやJavascriptファイルを縮小するよりもかなりコストがかかります。
HTMLには縮小の余地はあまりないと思います。空白や改行を削除することはできますが、基本的には、ページの構造に実際に入ることなく、それだけです。
JSの縮小化により、変数名と関数名を短縮できます。これは、節約されたスペースの点でおそらく最大の純利益です。タグの固定セットでは、HTMLはその可能性を提供しません。
HTMLをgzipするオプションは、特にHTMLに対して通常有効になっているため、とにかく縮小する必要性の多くをおそらく排除しますが、CSSおよびJSファイルタイプに対して常に有効であるとは限りません。
主な理由は、Javascript ファイルと CSS スタイルシートは多くの場合、展開時に変更されない静的ファイルであるためです。一方、マークアップはその場で生成されることが多く (少なくともデータベース駆動型の Web アプリでは)、「ページ」の数は通常大きくて動的であるため、縮小の利点は価値以上に機能します。
gzip される Html コンテンツは、圧縮の大部分を処理します。その上で縮小しても、多くのことは達成されず、帯域幅を大幅に節約することもできません。
ビルドの一部として縮小できる Javascript。これが HTML コンテンツ全体で発生する唯一の方法は、すべての部分を縮小するか (それが生成された場合はどうなるでしょうか?)、またはずっと縮小することです (作業するのは悪夢ですか?)。
コスト対メリット、コスト:限界帯域幅、メリット: 作業しやすく、生成しやすく、デバッグしやすく、ソース ビュー ウィンドウにきれいに表示されます。