氾濫的文字
我們知道，JSON作為一種輕量級的數據交換格式，現在被廣泛應用，特別是在API層，返回數據格式基本上都是JSON。但是，JSON字符串如果過長，那在網絡傳輸中也存在耗時的，站在性能角度我們需要合理優化JSON。
JSON優化建議
1、服務器端開啟GZip壓縮
主流的服務端都支持GZip壓縮，對於一般的純文本內容GZip壓縮率在35%以上，這樣做的好處也很明顯：
減少JSON輸出大小，網絡傳輸速度更快；
節省帶寬。
2、鍵名縮短
對於結果集而言，數據都是查詢循環輸出的，所以當我們把鍵名縮短也變相壓縮了JSON文本長度。比如原本的 {"name":"張三"} 我們可以寫為 {"a":"張三"}
3、JSON中的中文避免被轉為Unicode編碼
現在也有不少人喜歡將JSON中的漢字轉為Unicode編碼，此時JSON文本內容就會變得很長，如果避免漢字轉碼，可以控制文本長度。
以上就是我的觀點，對於這個問題大家是怎麼看待的呢？歡迎在下方評論區交流 ~ 我是科技領域創作者，十年互聯網從業經驗，歡迎關注我瞭解更多科技知識！網絡圈
作為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要小。
互聯網活化石
現在主流的網絡請求中都採用JSON作為其數據交互格式，這主要是因為JSON有以下優勢：
數據格式簡單，易於讀寫，格式都是壓縮的，佔用帶寬小；
易於解析，客戶端JS很容易JSON數據進行解析和編輯；
支持大多數後端語言，大大簡化了服務端和前端交互時的代碼開發量，且易於維護；
但如果在開發過程中，把很長很大的JSON數據在前後端傳輸，那就說明設計工作沒做好，應該儘量避免這種數據傳輸，但也可以從下面幾個方面進行下優化：
優化json數據的key-value的長度，儘量簡潔易懂即可；
異步分批加載，建設大數據量造成前端頁面卡死；
前端增加銷燬機制，可以一邊加載，一邊銷燬；
使用解析和壓縮性能高的JSON解析工具；
在 Skylake 處理器上，各種解析器解析同一個大數據量的JSON文件的速度（以 GB/s 為單位）如下所示：
碼農胖哥
1，開啟gzip，壓縮率很高，即便是很長的文本，在網絡中傳輸量也很小 。
2，不建議分次請求，除非是業務需要。連接次數過多，加大了併發的壓力。
3，提醒用戶點擊的做法可以通過按鈕反饋或loading條來做。
4，如果有可能，考慮提前預讀你可以這樣，在一個隱藏的 iframe 裡面請求服務器，返回值是這樣的：
