ページの読み込みを高速化するために HTML を縮小する方法

HTML は、ブラウザがすべてのページで最初にダウンロードするものです。 CSS がスタイルをペイントしたり JavaScript を実行したりする前に、ドキュメントが到着して解析される必要があります。そのため、不要なコメント、インデントされた行、タグ間の空白のギャップによって、クリティカル パスで時間がかかります。 HTML を縮小すると、ページの外観や動作を変更することなく、これらの文字が削除されます。このガイドでは、Core Web Vitals にとって HTML サイズが重要な理由、安全な縮小によって削除されるもの、バイト前後の具体的な例、gzip または Brotli と組み合わせる方法、ワークフロー内で縮小するタイミング、絶対に壊してはいけないものについて説明します。

LCP と TTFB にとって HTML サイズが重要な理由

Core Web Vitals では、高速に感じられるページに報酬を与えます。 HTML サイズを最も直接的に感じる 2 つの指標は次のとおりです。

• 最初のバイトまでの時間 (TTFB): ブラウザーは、解析を開始する前に HTML 応答を待ちます。特にモバイル ネットワークや遠く離れた CDN では、ドキュメントが小さいほど、生成、キャッシュ、転送が高速になります。
• 最大のコンテンツフル ペイント (LCP): メイン コンテンツは、ブラウザーがコンテンツを検出してレンダリングするのに十分な HTML (および重要な CSS) を取得するまでペイントできません。 HTML バイトが少ないということは、最初の意味のあるペイントまでのダウンロードと解析の作業が少なくなるということです。

HTML は他のすべてのものにとってもボトルネックになります。ブラウザはドキュメントを読み取ることで、スタイルシート、スクリプト、画像、フォントを検出します。 HTML ストリームが到着するまで、これらのリソースは表示されません。ドキュメントの縮小は、画像の最適化やコード分割に代わるものではありません。しかし、これはクリティカル パスにおいて最も安価な方法の 1 つであり、すべてのページ ビューに影響を与えます。

HTML 縮小によって削除されるもの

安全な HTML 縮小化は、DOM の構築時にブラウザーが無視する文字をターゲットとします。慎重なミニファイアーは通常、次のことを行います。

• HTML コメントを削除します (IE の条件付きコメントがまだ必要な場合は保持します)。
• 人間が読みやすいようにするためだけに存在する、インデント、タブ、空白行など、タグ間の一連の空白を折りたたみます。
• タグの周囲の不要なスペースをトリミングして、レンダリングされたテキストを変更せずにマークアップをより少ない行に詰め込みます。
• マークアップの意味はそのまま残ります。つまり、同じ要素、属性、表示されるコンテンツがそのまま残ります。

できないこと: minify HTML は CSS または JavaScript コンプレッサーではありません。インライン スクリプトとスタイル ブロックはそのままにしておく必要があります (または専用の JS/CSS ミニファイアーに渡される)。また、属性値の変更、URL の書き換え、未使用の DOM の削除も行いません。これらは個別の最適化です。

前後: 実際のバイト比較

以下は、ほとんどのエディターと CMS エクスポートで作成される方法で書式設定されたランディング ページの小さなフラグメントです (インデント、空白行、開発者コメントが含まれています)。

• <!DOCTYPE html>
• <html>
• <頭>
• <title>ようこそ</title>
• <!-- サイトヘッダー -->
• <meta charset="utf-8">
• </head>
• <本文>
• <h1>こんにちは</h1>
• <p>今日から始めましょう。</p>
• </body>
• </html>

そのフォーマットされたバージョンは 196 バイトです。縮小すると、コメントとタグ間の空白が消えます。

つまり、小さなスニペットでは 59 バイト (約 30%) が節約されます。実際のページはさらに大きくなります。デザイン ツールのエクスポート、CMS テンプレート、電子メールの HTML には、深いネスト、繰り返しのインデント、残されたコメントが含まれることがよくあります。これらのファイルでは、圧縮が実行される前に、縮小化によって生の HTML サイズの 15 ～ 40% がトリミングされるのが一般的です。

縮小化を gzip または Brotli と組み合わせる

