美文网首页
优化列表数据显示卡顿

优化列表数据显示卡顿

作者: 晴窗细语 | 来源:发表于2020-09-04 16:38 被阅读0次

问题

环境
  • vue : 2.6.10
  • element-ui : 2.13.0
  • koa : 2.7.0
描述

列表数据大概300条左右,请求一次性请求所有数据,在操作之后到页面上显示表格数据大概有3秒卡顿,想到用chrome performance面板进行分析。
对performance运用比较陌生,看了两篇performance调试文章,链接贴出来
前端性能测试
全新Chrome Devtool Performance使用指南

结果如下:


原网页性能分析

可以看到,从界面上点击显示列表数据到界面上有数据显示出来的总耗时为:


总耗时

其中优化主要点在于:

  • js脚本执行时间过长(1197ms)
  • 界面渲染时间过长(682ms)
    空闲时间(313ms)相较于这两者来说不算太长,可以先暂时不用考虑优化

针对以上两点进行分析,js脚本执行时间太长可能是因为数据量大导致(只是猜测,从performance面板进不到js文件里),界面渲染时间过长是因为需要一次性渲染近300条数据,dom操作频繁导致。

由此想到将数据分片进行展示,原代码获取列表数据只发了一次请求获取全部数据,可以考虑首先获取少量数据进行渲染,填充当前界面显示区域,再获取全部数据(此处也可获取较多条数的数据,譬如1000条,缓存到前端,等到缓存区数据不够是再请求获取多条数据,由于数据量不够大,故此处直接获取全部数据)。

验证

为验证以上方法,首先请求20条数据(分页设定每页显示20条数据),用performance对从操作到数据显示的结果为:


只发一条请求,请求少量数据

总耗时:


总耗时

可以看到,当请求数据量少时,卡顿时间明显减少,js脚本执行时间与render渲染时间明显下降。

在此之后再请求所有数据,前端进行数据缓存,分页后每翻一页从缓存里取数据渲染界面,发两次请求从操作到数据显示结果为:


两次请求

总耗时:


总耗时

相较于只发一次请求耗时略有增加,主要体现在js脚本执行时间与空闲时间的增减,但相较于原网页请求耗时仍有明显减少。

总结

其实以前做的请求多条数据都是用这种方式实现的,发两次请求,一次用于显示,一次用于缓存数据,只是一直没从性能的角度进行分析,对performance面板的运用也不太熟,之后需要进行学习。

但本次的优化之后虽然卡顿时间确有下降,但是可以从上面总耗时图中看到,空闲时间仍有很多(265ms),此处也是有待进一步优化之处。

相关文章

  • 优化列表数据显示卡顿

    问题 环境 vue : 2.6.10 element-ui : 2.13.0 koa : 2.7.0 描述 列表数...

  • Runloop优化列表滑动卡顿

    Runloop优化列表滑动卡顿

  • Android列表优化,可以参考参考

    OrderList 优化列表,大量数据也不会造成卡顿,代码简洁可读性高 使用AutoSwipeRefreshLay...

  • iOS两种网络图片加载

    今天遇到TableView滚动显示卡顿,所以就对cell进行优化,但是发现没有完全解决, 所以就对cell里面的数...

  • 双屏显示卡顿

    双屏显示卡顿,27英寸2k分辨率的HKC。之前是GTX970的显卡,烧了后换了GTX 1050TI。刚开始还很好,...

  • 2019-03-01.24(大数据量性能优化)

    大数据量性能优化: 1 . 列表优化 大型表单优化 表格优化 我们在修改数据的时候,视图就会有响应的变化,视图会去...

  • 列表类控件卡顿优化

    1、使用ConstraintLayout减少布局层级。 2、可以的话,设置RecyclerView布局等高,然后设...

  • iOS 列表卡顿优化记录

    首先介绍出现问题场景:实时聊天的群聊列表,消息过来会进行频繁刷新,在压力测试下,大约0.5s会刷新一次。列表中包含...

  • 十. 其它优化

    一. 列表卡顿优化 常规方案 convertView复用、使用ViewHolder 耗时任务异步处理 布局相关 减...

  • 关于IOS优化

    最近看了很多关于IOS优化的文章,现在大概来总结一下. 列表优化: 卡顿产生的原因 首先我们要了解优化任务的底层运...

网友评论

      本文标题:优化列表数据显示卡顿

      本文链接:https://www.haomeiwen.com/subject/ltgzsktx.html