知识分享

移动网站H5前端性能优化指南

发表日期:2015/7/23 15:59:11 文章编辑: 浏览次数:1946


移动H5前端性能优化指南[托尼托尼研究所]

概述

1. PC优化手段在Mobile侧同样适用
2. 在Mobile侧我们提出三秒种渲染完成首屏指标
3. 基于第二点,首屏加载3秒完成或使用Loading
4. 基于联通3G网络平均338KB/s(2.71Mb/s),所以首屏资源不应超过1014KB
5. Mobile侧因手机配置原因,除加载外渲染速度也是优化重点
6. 基于第五点,要合理处理代码减少渲染损耗
7. 基于第二、第五点,所有影响首屏加载和渲染的代码应在处理逻辑中后置
8. 加载完成后用户交互使用时也需注意性能
优化指南

[加载优化]

加载过程是最为耗时的过程,可能会占到总耗时的80%时间,因此是优化的重点

· 减少HTTP请求
因为手机浏览器同时响应请求为4个请求(Android支持4个,iOS 5后可支持6个),所以要尽量减少页面的请求数,首次加载同时请求数不能超过4个
a) 合并CSS、JavaScript
b) 合并小图片,使用雪碧图

· 缓存
使用缓存可以减少向服务器的请求数,节省加载时间,所以所有静态资源都要在服务器端设置缓存,并且尽量使用长Cache(长Cache资源的更新可使用时间戳)
a) 缓存一切可缓存的资源
b) 使用长Cache(使用时间戳更新Cache)
c) 使用外联式引用CSS、JavaScript

· 压缩HTML、CSS、JavaScript
减少资源大小可以加快网页显示速度,所以要对HTML、CSS、JavaScript等进行代码压缩,并在服务器端设置GZip
a) 压缩(例如,多余的空格、换行符和缩进)
b) 启用GZip

· 无阻塞
写在HTML头部的JavaScript(无异步),和写在HTML标签中的Style会阻塞页面的渲染,因此CSS放在页面头部并使用Link方式引入,避免在HTML标签中写Style,JavaScript放在页面尾

部或使用异步方式加载

· 使用首屏加载
首屏的快速显示,可以大大提升用户对页面速度的感知,因此应尽量针对首屏的快速显示做优化

· 按需加载
将不影响首屏的资源和当前屏幕资源不用的资源放到用户需要时才加载,可以大大提升重要资源的显示速度和降低总体流量
PS:按需加载会导致大量重绘,影响渲染性能
a) LazyLoad
b) 滚屏加载
c) 通过Media Query加载

· 预加载
大型重资源页面(如游戏)可使用增加Loading的方法,资源加载完成后再显示页面。但Loading时间过长,会造成用户流失
对用户行为分析,可以在当前页加载下一页资源,提升速度
a) 可感知Loading(如进入空间游戏的Loading)
b) 不可感知的Loading(如提前加载下一页)

· 压缩图片
图片是最占流量的资源,因此尽量避免使用他,使用时选择最合适的格式(实现需求的前提下,以大小判断),合适的大小,然后使用智图压缩,同时在代码中用Srcset来按需显示
PS:过度压缩图片大小影响图片显示效果
a) 使用智图( http://zhitu.tencent.com/ )
b) 使用其它方式代替图片(1. 使用CSS3 2. 使用SVG 3. 使用IconFont)
c) 使用Srcset
d) 选择合适的图片(1. webP优于JPG 2. PNG8优于GIF)
e) 选择合适的大小(1. 首次加载不大于1014KB 2. 不宽于640(基于手机屏幕一般宽度))

· 减少Cookie
Cookie会影响加载速度,所以静态资源域名不使用Cookie

· 避免重定向
重定向会影响加载速度,所以在服务器正确设置避免重定向

· 异步加载第三方资源
第三方资源不可控会影响页面的加载和显示,因此要异步加载第三方资源

[脚本执行优化]

脚本处理不当会阻塞页面加载、渲染,因此在使用时需当注意

· CSS写在头部,JavaScript写在尾部或异步

· 避免图片和iFrame等的空Src
空Src会重新加载当前页面,影响速度和效率

· 尽量避免重设图片大小
重设图片大小是指在页面、CSS、JavaScript等中多次重置图片大小,多次重设图片大小会引发图片的多次重绘,影响性能

· 图片尽量避免使用DataURL
DataURL图片没有使用图片的压缩算法文件会变大,并且要解码后再渲染,加载慢耗时长

[CSS优化]

· 尽量避免写在HTML标签中写Style属性

· 避免CSS表达式
CSS表达式的执行需跳出CSS树的渲染,因此请避免CSS表达式

· 移除空的CSS规则
空的CSS规则增加了CSS文件的大小,且影响CSS树的执行,所以需移除空的CSS规则

