问题描述
最近尝试优化大数据接口的请求速度（涉及大量的点位数据，5M-10M） java处理提速，接口数据精简这些当然交给后端大哥处理，前端主要思考能否通过压缩的方式提升接口下载速度。
调研流程
- 首先直接起node服务器, 用json模拟一个5M左右的请求数据，time图如下：
压缩主要也是提升download速度，大概400ms，在实际项目中可能会有更大堵塞影响，值得尝试。
接下来使用node的zlib.createGzip进行压缩，再次请求，time图如下：
有点出乎意料，可以看到传输数据已经被压缩到200k了，但是download时间还有380ms
- 接口来在network slow情况下看看效果：
开启压缩：
关闭压缩：
emmm。。好吧，说明压缩在纯粹下载时间这块还是有优化效果的，但是为什么在常常情况下请求速度没有没有明显提升呢？
- 因为node对GZip对象的描述过少，没有找到有效信息，监听下readStream的data事件，代码如下：
let startTime = new Date().getTime();
readStream.on("data", (data) => {
let endTime = new Date().getTime();
console.log(i++, endTime - startTime);
startTime = endTime;
})
压缩和非压缩的输出结果如下：
非压缩：
（从0开始一共78次）
压缩：
从上面两张图的对比可以分析出，虽然压缩过数据少了很多，但是每次的传输时间都变长了。 看起来让服务器做gzip压缩还是比较耗时的（怪不得前端的包得再打包时压缩，nginx配置gzip_static on），对此node官网也有说明： 这点node官网也有描述：
关键点备注
这里纠正我之前的一个错误观点：流传输的时候应该是边压缩边传输的，并不是整个数据压缩好再开始传输的。
- 如果是压缩好再一次传输的，在chrome的time图中，应该是wait for server response时间长，而不是download
- 如果是压缩好再一次传输的，不会每个chunk的时间间隔都比普通传输长这么久。 所以我认为chrome在收到server的第一个response字节的后续时间，都计算再download时间中，而不是存粹的下载时间
我没有找到能印证我观点的文档，但是可以贴个gif图印证上述观点：
可以看到，我每次打断点耽误的时间，都计算再download中
最终结论
正常网速下，在接口传输的过程中进行gzip压缩并不能有效提升接口速度，因为gzip压缩的耗时也是一个瓶颈
2023/2/5更新 这个压缩速度和gzip压缩等级有关，可能可以调整成一个比较合适的值（网上推荐为4）
