オンライン JSON エディタが 20MB の Base64 でフリーズする理由とベンチマーク結果

20MB の Base64 文字列を含む API レスポンスでは、解析、ハイライト、レイアウトに時間がかかる場合があります。影響はエディタ、ブラウザ、端末、テストデータで異なるため、ここでは 3 つのツールを同じ手順で比較します。

なぜこんなことが起きるのでしょうか。ハードウェアの性能不足なのか、それともブラウザがテキストを処理する方法そのものに根本的な欠陥があるのか──。ハイエンドなデスクトップ環境で透明性のあるベンチマークを行い、主要フォーマッタが限界を迎える本当の原因と、その解決策を探りました。

20MB ベンチマーク：主要オンライン JSON エディタを徹底比較

ハードウェア側の言い訳を排除するため、フラッグシップ級の開発マシンでテストしました：

• CPU: Intel Core i7-14700F
• メモリ: 32GB RAM

Playwright スクリプトを使い、1MB〜20MB のペイロードを各ツールに貼り付ける操作をシミュレートしました。GitHub Gist のスクリプトで再現・カスタマイズが可能です。以下は実測結果で、Load 時間を中心に記載しています（括弧内は Format／Minify 時間）：

生の CSV をダウンロード。ランナーは処理時間と失敗を記録していますが、OS、Chromium、Playwright、ネットワーク、各サイトのビルド番号は記録していません。恒久的な順位ではなく、日付付きの測定結果として参照してください。

なぜオンライン JSON エディタは巨大な Base64 文字列で重くなるのか

この圧倒的なパフォーマンス差は、従来の Web アプリケーションがコードハイライトを処理する方法に深刻な限界があることを浮き彫りにしています。オンライン JSON エディタが大きな Base64 データで遅くなる原因は、主に 2 つのボトルネックに集約されます：

1. シングルスレッド CPU ボトルネック

多くのエディタ処理はメインスレッドで動くため、大きな文書の解析やトークン化が操作を遅らせることがあります。Worker で一部を移せますが、実装はエディタごとに異なり、CPU 使用状況は実測が必要です。

2. 超長一行テキストの描画ボトルネック

JSON ファイルを処理する際、シンタックスハイライタは Base64 文字列全体をたった 1 つの <span class="string"> ノードにラップします。問題の本質は、このノードに約 2,700 万文字が含まれ、かつ改行なしの 1 行として存在していることです。エディタのコアエンジンはこの「超長一行」に対して文字幅の測定、折り返し位置の算出、カーソル位置の計算を行わなければなりません。これほど巨大な連続文字列に対するレイアウト計算は、壊滅的なメモリオーバーヘッドを引き起こし、ブラウザのメインスレッドを完全にロックしてしまいます。

ViewJSON のアプローチ：メディア置換とロスレスクリップボード

従来のエディタがフリーズするのは、人間に読ませるために数千万文字をレンダリングしようとするからです。しかし私たちは根本的な事実に気づきました──20MB の Base64 を貼り付ける開発者は、その文字列を読みたいわけではなく、その裏にある実際のメディアを確認したいのです。ブラウザの限界に正面からぶつかるのではなく、ViewJSON は UX の観点からアーキテクチャを設計し直しました：

• メディア置換（単なる切り捨てではない）: ViewJSON は Base64 文字列を検出すると、マジックバイトをデコードし、読めないコードブロックを実際のインラインメディアプレビュー（画像など）に丸ごと置き換えます。プレビューをオフにした場合は、長い文字列をスマートに省略表示します。いずれの場合も、数百万文字がエディタのテキストバッファに入り込むのを防ぎ、コアエンジンと描画スレッドの負荷を根本から解消します。
• ロスレスクリップボード復元: 元のテキストを隠すと、通常は致命的な問題が生じます──コピーした JSON からデータが欠落するのです。ViewJSON はカスタムクリップボードマネージャーでこの問題を解決します。画面に表示されているのが画像プレビューでも省略テキストでも、「コピー」をクリックすれば、エディタがバックグラウンドで元の Base64 ペイロードを復元し、コピーされたデータは 100% 完全な状態が保たれます。

この測定環境では、ViewJSON の 20MB ケースの読み込みは約 1.6 秒でした。ペイロード、ブラウザ、端末が変われば結果も変わります。