ほぼすべての実稼働サーバーは、すでに gzip または Brotli を使用して HTML を圧縮しています。これらのアルゴリズムは、繰り返されるスペースを圧縮するのに優れています。そのため、縮小のみによるネットワーク経由のゲインは、生のバイトの差よりも小さくなります。縮小しても次の 3 つの理由で役立ちます。

• メモリ、ディスク キャッシュ、CDN オリジン ストレージの非圧縮サイズが小さくなります。
• 圧縮がスキップされたり弱い場合でも、コンプレッサーの仕事が減り、ペイロードが小さくなります。
• 解凍後の HTML 解析が高速化 - トークナイザーが歩く文字が少なくなります。

HTML を縮小する場合 (ビルドとデプロイ)

マークアップを書いている間ではなく、運用環境に移行する途中で縮小します。

• 静的サイトとランディング ページ: ホストまたは CDN にアップロードする前の最後のビルド ステップとして HTML を縮小します。
• テンプレートと電子メール HTML: 送信または公開するエクスポート ファイルを縮小します。読み取り可能なソースをリポジトリまたは ESP に保存してください。
• CMS またはデザインツールのエクスポート: 出荷前に肥大化したマークアップに対してミニファイアーを 1 回実行します。
• フレームワーク アプリ: 運用ビルドではフレームワークまたはバンドラーの HTML 縮小オプションを優先します (多くのアプリではすでに有効になっています)。

フォーマットされた HTML をソース管理に保持します。差分は読みやすく、レビューも健全なままで、単一行のドキュメントを手動で編集する必要はありません。縮小化は出力変換であり、オーサリング形式ではありません。

壊してはいけないもの: スクリプト、スタイル、プレ

積極的に空白を削除すると、間違った領域に触れるとページが破壊される可能性があります。安全な HTML ミニファイアーは以下を保護する必要があります。

• script: JavaScript では多くの場合、改行とスペースが必要です。 <script> 内のストリッピングはコードを壊したり、ASI の動作を変更したりする可能性があります。
• style: CSS には特定のスペースが必要です (たとえば、calc() の + と - の周囲)。インライン CSS は CSS ミニファイアーに任せます。
• pre および textarea: ホワイトスペースは意味のあるコンテンツです。ホワイトスペースを折りたたむと、ユーザーが表示およびコピーする内容が変わります。
• 条件付きコメント: <!--[if IE]> ブロックは、一部の従来の電子メールおよびサポート マークアップで依然として使用されています。未使用であることがわかっている場合を除き、保管してください。

ミニファイアーがこれらの領域に関して保守的である場合、謎のプロダクション バグを発生させることなく、サイズを優先することができます。これらのレイヤーも圧縮したい場合は、インライン JS と CSS を専用のミニファイアーに渡します。

よくある質問

HTML を縮小するとページの見た目は変わりますか?

いいえ、安全に完了した場合に限ります。コメントを削除したり、タグ間の空白を折りたたんだりしても、DOM 構造や表示されるテキストは変更されません。ページは同じようにレンダリングされるはずです。配信されたファイルで人間が判読できる形式が失われるだけです。

HTML の縮小は gzip 圧縮と同じですか?

いいえ。縮小化では、HTML テキストがより小さい有効なドキュメントに書き換えられます。 Gzip と Brotli は転送用にバイトをエンコードするため、解凍が必要です。両方を使用します。HTML を縮小し、ネットワーク上で圧縮します。

ページの読み込みはどれくらい速くなりますか?

それは、元の HTML がどれだけ肥大化したか、および HTML が画像やスクリプトと比較してどれくらい大きいかによって異なります。縮小化により、多くの場合、生の HTML バイトが 15 ～ 40% 削減されます。 TTFB と LCP に顕著に役立つ HTML の多いページまたはモバイル ページ。画像の多いページでは、絶対ゲインは小さくなりますが、それでも無料です。

開発中に HTML を縮小する必要がありますか?

通常はいいえ。開発およびデバッグ中は、読み取り可能なマークアップを維持してください。ソースを保守しやすい状態に保つため、実稼働ビルドまたは最終公開ステップとしてのみ縮小します。

ページをアップロードせずに HTML をオンラインで縮小できますか?

はい。ブラウザベースの HTML ミニファイアーがデバイス上でマークアップを処理するため、プライベート テンプレートや未リリースのページがマシンから流出することはありません。結果をデプロイステップに貼り付け、縮小し、コピーします。