API 応答のすべてのバイトをシリアル化し、ネットワーク上にプッシュし、相手側で再度解析する必要があります。 JSON を縮小すると、人間が読みやすくするためにスペース、タブ、改行が削除され、単一の値に触れることなくペイロードが縮小されます。トラフィックの多い REST および GraphQL エンドポイント、低速接続のモバイル クライアント、および生の JSON として保存したものについては、保存されたバイト数が加算されます。このガイドでは、JSON を縮小する理由と方法、実際の前後のバイト数、縮小すべきでない場合、および JavaScript と Python で縮小する方法を示します。
クイック回答
JSON を縮小すると、データの一部ではないすべてのスペース、タブ、改行が削除され、1 行に折りたたまれます。値が変更されることはありません。パーサーは、{"a": 1} と {"a":1} をまったく同じオブジェクトとして読み取ります。実稼働 API 応答、ストレージ、ログ用に JSON を縮小します。読み取りとデバッグのためにフォーマットされたコピーを保存します。
API 用に JSON を縮小する理由
縮小化は、マシンが必要としない文字、つまり改行、インデント、および編集者が読みやすくするために追加する各コロンとカンマの後のスペースを対象とします。それらを削除すると、API にいくつかの具体的な利点があります。
- ペイロードの縮小: すべてのリクエストと応答で送信するバイト数が少なくなります。これは、大容量のエンドポイントや従量制のモバイル データでは最も重要です。
- 転送と解析の高速化: ネットワーク上で移動するデータが減り、クライアントが JSON を読み取るときにスキャンするテキストが減ります。
- ストレージとログのコストの削減: データベース列、キャッシュ、メッセージ キュー、またはログ行に保持される JSON は、縮小されたときに必要なスペースが少なくなります。
- よりクリーンなワイヤ形式: クライアント アプリケーションは整形印刷を必要としません。インデントは開発者の利便性であり、アプリが依存するものではありません。
前後: 実際のバイト比較
以下は、一般的な REST エンドポイントからの小さなユーザー レコードです。ほとんどのエディターと JSON.stringify(obj, null, 2) が生成する 2 スペースのインデントでフォーマットされています。すべての行に改行とインデントが追加されます。
- {
- 「id」: 42、
- "名前": "エイダ ラブレス",
- "電子メール": "ada@example.com",
- 「アクティブ」: true、
- 「役割」: [
- 「管理者」、
- "エディタ"
- ]
- }
そのフォーマットされたバージョンは 132 バイトです。縮小すると、まったく同じデータが 1 行に折りたたまれます。
縮小 - 98バイト
{"id":42,"name":"Ada Lovelace","email":"ada@example.com","active":true,"roles":["admin","editor"]}
つまり、1 つの小さなオブジェクトで 34 バイト (約 26%) が節約されることになります。実際の API 応答は通常、はるかに大きく、より深くネストされています。つまり、それぞれが同じキーとインデントを繰り返す数百のレコードの配列です。これらのペイロードでは、通常、縮小によって生のサイズの 20 ～ 50% がトリミングされ、ネストのレベルが上がるごとに節約量が増加します。
gzip と Brotli はどうですか?
ほとんどのサーバーはすでに gzip または Brotli を使用して応答を圧縮しており、これらのアルゴリズムは繰り返される空白を圧縮するのに非常に優れているため、縮小化だけによるネットワーク経由の節約は、生のバイトの差が示すよりも小さいです。縮小は依然として役に立ちます。メモリ、キャッシュ、ログ、ストレージに存在する非圧縮サイズが縮小され、コンプレッサーの作業が軽減され、圧縮が利用できない場合でもペイロードの減少が保証されます。両方を使用します。最初に縮小し、次にサーバーで圧縮します。
JSON を縮小すべきではない場合
縮小された JSON は読むのが惨めなので、人間が見る必要がある場所には常に空白を残しておきます。
- デバッグと開発: きれいに印刷された JSON は、エディター、手動で読むログ、および積極的に検査している応答でスキャンするのがはるかに簡単です。
- バージョン管理の構成ファイル: package.json、tsconfig.json、および同様のファイルは、差分が読みやすく、マージ競合が管理しやすいようにフォーマットされたままである必要があります。
- ドキュメントと例: API ドキュメント内のサンプル リクエストとレスポンスは、読者が構造を理解できるようにフォーマットされている必要があります。
- ユーザーが直接編集するものはすべて、手作業で管理された JSON はインデントされたままにする必要があります。ビルドまたはデプロイのステップとしてのみ縮小してください。
経験則
人間向けにフォーマットし、マシン向けに minify します。読み取り可能なバージョンをソース管理とエディターに保持し、運用トラフィック、ストレージ、ログに出力される途中でのみ縮小します。
コード内の JSON を縮小する方法
JavaScript / Node.js
JSON.stringify はデフォルトですべてのオプションの空白を省略するため、文字列を解析してスペーサーなしで再文字列化すると、縮小された出力が得られます: JSON.stringify(JSON.parse(input))。すでにオブジェクトがある場合は、JSON.stringify(obj) を呼び出すだけです。 JSON.stringify(obj, null, 2) のように 3 番目の引数を渡すと、その逆が行われ、きれいに表示されます。
パイソン
Python の json.dumps はデフォルトですべてのカンマとコロンの後にスペースを追加するため、出力は完全には縮小されません。コンパクトな区切り文字を渡してそれらを削除します: json.dumps(obj, separators=(",", ":"))。代わりに整形して表示するには、json.dumps(obj, indent=2) を使用します。
どちらのアプローチも、データを書き出す前にデータを解析するため、データの検証も行います。不正な形式の JSON は、送信する前にエラーをスローします。これは、スクリプトを書かなくても、オンラインのミニファイアーがブラウザーで実行することとまったく同じです。
よくある質問
JSON を縮小するとデータは変更されますか?
いいえ。縮小化ではトークン間の空白のみが削除されます。キー、値、配列、オブジェクトは変更されません。パーサーは {"a": 1} と {"a":1} をまったく同じオブジェクトとして読み取るため、縮小された JSON は常に安全に送信、保存、解析できます。
縮小された JSON はどれくらい小さくなりますか?
それは、元の文字列にどれだけの空白が含まれているか、およびどれだけ深くネストされているかによって異なります。コンパクトなオブジェクトは 10 ～ 20% 縮小する可能性がありますが、大きくインデントされ、深くネストされたペイロードは 30 ～ 50% 縮小する可能性があります。サーバー上の gzip または Brotli 圧縮は、繰り返しの空白をすでに適切に処理しているため、回線上の差異が減少することに留意してください。
API 応答の JSON を縮小する必要がありますか?
運用トラフィックの場合ははいです - フォーマットを気にしないクライアント アプリケーションにきれいに印刷された JSON を送信する理由はありません。また、多くのフレームワークはデフォルトでコンパクトな JSON を返します。 API を手動で探索する開発者に書式設定されたオプションを提供することは依然として良いことであり、一部の API は ?pretty=true フラグを通じて公開します。
縮小された JSON は依然として有効な JSON ですか?
完全に。トークン間の空白は JSON 仕様ではオプションであるため、これを削除すると、準拠したパーサーが受け入れる有効な JSON が生成されます。失われるのは人間の可読性だけであり、再フォーマットすることでいつでも復元できます。
JSON の縮小と圧縮の違いは何ですか?
縮小すると、有効で読み取り可能な JSON を維持しながら、テキストからオプションの空白が削除されます。圧縮 (gzip または Brotli) では、クライアントが使用前に解凍する必要がある小さなバイナリ BLOB を生成するアルゴリズムを通じてバイトを実行します。これらは異なるレイヤーで機能し、テキストを縮小してから転送中に圧縮するという組み合わせが最適です。
JSON をオンラインで縮小 - 無料
JSON を無料の JSON Minifier & Formatter に貼り付けて、実稼働用に縮小したり、デバッグ用に再度整形したりできます。進行中に検証が行われ、明確なエラーが表示されますが、何もアップロードされません。API データがデバイスの外に出ることはありません。