前端性能- 请求数据篇

@force2008 2017-11-01 07:26:03发表于 kaola-fed/blog 待归档


title: 前端性能- 请求数据篇
date: 2017-11-01

请求数量

  1. 现在的一个页面一般占用的请求有40~50个,页图片请求占有很大的比重,如果页面的请求在第一次初始化后被大面积的并发发出,会造成请求被挤占
  • 在http 1.1协议里,一个域名最多的并发请求为6,后面的请求都会被放到待发队列,导致图片加载延时,所以图片数量要进行懒加载控制
  • 在http2下,往一个域名上发多个请求要没有数量的限制,但因为h2是tcp的单通道,如果并发请求数多,也会造成请求的加载时间,首字节返回时间慢。所以我们计划把原来收敛到单个域名的优化,放开到三个域名。
    页面上初使化时需要对页面上的图片数量控制,做好懒加载的处理。

由于不能确定一个页面上首页会有多少的图片请求,所以现在我们的活动页上的图片数据在前20张图片不进行懒加载,其他图片都要进行懒加载。

图片的流量

解决的图片的数量问题,已经把移动端的流量减少很多,在移动端,

  • webp的图片最小质量最高,但仅android支持webp,而ios不支持web
  • png格式的图片裁剪不能减少流量
  • jpg可以大大减少图片大小,所以在做后面的图片上传的时候,如无必要用jpg的格式上传图片,如有特殊的透明需要,则只进行png的图片上传。

请求的延时发送

我们现在有两套活动责,

  • wap工程上的活动页
  • 搭建工程里的活动页
    这两套在数据上有差别是,wap工程有塞活动页的简单同步数据,造成的影响是html返回的大小由于附带了同步数据而造成页面请求变大,有的可能是80k。 无论有没有在页面上放同步数据都会在后面用异步数据把真实的数据取上来,放到页面上。由于页面很大,如果在初使化页面的模块时,直接发送异步请求,然后呈现到页面上,这个的一种方式是用户可能只浏览了前面几个模块,就退出了,但逻辑上把整个面页的模块数据都请求上来,导致初使化时做了很多对用户无用的功能。 优化的方案是,监测页面的滚动,同时用debounce进行降频,达到ios和安桌滚动时都不执行脚本的一致性。当页面滚动,监测模块,如果模块进入两屏高度的区域则进行加载,这种方式的好处时,如果用户滚动浏览,前面那个模块快浏览完时,在一屏高度外的下一个模块则去做加载; 还有一种方式是通过导航定位过来的模块,有“加载中”显示,并把该模块的数据加载回来。这样的一种请求延时模式,可以降低页面的请求量,最重要的是能把服务器的压力给降低。在这种情况页,模块加载中的高度最好是超过半屏,尽可能占有到一屏,如果一个模块占高50px,可能页面进来20个模块都被检测到在两屏内加载,那相当于没有做优化

http 2的优化

我们的测试结果是h2在中等数量的中大型请求大小,对于最后的加载时间有比较大的优化,小请求的加载时间缩减并不明显。