笔者在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 上。
页面的时间几乎都花在了渲染内容上面,经过分析该页面首次加载的接口来看,当时生产一次性加载了十个接口,在首次加载的时候,其实只有一个接口是必须加载的,另外九个接口都是查询条件的下拉框,前端也一并在初始化直接给加载了,导致了过多的不必要的数据也在该次页面刷新进行了初始化。
如何解决
前端:首次加载只加载查询的接口,并且只展示第一页所需的数据
后端:分页查询+展示业务所需字段,不需要的字段不返回
文章讨论了在遇到ContentDownload时间过长问题时的优化策略。通过分析,发现首次加载页面时不必要的接口请求导致了延迟。建议前端在首次加载时只请求必需的接口,并限制为第一页数据;后端应实施分页查询并只返回业务所需的字段,以减少数据传输量和渲染时间。
6万+

被折叠的 条评论
为什么被折叠?