· 正确使用Display的属性
Display属性会影响页面的渲染,因此请合理使用
a) display:inline后不应该再使用width、height、margin、padding以及float
b) display:inline-block后不应该再使用float
c) display:block后不应该再使用vertical-align
d) display:table-*后不应该再使用margin或者float

· 不滥用Float
Float在渲染时计算量比较大,尽量减少使用

· 不滥用Web字体
Web字体需要下载,解析,重绘当前页面,尽量减少使用

· 不声明过多的Font-size
过多的Font-size引发CSS树的效率

· 值为0时不需要任何单位
为了浏览器的兼容性和性能,值为0时不要带单位

· 标准化各种浏览器前缀
a) 无前缀应放在最后
b) CSS动画只用 (-webkit- 无前缀)两种即可
c) 其它前缀为 -webkit- -moz- -ms- 无前缀 四种,(-o-Opera浏览器改用blink内核,所以淘汰)

· 避免让选择符看起来像正则表达式
高级选择器执行耗时长且不易读懂,避免使用

[JavaScript执行优化]

· 减少重绘和回流
a) 避免不必要的Dom操作
b) 尽量改变Class而不是Style,使用classList代替className
c) 避免使用document.write
d) 减少drawImage

· 缓存Dom选择与计算
每次Dom选择都要计算,缓存他

· 缓存列表.length
每次.length都要计算,用一个变量保存这个值

· 尽量使用事件代理,避免批量绑定事件

· 尽量使用ID选择器
ID选择器是最快的

· TOUCH事件优化
使用touchstart、touchend代替click,因快影响速度快。但应注意Touch响应过快,易引发误操作

[渲染优化]

· HTML使用Viewport
Viewport可以加速页面的渲染,请使用以下代码

· 减少Dom节点
Dom节点太多影响页面的渲染,应尽量减少Dom节点

· 动画优化
a) 尽量使用CSS3动画
b) 合理使用requestAnimationFrame动画代替setTimeout
c) 适当使用Canvas动画 5个元素以内使用css动画,5个以上使用Canvas动画(iOS8可使用webGL)

· 高频事件优化
Touchmove、Scroll 事件可导致多次渲染
a) 使用requestAnimationFrame监听帧变化,使得在正确的时间进行渲染
b) 增加响应变化的时间间隔,减少重绘次数

· GPU加速
CSS中以下属性(CSS3 transitions、CSS3 3D transforms、Opacity、Canvas、WebGL、Video)来触发GPU渲染,请合理使用
PS:过渡使用会引发手机过耗电增加

为什么优化?

