HTMLのいわゆる最小化(圧縮)を行うようにした。HTML Minifierを何度か使う機会があり、それなりに安定していることがわかったので、得られるパフォーマンスと背負うリスクが妥当なのではないかという方向へ傾いてきた。
HTML Minifierのオプションは以下のようなものにした。かなりの数のオプションを有効化し、すこしきつめに圧縮してみている。
var optionsHTMLMinifier = {
collapseBooleanAttributes: true,
collapseInlineTagWhitespace: true,
collapseWhitespace: true,
minifyCSS: true,
minifyJS: true,
removeAttributeQuotes: true,
removeComments: true,
removeEmptyElements: true,
removeOptionalTags: true,
removeRedundantAttributes: true,
removeScriptTypeAttributes: true,
removeStyleLinkTypeAttributes: true,
sortAttributes: true,
sortClassName: true,
useShortDoctype: true
};
開発者ツールがあるので、HTMLがおかしいかどうかはチェックすることは難しくない。ソースマップが欲しいかなと思ってはいたが、現状のHTMLという存在の性格上、必要ないようだ。最小化したHTMLが壊れている場合、そこに至るまでのどこかしらのツールがおかしいだけで、制作者のミスという可能性はかなり低い。ということはソースマップを使ってデバッグしても原因が特定できないことになるからだ。
こういったHTML(に限らずCSSやJavaScript)の最小化はCloudflareなどでも一機能として提供されている。しかしどういうツールを使っているのか明らかにされておらず、結果が保証されない。自分の書くコードと最小化ツールとの相性は当然あるため、背負うリスクはかなり高いのではないかと感じる。
どうせ最小化するからといって色々と省略しつつHTMLコードを書くのはあまり薦められない。ただそれは省略することを意識すると書きにくいという理由ではない(そういうのは慣れの問題と言える)。HTMLコードでの様々な省略した書き方が多くの人が想像する以上にややこしく、完全に理解するのはまず無理だからだ。またネストがカギの構造であるHTMLコードでは、インデントと改行は読みやすさに直結するであろうからだ。
collapseInlineTagWhitespace
がtrue
だと記号間の調整に使っている空白が消えるので、無効にした。またDIFFが確認しづらく、出力されたHTMLが正しいか把握しづらい問題には、preserveLineBreaks
を有効にすればよいことを学んだ。このウェブサイトでは巨大な(3000行やそれ以上の)HTMLファイルがあるため、有効にしていない。