ブログ

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

2026年4月23日公開 · 約 6 分で読めます

API レスポンスをオンラインの JSON エディタに貼り付ければ、普通はすぐに表示されるはずです。しかしデータの中に AI やマルチメディア API が返す 20MB の Base64 画像文字列が含まれていると、ほとんどのツールは極端に重くなります。レスポンスは膨れ上がり、スクロールはカクつき、エディタ自体が操作不能に陥ります。

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

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

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

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

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

ファイルサイズ CodeBeautify JSONFormatter ViewJSON
1MB 1.1s(F: 1.1s, M: 1.0s) 1.2s(F: 0.9s, M: 1.0s) 0.7s(F: 0.6s, M: 0.6s)
5MB 2.5s(F: 4.1s, M: 3.1s) 4.3s(F: 3.0s, M: 3.8s) 0.9s(F: 0.7s, M: 0.7s)
10MB 4.3s(F: 7.8s, M: 6.4s) 5.9s(F: 5.2s, M: 6.9s) 1.1s(F: 0.8s, M: 0.7s)
20MB 8.7s(F: 16.0s, M: 13.1s) 12.6s(F: 15.4s, M: 11.6s) 1.6s(F: 1.0s, M: 0.8s)

* F = Format 時間、M = Minify 時間。 各値は 3 回計測の中央値。メインカラーの数値は Load 時間を示します。 時間は小数第一位に四捨五入。

20MB読み込み時間の棒グラフ: CodeBeautify 8.7s、JSONFormatter 12.6s、ViewJSON 1.6s。
20MBベンチマークの可視化(低いほど高速)。

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

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

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

ブラウザの JavaScript 実行はシングルスレッドです。従来のフォーマッタが 20MB のファイルを受け取ると、構文トークナイズとレイアウト計算という非常に重い処理をメインスレッド上で実行します。この処理を複数の CPU コアに分散することはできないため、i7-14700F のようなハイエンド CPU でもほとんど活かされません。1 コアだけが 100% に張り付き、ページ全体がクリックにもスクロールにも反応しなくなります。

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

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

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

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

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

この「レンダリング回避」と「データ完全性」の組み合わせにより、ViewJSON は 20MB のペイロードを 2 秒未満でフォーマットできます。

関連記事

JSON API レスポンス内の Base64 画像をデバッグする方法 →

遅い JSON エディタはもう卒業しよう

巨大な JSON レスポンスを ViewJSON にそのまま貼り付けてください。瞬時のフォーマット、インラインメディアプレビュー、ゼロ遅延を体験できます。

ViewJSON を開く →