后端接口返回近万条数据，前端渲染缓慢，content Download 时间长的优化方案

本文介绍: 按照上面的方法，页面初始化的时候确实比之前快了很多，大概有一倍左右。不过直接跳转到最后一页，接口还是会有些缓慢。不过，对于上万条数据，也很少有人会直接跳转到最后一页进行搜索，毕竟上面也是有筛选条件可以进行筛选的。总而言之，也算是完成了性能优化。前端性能方案有很多种，比如 SSR，只是目前暂时还未了解，以后慢慢掌握。本篇文章介绍的方法只是其中比较特殊的一种，正常来说，我内心还是比较偏向于 gzip 压缩处理的。

性能优化，是前端绕过不去的一道门槛，甚是重要。最近一年，也很少有机会在项目中进行前端性能优化，一直在忙于业务开发。

最近终于是来了机会，遇到了这样的场景，心里也甚是激动，写个随笔记录下性能优化的过程及逻辑，有需要的可以参考下。

后端接口一下子返回了 9000 多条数据，而且不带分页参数，全部返回了。

说实话，刚联调接口的时候我也有点懵，也是第一次遇到这样的情况，于是询问后端同学为什么要这样。他回复我说是因为特殊需要，后端调的是大数据的接口，拿的是大数据团队的数据，技术方案评审时，要求数据不落表（我也不太懂后端这是什么意思）

毫无疑问，将近一万条数据在前端渲染，百分之百的会造成卡顿。而且接口调用时间也会很长。

在这里插入图片描述

前端分页逻辑其实很简单：有分页的组件，拿来用就行。使用数组的 slice 方法，对总数据进行分割，跳转到不同页时，根据 pageSize 和 limit 两个参数分割数组。

// 前端分页逻辑
/**
 * 该方法用于前端分页
 * @param limit         每页条数
 * @param currentPage   当前页
 * @param tableData     总数据
 */
  queryByPage(limit, currentPage, tableData) {
     return tableData.slice((currentPage - 1) * limit, currentPage * limit)
  }

content download ：收到响应的第一个字节，到接收完最后一个字节的时间，就是下载时间。即 下载 HTTP 响应的时间（包含头部和响应体）

定义一个变量 clickedMaxPage，默认值为 1，用于储存当前页的页码点击的最大值。

// 当前页发生变化
// page: 当前页码
currentPageChange(page) {
	// 如果 page > this.clickedMaxPage 调用接口，否则不需要
	if (page > this.clickedMaxPage) {
		this.clickedMaxPage = page
		// 调用接口
		return
	}
	// page <= this.clickedMaxPage
	// 调用前端分页方法
}

// 每页条数发生变化
// size: 当前每页条数
sizeChangeHandle(size) {
/**
 * 需要判断当前总条数是否大于分页条数，
 * 如果大于，正常取余判断, 余数不为0，clickedMaxPage = 商 + 1，否则 clickedMaxPage = 商
 * 如果小于等于 clickedMaxPage = 1
 */
 if (this.data.length > size) {
        // 获取余数
        const remainder = this.data.length % size
        // 获取商数
        const result = parseInt((this.data.length / size) + '')
        if (remainder === 0) {
          this.clickedMaxPage = result
        } else {
          this.clickedMaxPage = result + 1
        }
      } else {
        this.clickedMaxPage = 1
      }
      // 前端分页逻辑
}