画像を埋め込むと、そのバイトが HTML、CSS、または別のドキュメント内に配置されます。小さなアーティファクトを自己完結型にすることができますが、画像をそのドキュメントの配信とキャッシュに結合することもできます。 URL が少ないほど常にページが高速であると仮定するのではなく、完全なワークフローに基づいて決定してください。
正しいラッパーを構築する
PNG 画像データ URI は次で始まります data:image/png;base64,、その後に元のファイルの Base64 表現が続きます。 JPEG には次のものが必要です image/jpeg; WebP のニーズ image/webp。 MIME 型の名前を変更してもバイトは変換されません。受信機が JPEG を必要とする場合は、データ URI を構築する前に画像を再エンコードします。
<img src="data:image/png;base64,BASE64_PAYLOAD" alt="Descriptive alternative text" width="32" height="32">上のプレースホルダーは動作する画像ではありません。これをエンコーダの完全な出力に置き換えます。出力にすでに data: プレフィックスを追加しないでください。周囲の引用符のバランスを保ち、リッチ テキスト エディターによって導入される改行を避けてください。
実際のサイズを計算する
エンコードされた部分には、3 つの入力バイトごとに 4 つの文字が必要で、完全なグループに丸められます。 Data URI プレフィックスはさらにもう少し追加します。 30,000 バイトのファイルの場合、ペイロードだけで 40,000 文字になります。 HTML 圧縮により転送サイズが変更される可能性がありますが、ブラウザはドキュメントを解析して画像をデコードする必要があります。ソースファイルだけでなく、実際のページも測定してください。
個別に提供された画像はキャッシュされ、ページ全体で個別に再利用できます。埋め込まれた画像は、それを含むすべてのドキュメントに関連付けられます。したがって、大きく繰り返されるイラストは自動インライン化の候補としては適していません。自己完結型レポート内の小さな 1 回限りのアイコンは、合理的なトレードオフになる可能性があります。
目的地を確認する
コンテンツ セキュリティ ポリシーで制限できるのは data: 画像。電子メール クライアントは、埋め込みコンテンツを削除または拒否する場合があります。ブラウザでプレビューされるファイルは、受信者のアプリケーションでそのファイルが表示されることを証明するものではありません。サポートする必要がある正確なエクスポート、電子メール クライアント、またはダウンストリーム システムをテストします。
一時的なローカル プレビューの場合、Blob URL は、多くの場合、大きな Base64 文字列の作成を回避します。ビューが削除されたら、URL を取り消します。エクスポートされたスタンドアロン HTML の場合、データ URI が適切な場合があります。どちらの場合でも、代替テキストと寸法を保持します。構文とブラウザの考慮事項については、次の記事で説明しています。 MDN: データ URL。