随着移动互联网的发展,我们越发要关注移动页面的性能优化,今天跟大家谈谈这方面的事情。

     首先,为什么要最移动页面进行优化?

     纵观目前移动网络的现状,

   

          移动页面布局越来越复杂,效果越来越炫,直接导致了文件越来越大,下载和运行速度越来越低,而速度低会造成不良影响,据统计:

      

          71%的用户期望移动页面跟pc页面一样快,74%的用户能容忍的响应时间为5秒,所以我们必须保证移动端页面有足够的速度。

      移动页面的速度跟三个因素有关,分别是:移动网络带宽速度,设备性能(CPU,GPU,浏览器),页面本身。

      目前主流的移动网络制式为3g

      

      今年,我们还看到了4g网络制式在快速发展,这再一次提升了移动页面的加载速度;

      而移动设备本身,截止到目前,以iphong6三星Note4等设备为首,智能设备已经变得比以往屏幕更大,CPU、GPU、内存更靠谱

      

      而与其同时,浏览器产商也为提升页面的速度做出了不可磨灭的努力,这里大家可以看一个视频(http://www.iqiyi.com/w_19rsgfld99.html

      

      网络制式供应商,手机制造商,浏览器产商如此给力,我们呢?我们能做什么。

      我们能做得是对移动端页面本身优化,这也是我们专业价值的体现,所以我们必须做移动端页面性能优化。

 

      该怎么做移动端页面优化呢?

      在说这个前,要提一下pc常用的优化手段:

 

          代码优化(css、html、js优化)

          减少HTTP请求(雪碧图,文件合并…)

          减少DOM节点

          无阻塞(内联CSS,JS置后…)

          缓存

 

          ...

      这些手段大部分适用于移动端,这都是一些耳熟能详的手段,今天这里就讲了,有兴趣可以参考PDI课程《网站性能优化》。

      今天要讲的主要是一些适用于移动端的优化手段,现在进入正题。

      首先我们得关注一下一个页面从开始到呈现完毕需要经历什么阶段,主要有四个阶段:

       

      每个阶段的主要工作如上图所示,而我们的优化目标是:

      下面我们来针对上面的几个阶段细说一下都有哪些优化手段。

      首先,来看看加载中有哪些优化手段:

      1. 预加载

      预加载方式有两种:

      A.显性加载

      

      类似这种用户能明显感知的,我把它称为“显性加载”,互动页面都建议加上这种加载方式,它一方面能增加页面的趣味性,另一方面能让后续页面体验更流畅

      B.隐性加载

     这种在加载第一张图片的时候已经预先加载了第二张图片,从而使得页面体验更流畅的方式,我把它称为隐性加载,这种方式的好处是节省流量之余又能使得体验增强。

     2.    按需加载

     按需加载是不可或缺的优化手段,主要有以下两种方式:

      

      对于这种方式,在首屏加载的时候把首屏的内容加载尽量,而位于首屏之外的元素都只在出现在首屏时才加载,很大程度地节省了流量,提升了首次加载时间。

      

      这种叫响应式加载方式,意思是利用js或者css判断分辨率,从而选择不同尺寸的图片进行引入,这种的好处显而易见,同样可以加快加载速度和节省流量。

      3.    压缩图片

      对于压缩图片,首先要提的是jpg文件:

      

      对于移动端的Jpg文件,有这样的结论:

           a.使用大尺寸大有损压缩比的jpg

           b.使用jpegtran进行无损压缩

      而对于png有以下结论:

           a.多彩图片使用png24

           b.低彩图片使用png8

           c.推荐使用pngquant

 

      4.尽量避免重定向

      为什么要尽量避免重定向呢?因为如图:

      

      这是一个同一网速下的测试结果,重定向之所以会比较慢,是因为它重复了域名查找,tcp链接,发送请求。

      5. 使用其他方式代替图片

      有两种方式,第一种是:依靠css3绘制图片

      

      第二种:使用iconfont代替图片

      

      但iconfont不一定比图片好,这里做了个实验:

      

      对于大图片,iconfont并不比雪碧图好,建议单侧小尺寸图标才使用iconfont.

 

      然后,针对脚本执行中有哪些优化手段,这里只提两点:

      1.尽量避免DataURI

      DataUri在移动端并不如它在pc端吃香,因为:

      

      经测试,DataURI要比简单的外链资源慢6倍,生成的代码文件相对图片文件体积没有减少反而增大,而且浏览器在对这种base64解码过程中需要消耗内存和cpu,这个在移动端坏处特别明显。

      2.点击事件优化

      在移动端请适当使用touchstart,touchend,touch等事件代替延迟比较大的click事件。Click之所以慢是因为mousedown导致的:

 

      然后,针对渲染阶段中有哪些优化手段,这里也只提两点:

      1. 动画优化

            a) 尽量使用css3动画

            优点:

                不占用js主线程

                可利用硬件加速

                浏览器可对动画做优化

             缺点:

                不支持中间状态监听

            b) 适当使用canvas动画

            优点:

                可规避渲染树的计算渲染更快

            缺点:

                开发成本高

                维护较麻烦

            通过对css3动画和canvas动画对比:

      

            得到结论:5个元素以内使用css3动画,5个以上使用canvas动画。

            c) 合理使用RAF(requestAnimationFrame)

            优点:

                能解决脚本问题引起的丢帧,卡顿问题

                支持中间状态监听

            缺点:

                兼容问题

            

            通过RAF动画与settimeout动画对比:

            

            得到结论:不需要兼容android 4.3浏览器的情况下,请使用RAF制作脚本动画

      2. 高频事件优化

      

      类似touchmove,scroll这类的事件可导致多次渲染,对于这种事件可以通过以下手段进行优化:

      1.使用requestAnimationFrame监听帧变化,使得在正确的时间进行渲染

      2.增加响应变化的时间间隔,减少重绘次数。

 

      最后,针对合成/绘制只提一个优化手段:

        GPU加速

            触发GPU加速的方式有:

                 CSS3 transitions

                      CSS3 3D transforms

                      WebGL 3D 绘制

                      Video

                      ...

            使用GPU加速前有对比实验:

            

      GPU加速实际上是大幅减少了合成/绘制时间,从而大大地提高了页面速度,但GPU加速有自己的缺点:

      过多的GPU层会带来性能开销,主要原因是使用GPU加速其实是利用了GPU层的缓存,让渲染资源可以重复使用,所以一旦层多了,缓存增大,就会引起别的性能问题。

      

     总结

              

      本文针对页面呈现的四个阶段提出了比较典型的优化手段,到最后,再提醒读者一下:其实优化是双刃剑。

       按需加载提升速度,但可能导致大量重绘;

       Touch响应快,但很多场景不适合;

       GPU加速效率高,但内存开销大等等

       Loading会让整体体验流畅,但容易造成用户流失

       图片压缩让带宽成本降低,但可能会导致视觉效果变差

      类似这样的矛盾点还有很多,请结合业务按照实际情况进行优化。

将文章分享到..
相关新闻
全新新闻
随机新闻
最新网站设计案例
Hi,我来帮您!