针对后端接口返回近万条数据导致前端渲染慢的问题，采取前端分页与后端gzip压缩相结合的策略进行优化。前端根据分页参数请求指定数量数据，后端压缩响应内容，减少content download时间。虽然后端未采用gzip，但通过精简字段将数据量降至4M。优化后，页面初始化速度提升约一倍，但直接跳转到最后一页仍可能较慢。文章还提及了其他前端性能方案，如SSR，并邀请读者交流讨论。
从上图我们可以看到，造成接口时间长的主要原因是：ttfb 与 content download 的时间太长了，正常情况下，这哥俩的耗时应该是以毫秒为单位的。
不过，和后端同学沟通，目前的 TTFB 时间已经是优化过后的，本来是 十几秒 的时间，现在优化到 3秒左右，他那边目前没有好的再优化 TTFB 时间的方案。
那下一步就是优化 content download 的时间。
content download ：收到响应的第一个字节，到接收完最后一个字节的时间，就是下载时间。即 下载 HTTP 响应的时间（包含头部和响应体）
通过看接口返回详情，我们可以很清晰的了解到：这个接口响应的资源很大，大概有7M（估算的，因为优化字段后资源大小仍然有 4M 左右，当时忘了看之前的资源大小）
看到这里，我们就能意识到：原来是接口返回的数据资源太大，导致下载时间长。 那么，我们该如何优化数据资源呢？
网上出现的比较多的是这两种方案：
- 1、移除重复脚本，精简和压缩代码，比如借助自动化构建工具 grunt、gulp 等。（不太熟悉，加上时间紧迫，就没了解）
- 2、压缩响应内容，服务器端启动 gzip 压缩，可以减少下载时间。
当时我向后端同学推荐
最低0.47元/天 解锁文章
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
