泛滥的文字
现在主流的网络请求中都采用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要小。
互联网活化石
我们知道，JSON作为一种轻量级的数据交换格式，现在被广泛应用，特别是在API层，返回数据格式基本上都是JSON。但是，JSON字符串如果过长，那在网络传输中也存在耗时的，站在性能角度我们需要合理优化JSON。
JSON优化建议
1、服务器端开启GZip压缩
主流的服务端都支持GZip压缩，对于一般的纯文本内容GZip压缩率在35%以上，这样做的好处也很明显：
减少JSON输出大小，网络传输速度更快；
节省带宽。
2、键名缩短
对于结果集而言，数据都是查询循环输出的，所以当我们把键名缩短也变相压缩了JSON文本长度。比如原本的 {"name":"张三"} 我们可以写为 {"a":"张三"}
3、JSON中的中文避免被转为Unicode编码
现在也有不少人喜欢将JSON中的汉字转为Unicode编码，此时JSON文本内容就会变得很长，如果避免汉字转码，可以控制文本长度。
以上就是我的观点，对于这个问题大家是怎么看待的呢？欢迎在下方评论区交流 ~ 我是科技领域创作者，十年互联网从业经验，欢迎关注我了解更多科技知识！网络圈
1，开启gzip，压缩率很高，即便是很长的文本，在网络中传输量也很小 。
2，不建议分次请求，除非是业务需要。连接次数过多，加大了并发的压力。
3，提醒用户点击的做法可以通过按钮反馈或loading条来做。
4，如果有可能，考虑提前预读你可以这样，在一个隐藏的 iframe 里面请求服务器，返回值是这样的：
