データURIサイズ計算

フォント、アイコン、スタイルシートをデータURIとして埋め込むと追加のHTTPリクエストを避けられますが、Base64符号化はペイロードをおよそ三分の一膨らませ、data: 接頭辞がさらに文字を足します。返すのは正確な Base64 ペイロード長、データURI全体の文字数、約三十三パーセントのペイロード増、接頭辞込みの総増、およびインライン化するか別リンクのままにするかの推奨です。成功した API 呼び出しは $0.002、不正な入力は課金されません。

元バイト数から Base64 データURIサイズを求める方法

data、任意のメディア種別、セミコロン base64 トークン、カンマ、そしてペイロードです。ペイロードは RFC 4648 の標準 Base64 で、元の3バイトが4つの ASCII 文字になるため、符号化長は元の長さを3で割った天井のちょうど4倍です。元の長さが3の倍数でないときは、等号のパディングが最後の四文字組を埋め、ペイロード長は常に4の倍数になります。ペイロードだけの増加はおよそ三十三パーセント——元サイズが3の倍数ならちょうど三分の一、パディングがあれば少し多め——です。

入力契約、応答の形、エラー時の挙動

bytes は符号化前の元リソースサイズを表す正の整数（または数値文字列）です。既定の octet-stream で1万バイトなら URI は 13373 文字で link 推奨です。文字列そのものが必要なら独自の符号化器と組み合わせてください。必須フィールド bytes を1つ持つ JSON 本体を POST してください。任意の media_type（別名 mime、type、content_type、mime_type）は接頭辞に書く MIME 種別で、省略時は application/octet-stream です。任意の budget（別名 max、limit、max_bytes、max_size）はまだインライン化に値するとみなすデータURIの最大長で、既定は HTTP/1 の経験則である 2048 です。欠落・空・非整数・0・負はフィールド名付きの invalid_input で失敗し、type/subtype でない、空白やカンマを含むメディア種別も同様に拒否されます。これらの失敗は課金されません。成功時、本体は bytes、media_type、budget をエコーし、prefix と prefix_chars、base64_chars と padding_chars、data_uri_chars と overhead_chars を返し、元ファイルに対する URI 全体の overhead_percent と Base64 ペイロードだけの payload_overhead_percent（およそ三十三パーセントの数字）、元バイトに対する URI 長の expansion_ratio、within_budget と inline または link の recommendation を返します。例：image/png の 1024 バイトは接頭辞 22 文字、パッド2の Base64 1368 文字、データURI 1390 文字、ペイロード増約 33.59 パーセント、既定予算 2048 に対する inline 推奨です。この端点は符号化済みペイロードを出しません。

三十三パーセント増でもデータURIのインライン化が見合うとき

インライン化する通例の理由はリクエスト削減です。Base64 はその取引を約三分の一悪化させ、HTTP/2 や HTTP/3 の多重化は HTTP/1 より個別リクエストを安くするため、損益分岐のサイズは 2012 年頃の記事が今も主張する値より小さくなります。8キロバイトの url-loader 上限を使っていたバンドラは HTTP/1 のスプライト向けでした。その旧規則に合わせるなら budget を 8192 に上書きし、HTTP/2 サイトなら下げてください。pull-request 検査の門として使い、data_uri_chars が上限を超えたらリソースを URL のままにしてください。