今天和前端同学联调时遇到一个问题，前端同学反馈其中一个接口响应过慢，于是我就通过后台实际操作了一下，看下耗时。具体情况是这样的
观察了一下，请求面板耗时分析了一下参数意义：
1、Request sent ：发起请求的时间，0.26ms
2、Waiting(TTFB) ：请求发出后，到收到响应的第一个字节所花费的时间(Time To First Byte)，发送请求完毕到接收请求开始的时间；通常是耗费时间最长的。从发送请求到收到服务器响应的第一字节之间的时间，受到线路、服务器距离等因素的影响。
注意：网页重定向越多，TTFB越高，所以要减少重定向
3、Content Download： 获取Response响应数据的时间花费
对参数的意义网上有很多详细专业的解释，这里我就不做过多解释了，直接进入主题。
看了耗时，request sent和waiting(TTFB)都没问题，200ms左右。响应耗时主要消耗在了content download上。
根据字面意思会发现其实是后端处理很快，但是在获取response响应的数据时，浏览器花费了大量的时间。我的第一反应是返回的数据量过大了，接口在返回数据时浏览器下载或者说传输数据过程中消耗了时间。
由于这只是我的经验直觉做出的判断，所以不是很确定还需要辩证，来确定是数据量返回过大导致的问题。
网上很多同学说是JS有过多的处理或者很多页面上渲染逻辑导致，所以我在浏览器中直接输入接口地址观察了一下。这里有人说可以用postman，postman确实是响应耗时过长，但太过于笼统，只能看到总耗时，却不能向浏览器那样有相对详细的参数详情。所以还是用浏览器试了一下。结果如下
结果还是一样，在没有js渲染的情况下，直接请求耗时问题依然存在，所以可以排除是js导致的问题。那么问题很明显了，就是返回的数据量的问题。
但是又有一个疑问，数据量到底有多大，会导致传输耗时过高呢，我把整个接口响应的数据复制了下来，放在了一个文本文件中，看了下大小
保存前
保存后（这里说明一下，接口响应的数据都是纯json）
好家伙，请求100条的数据量竟然有10MB大小。根据公司的网络带宽每秒下载有1MB已经不错了，10MB的数据量就需要传输10s左右，怪不得接口会这么慢。
后端处理其实很快，几百毫秒就可以了，主要是响应后，浏览器加载数据就需要10s才会给到前端JS来处理渲染。到这里很明确了，优化的点就是精简响应数据，把没有用的字段统统删掉，经过精简后接口响应数据量大小几百kb，接口整体响应1s以内，优化完成。
这个优化其实很简单，但是也是平时比较容易忽略的细节。
最后，接口的优化还是要具体问题具体分析。
