我們知道，JSON作為一種輕量級的資料交換格式，現在被廣泛應用，特別是在API層，返回資料格式基本上都是JSON。但是，JSON字串如果過長，那在網路傳輸中也存在耗時的，站在效能角度我們需要合理最佳化JSON。

1、伺服器端開啟GZip壓縮

主流的服務端都支援GZip壓縮，對於一般的純文字內容GZip壓縮率在35%以上，這樣做的好處也很明顯：

減少JSON輸出大小，網路傳輸速度更快；

節省頻寬。

2、鍵名縮短

對於結果集而言，資料都是查詢迴圈輸出的，所以當我們把鍵名縮短也變相壓縮了JSON文字長度。比如原本的 {"name":"張三"} 我們可以寫為 {"a":"張三"}

3、JSON中的中文避免被轉為Unicode編碼

現在也有不少人喜歡將JSON中的漢字轉為Unicode編碼，此時JSON文字內容就會變得很長，如果避免漢字轉碼，可以控制文字長度。

1，開啟gzip，壓縮率很高，即便是很長的文字，在網路中傳輸量也很小 。

2，不建議分次請求，除非是業務需要。連線次數過多，加大了併發的壓力。

4，如果有可能，考慮提前預讀你可以這樣，在一個隱藏的 iframe 裡面請求伺服器，返回值是這樣的： <script> parent.notifyDataArrive(YOURS_JSON_DATA); </script>

現在主流的網路請求中都採用JSON作為其資料互動格式，這主要是因為JSON有以下優勢：

資料格式簡單，易於讀寫，格式都是壓縮的，佔用頻寬小；

易於解析，客戶端JS很容易JSON資料進行解析和編輯；

支援大多數後端語言，大大簡化了服務端和前端互動時的程式碼開發量，且易於維護；

但如果在開發過程中，把很長很大的JSON資料在前後端傳輸，那就說明設計工作沒做好，應該儘量避免這種資料傳輸，但也可以從下面幾個方面進行下最佳化：

最佳化json資料的key-value的長度，儘量簡潔易懂即可；

非同步分批載入，建設大資料量造成前端頁面卡死；

前端增加銷燬機制，可以一邊載入，一邊銷燬；

使用解析和壓縮效能高的JSON解析工具；

在 Skylake 處理器上，各種解析器解析同一個大資料量的JSON檔案的速度（以 GB/s 為單位）如下所示：

作為JSON這個規範，要在大小上最佳化，空間很有限，所獲得的收益也很低，但是也不是沒有最佳化空間，可以從下面幾個角度入手：

1.最佳化傳輸大小，開啟伺服器的gzip壓縮即可，但會略微佔用更多CPU。

2.使用更短的key，為了可讀性，一般不建議這麼做。

3.開啟重複引用和迴圈引用。Java實現的一些JSON庫支援重複和迴圈引用，可以縮小JSON文字大小。比如在傳輸的資料中出現相同的物件時，fastjson預設開啟引用檢測將相同的物件寫成引用{"$ref":".."}的形式.

如圖所示：

對於第二個LoanOrder 02，fastjson僅僅解析並載入其貸款訂單部分的資料，對於“$ref”所指向的 Loaner貸款人的資料，fastjson會因為“開啟了fastJson的‘迴圈引用檢測’機制”而不去載入該貸款人資料。

這樣可以大大減少重複物件的處理，但是問題是大部分JSON庫包括瀏覽器客戶端並不支援這個特性。

4.如果又要體積小，又要相容性好，建議使用體積更小的序列化方式，比如msgpack.

MessagePack is an efficient binary serialization format. It lets you exchange data among multiple languages like JSON. But it"s faster and smaller.

不僅體積小，而且速度快，比JSON快多了。

下面是JSON、Protobuf、Thrift、MessagePack 序列化大小對比，體積都比JSON要小。