Timing 中 Content Download 耗时过长问题如何解决

笔者在pgsql创建索引的优化中有写到基于数据库查询的优化，但实际在sql优化之前，通过f12开发者模式发现查询的接口Timing中Content Download时间过长，实际的接口响应只有200ms，但是Content Download长达3s多，在网上查阅资料，分析了一下页面加载时间，参考网上一位老哥博客地址：https://www.cnblogs.com/amyzhu/p/13125463.html（这篇博客主要是介绍浏览器上面一些参数是干嘛的）

由于生产是禁止外网传播，笔者以google浏览器为例，讲述一下大概的优化思路：

想必大家在开发中经常用到这个界面，F12打开开发者模式，看了耗时，当时生产的Content Download是3s多，接口的响应时间只有200多毫秒，导致整个页面处于加载的时间过长，request sent 和 waiting都没问题，响应耗时主要消耗在了 content download 上。

页面的时间几乎都花在了渲染内容上面，经过分析该页面首次加载的接口来看，当时生产一次性加载了十个接口，在首次加载的时候，其实只有一个接口是必须加载的，另外九个接口都是查询条件的下拉框，前端也一并在初始化直接给加载了，导致了过多的不必要的数据也在该次页面刷新进行了初始化。

如何解决

前端：首次加载只加载查询的接口，并且只展示第一页所需的数据

后端：分页查询+展示业务所需字段，不需要的字段不返回