ajax 返回JSON数据,Size数据量大,传输时间长的解决方案

问题描述

有一个接口需要一次性返回数据, json数据的Size最大的时候,有将近1M的数据量,返回时间将近20s,是可忍,孰不可忍?
这个问题,是必须要解决的,估计除了我们自己,没人愿意等上20s了

解决方案

减少SIze主要是两个方面:resources(资源) 和 transferred(传输);

首先,当然是压缩,分为2个方面

1. 可压缩的字段内容,全部压缩
2. 减少不必要的字段

然而,resources(资源) 和 transferred(传输) 比没有明显的改观,
不过效果还是向好的方向发展了,减少了200K左右, 有点杯水车薪的感觉, 这时候脑袋疼不?

其次,既然resources(资源)已经到了不可压缩的地步,得换个思路了,不能钻牛角尖

我们来想办法减少transferred(传输)的体积

不知道, 你有没有想过 Document (Network >> Doc) 下的文件加载的很快,SIze 也不小, 是为什么?

反正我是想了这个问题, 解决方案也是源于此处

打开Headers对比发现,这两个地方是不一样的, text 类型进行了gzip压缩, json没有压缩

Content-Encoding: gzip
Content-Type: text/html; charset=UTF-8

Content-Type: application/json

解决方式

解决问题,需要善于动手的,

赶快把json文件 按照 text 类型返回试试

在服务器端, 设置 Content-Type: text/html; charset=UTF-8

果然, transferred(传输) SIze 明显减下来,约40K, 速度到了1s内了,

还有一种解决方案 设置 application/json 开启 gzip

Content-Encoding: gzip
Content-Type: application/json

总结

1. 在服务器端, 设置 Content-Type: text/html; charset=UTF-8
2. 在nginx 配置, 设置 application/json 开启 gzip

text/html和text/plain的区别

text 类型默认是文本, 没有格式, 默认是开启gzip压缩的;
json 类型是有格式数据, 默认不开启gzip压缩的, 有时候传输大小 > 文件大小;

text/html
浏览器在获取到这种文件时会自动调用html的解析器对文件进行相应的处理
text/htm 格式 到前端是 需要 反序列化 操作

text/plain
浏览器在获取到这种文件时并不会对其进行处理
text/plain 格式 到前端是不需要 反序列化 操作