MiB を kB に変換

1 メビバイトは 1,024 キビバイト、つまり 1,048,576 バイトです。Linux のツールとメモリーの数値は、表示が「MB」であってもほぼ常にこちらを指しています。

1 キロバイトは、標準化団体が定義すれば 1,000 バイトで、OS が定義すれば 1,024 バイトです。このページは 1,000 で計算します。1,024 のほうはキビバイトという名前を持っています。

倍率は 1048.576 で、これをそのまま持ち歩く人はまずいません。1050 に丸めると 0.14 % ずれます。小さい数では見えもしませんが、1,000 MiB あたりで、ずれは丸ごと 1 単位になります。

丸める前に知っておく価値があるのは、ずれの大きさそのものではなく、それを無視できなくなる地点のほうです。それより下なら短い倍率が賢明で、それより上なら上の入力欄を使ってください。あちらは書き出す前に丸めません。

MiB 1 つはひとつ下の単位の 1,024 倍で、MB 1 つは 1,000 倍です。このページでは 1048.576 kB と 1000 kB の差——4.9 %——になり、段を上がるごとにこの隔たりは開いていきます。写真 1 枚では丸め誤差でしかないものが、ハードディスクでは目に見える割合になるのはそのためです。

「容量が消えた」という話の中身は、これだけです。MB で売られたディスクには、書いてあるとおりのバイト数が入っています。それを 1,000 ではなく 1,024 で割り、名前は MB のまま表示しているのが Windows です。macOS は 10.6 以降ディスクの容量を十進の単位で数えているので、同じディスクが 2 台のパソコンで違う大きさに見えることがあります。減ったものはなく、丸めているのでもありません。同じバイト数に、名前が 2 つあるだけです。

ビルドツールは2進法の単位で報告します。それがファイルシステムの持っているものを説明しているからです。パフォーマンス予算やネットワークパネル、ページ重量のレポートは10進法のキロバイトで書かれます。それがウェブパフォーマンスの世界が10進法をずっと以前から慣習にしているからです。両方は内部では一貫していて、互いには一致しません。

変換は1,048.576を掛けるだけです。1.5MiBと表示されたバンドルは1,536でも1,500でもなく1,572.9kBです。1,500kBの予算に対しては5パーセント近く超過していて、頭の中でのざっくり換算がまさにそれを隠しています。1.5MiBは「だいたい1.5メガバイト」に聞こえて、まるで収まりそうに見えるのです。

4.9パーセントを心配する前に、そもそもその数字が正しいものを測っているか確認してください。ビルドツールは書き出したファイルのサイズを報告し、ユーザーは接続を通過した圧縮後のバイトを待っています。テキスト系のアセットはたいてい生のサイズの5分の1から4分の1に圧縮されるので、1.5MiBのバンドルが実際には350kBで届くこともあり、生のサイズに対して立てた予算はパーセントではなく倍率で狂います。

だからといって単位の変換が不要になるわけではありません。圧縮後の数字にも何らかの単位が必要で、そこにも同じ2.4パーセントが当てはまります。順序は明確です。まずパイプラインのどの段階を表しているかを確定させ、そのあとで単位を変換してください。2番目を正しくして1番目を間違えると、間違った量についての正確な数字が得られてしまいます。

ランダムな計測誤差は十分な数のアセットがあれば平均化されますが、単位の誤差はそうなりません。毎回同じ掛け算が同じ方向に働くからです。どのアセットも実際より少し小さく見え、合計も実際より小さく見え、予算に対する比較はどれも少しだけ楽観的になります。レポートのどこにも間違って見える箇所はなく、バイトを実際に測った何かで集めたフィールドデータと突き合わせたときにだけ、その一致は崩れます。

これが積み重なると、この問題を単なる細かい話ではなく本当のギャップにします。20個のアセットからなるページで、それぞれを丸めた係数で変換すると全体で2.4パーセント不足し、普通のページでは30から40キロバイトになります。これはちょうど小さなライブラリー1つぶんの大きさで、チームがそれを取り除くために午後を丸ごと費やすようなものです。予算を厳しくする提案が出たときは、この比較を明示的に行う価値があります。正しい変換は本物の最適化と同じ数のキロバイトを取り戻せて、しかも1行の算術で済みます。

同じアセットについて、この2つが同じ数字を示すことはめったになく、理由が積み重なっています。ビルドレポートは2進法の単位で生のバイトを示し、ネットワークパネルは圧縮済み、10進法で、ヘッダーを含むかどうかも一定しません。この違いのどれか1つだけでも数十パーセントの食い違いを生み、3つ揃えば直接の比較は意味を持たなくなります。

比較する方法は、両方を同じ量のバイト数に落とし込むことです。圧縮済みの成果物を取り、その正確なサイズを読み、それをブラウザーが報告する転送サイズと比べてください。残りの差はプロトコルのオーバーヘッドに帰せられるくらい小さいはずです。そこが一致してしまえば、どちらの側の見慣れた単位を使ってもよく、その下にある共通のバイト数がすでに手元にあるからです。

どこでもというわけではありません。いちばん重要なバイトは、最初の描画をブロックしているもの——クリティカルパスの CSS、コンテンツが表示される前に実行されなければならないスクリプト、テキストを止めているフォント——です。そこでの50キロバイトは、あとから遅延読み込みされる500キロバイトより値打ちがあり、すべてのバイトを均等に扱う予算は、間違った場所を精密に最適化してしまいます。

ここで単位の問題は机上の空論ではなくなります。クリティカルパスの予算は厳しいものだからです。ブロッキング JavaScript の目標150kBにはほとんど余裕がなく、0.15MiBの数字を150kBだと思って変換すると、実際には157.3kBなので、予算の5パーセントを算術だけで使ってしまうことになります。10倍大きい予算を持つ遅延読み込みのチャンクでは同じ誤差は見えず、時間をかける価値もありません。

予算は、数か月後に自分が持っていた文脈なしで、別の誰かが適用する数字です。だから量、単位とその体系、パイプラインのどの段階か——圧縮済みか生か、アセットごとかページごとか——の3つを一緒に書く必要があります。3つのうちどれかを暗黙のままにすると、あとから誰かがそれを憶測で埋め、その憶測はしばしば本来の意図と食い違います。

機械的なやり方は、強制する設定の中では予算をバイト数で表現し、その隣の文書に人が読める数字を添えることです。バイト数は読み違えようがなく、どのツールの内部の測定とも直接比較でき、下流の誰かが予算を立てた人が1,000のつもりだったのか1,024のつもりだったのかを知る必要をなくします。