§

Options

Minify options
§

HTML を貼り付け

§

最小化後の出力

html
§

節約率

  • 元のサイズ
  • 最小化後のサイズ
  • 節約
  • 節約率

ANA や朝日新聞デジタルの JAMstack チームは Cloudflare Pages や AWS Amplify 経由で Next.js または Astro サイトをデプロイする際、毎回の CI ビルドの末尾に HTML 最小化を実行しています。エッジキャッシュは転送バイト単位で課金され、Lighthouse は容量の大きなドキュメントに減点するためです。空白・コメント・冗長属性を除去すると通常 15〜25% 軽くなり、月数百万ページビューのメディアや EC サイトでは CDN コスト削減に直結します。ブラウザー内でローカルに完結させることで、ベンダーライブラリをリポジトリにコミットする必要がなく、FISC や NISC のデータ持ち出しポリシーにも抵触しません。

HTML 最小化の仕組み

ミニファイアは小さなステートマシンで入力を走査し、そのまま保持すべき領域(<pre><textarea><script><style>)と、空白・コメントを安全に縮約できる編集可能領域を区別します。

  1. 保持ブロックのトークン化. スキャナーは入力を一文字ずつ読み進め、<pre><textarea><script>、または <style> の開始タグに差し掛かると保持状態に切り替わります。これらのタグ内のすべての内容は、対応する終了タグが来るまでバイト単位でそのまま保持されます。
  2. 編集可能領域の空白縮約. 編集可能領域では、スキャナーがスペース・タブ・改行の連続をすべて 1 つのスペースに縮約し、タグ境界前後の先頭と末尾の空白をトリムします。可視テキストのリフローはブラウザーのレンダリングと同じになります。
  3. コメントの削除. トグルがオンのとき、<!-- ... --> ブロックが削除されます。レガシーなメールクライアントが IE 条件コメント(<!--[if IE]> ... <![endif]-->)に依存しているため、条件コメント保持トグルがオンのときはそれらが残ります。
  4. 論理属性の縮約. checked="checked"disabled="disabled"required="required" といった冗長な形式が属性名だけの形に縮まります。HTML5 仕様は省略形を意味的に同等と扱うため、レンダリングされる DOM は変わりません。
  5. バイト差分のレポート. 元のテキストと最小化後のテキストはいずれも new TextEncoder().encode(...).byteLength で計測されます——CDN や HTTP サーバーが回線上で観測するのと同じ UTF-8 バイト数です。メトリクス欄は元のサイズ、最小化後のサイズ、節約バイト数、節約率を表示します。

HTML を最小化する理由

  • ページ読み込みの高速化. 小さな HTML がブラウザーに早く届き、パーサーが早く完了します。モバイルネットワークでは、バイト節約が直接 First Contentful Paint の短縮と Lighthouse パフォーマンススコアの向上につながります。
  • CDN エグレス費用の削減. CloudFront、Cloudflare、Fastly はギガバイト単位のエグレスを課金します。月間数百万ビューで HTML が 20% 減ると、画像やスクリプトの最適化より先に実際の費用削減として積み上がります。
  • クリーンな pull-request の差分. リポジトリにコミットされた事前ビルドの静的 HTML は、テンプレートを少し修正するたびにインデントが変わりノイズが多くなります。dist フォルダー内の最小化 HTML はより締まった PR 差分を生み出し、空白の乱れではなく実際のコンテンツ変更に集中できます。
  • 小さな埋め込みとスニペット. メールテンプレート、サードパーティウィジェットのスニペット、JSON や YAML 設定に格納された HTML はどれも同じバイト削減の恩恵を受けます。最小化された埋め込みはトランザクションメールを ESP のサイズ上限内に収め、ウィジェットバンドルを縮小します。

主な用途

HTML の最小化は、ほぼすべての静的サイトや JAMstack ビルドパイプラインの末尾に現れます。また、ソースの可読性よりバイト数が重視されるいくつかのランタイムコンテキストでも使用されます。

  • 静的サイトのビルドステップ:Eleventy、Hugo、Astro、Next.js のプロダクションビルドは dist フォルダーに書き出す前に HTML をミニファイアに通し、デプロイされるバンドルをソースより小さくします。
  • トランザクションメール:ESP(SendGrid、Postmark、Mailgun)は HTML 本文のサイズを制限しており、インライン CSS の展開でそのカウントはすぐ増えます。送信前に本文を最小化することでメッセージを上限内に収められます。
  • 埋め込みウィジェット:インライン HTML として提供されるサードパーティウィジェットやチャットスニペットは、訪問のたびにホストページがダウンロードするため、すべてのバイト削減が意味を持ちます。

実践的な例

2 スペースインデント、行間に 3 つの改行、先頭に HTML コメントブロック、そして <input type="checkbox" checked="checked" /> を含む冗長な 500 バイトのフォームスニペットを貼り付けてください。すべてのオプションをオンにすると、出力は約 300 バイトに縮まります——約 40% の節約——レンダリングされた DOM ツリーはソースとバイト単位で同一のままです。

最小化すると HTML が壊れますか?

デフォルトのトグル設定では壊れません。ミニファイアは <pre><textarea><script><style> タグの内容をそのまま保持し、トグルがオンのときは IE 条件コメントを intact に残し、HTML5 パーサーがすでに無意味と分類した空白だけを縮約します。レンダリングされる DOM ツリーはソースとバイト単位で同一です。積極的なトグル(空の属性を削除)は、value=""alt="" を意図的に使用するスニペットの動作を変える可能性があるため、有効にした後は出力を確認してください。

インライン CSS や JS も最小化しますか?

このツールでは行いません。インラインの <style><script> の本文はそのまま保持されるため、ミニファイアが文字列リテラルや正規表現内の空白を縮約して CSS ルールや JS の文を壊すことはありません。CSS の最小化には CSS Minifier を、JS には JS Minifier をご利用ください。HTML ミニファイアはマークアップ自体に特化しています。

どれくらい節約できますか?

手書き HTML の典型的な節約は 10〜30% で、ソースがインデント・空行・冗長属性をどれだけ使うかによって変わります。Next.js などのフレームワークが生成する事前ビルド静的 HTML は通常 15〜25% 節約できます。フレームワークがすでに一部最適化しているものの、人が読みやすい空白を残しているためです。コメントが多いテンプレートやメールスタイルの深くネストされた HTML は 40% 以上に達することもあります。

pre の内容は保持されますか?

はい。ミニファイアは <pre><textarea><script><style> ブロックをそのまま保持する領域として明示的にトークン化し、その内容をバイト単位で出力にコピーします。これらのタグ内の空白・改行・インデントは最小化後も一切変わらないため、コードサンプルと ASCII アートは最小化後もまったく同じようにレンダリングされます。

ブラウザー側の HTML 最小化はビルドパイプラインをシンプルに保ち、マークアップを小さくします。上に HTML を貼り付け、オプションのトグルを調整して、最小化された出力をコピーまたはダウンロードしてください——アップロードなし、アカウント不要、ベンダーライブラリ不要。