web前端性能优化

来源:互联网 发布:空间数据库吴信才 编辑:程序博客网 时间:2024/06/05 22:35

作为一个前端工程师,性能优化是很有必要的。好的用户体验能一定程度上决定产品的命运。而提升用户体验有很多方面,比如,界面设计,操作设计,网页加载性能等。。。
提升性能我们可以从如下几个方面考虑:

减少http请求合理设置 HTTP缓存

在动态网页中,我们难免会与后台服务器交互,减少http请求的数目在性能提升上是十分明显的。比如我们可以:

  1. 简化步骤,将请求数据尽可能的封装在少的接口中,当然这是不破坏程序可扩展性及健壮性的情况下。
  2. 合并压缩css与JS等文件,图片较多的页面也可以使用 lazyLoad 等技术进行优化。
  3. 为不常变化的请求数据设置http缓存

合理放置CSS与JS的位置

浏览器会在下载完成全部CSS之后才对整个页面进行渲染,因此最好的做法是将CSS放在页面最上面,让浏览器尽快下载CSS。如果将 CSS放在其他地方比如 BODY中,则浏览器有可能还未下载和解析到 CSS就已经开始渲染页面了,这就导致页面由无 CSS状态跳转到 CSS状态,用户体验比较糟糕,所以可以考虑将CSS放在HEAD中。
Javascript则相反,浏览器在加载javascript后立即执行,有可能会阻塞整个页面,造成页面显示缓慢,因此javascript最好放在页面最下面。但如果页面解析时就需要用到javascript,这时放到底部就不合适了。
Lazy Load Javascript(只有在需要加载的时候加载,在一般情况下并不加载信息内容。)随着 Javascript框架的流行,越来越多的站点也使用起了框架。不过,一个框架往往包括了很多的功能实现,这些功能并不是每一个页面都需要的,如果下载了不需要的脚本则算得上是一种资源浪费 -既浪费了带宽又浪费了执行花费的时间。目前的做法大概有两种,一种是为那些流量特别大的页面专门定制一个专用的 mini版框架,另一种则是 Lazy Load。

减少重排与重绘

当DOM的变化影响了元素的几何属性(宽或高),浏览器需要重新计算元素的几何属性,同样其他元素的几何属性和位置也会因此受到影响。浏览器会使渲染树中受到影响的部分失效,并重新构造渲染树。这个过程称为重排。完成重排后,浏览器会重新绘制受影响的部分到屏幕,该过程称为重绘。
重排何时发生?
很显然,每次重排,必然会导致重绘,那么,重排会在哪些情况下发生?
1、添加或者删除可见的DOM元素
2、元素位置改变
3、元素尺寸改变
4、元素内容改变(例如:一个文本被另一个不同尺寸的图片替代)
5、页面渲染初始化(这个无法避免)
6、浏览器窗口尺寸改变
这些都是显而易见的,或许你已经有过这样的体会,不间断地改变浏览器窗口大小,导致UI反应迟钝(某些低版本IE下甚至直接挂掉),现在你可能恍然大悟,没错,正是一次次的重排重绘导致的!

重排和重绘是DOM编程中耗能的主要原因之一,平时涉及DOM编程时可以参考以下几点:
1、尽量不要在布局信息改变时做查询(会导致渲染队列强制刷新)
2、同一个DOM的多个属性改变可以写在一起(减少DOM访问,同时把强制渲染队列刷新的风险降为0)
3、如果要批量添加DOM,可以先让元素脱离文档流,操作完后再带入文档流,这样只会触发一次重排(fragment元素的应用)
4、将需要多次重排的元素,position属性设为absolute或fixed,这样此元素就脱离了文档流,它的变化不会影响到其他元素。例如有动画效果的元素就最好设置为绝对定位。

javascript代码优化

1、减少dom访问
对DOM操作的代价是高昂的,这在网页应用中的通常是一个性能瓶颈。

天生就慢。在《高性能JavaScript》中这么比喻:“把DOM看成一个岛屿,把JavaScript(ECMAScript)看成另一个岛屿,两者之间以一座收费桥连接”。所以每次访问DOM都会教一个过桥费,而访问的次数越多,交的费用也就越多。所以一般建议尽量减少过桥次数。
解决办法:

修改和访问DOM元素会造成页面的Repaint和Reflow,循环对DOM操作更是罪恶的行为。所以请合理的使用JavaScript变量储存内容,考虑大量DOM元素中循环的性能开销,在循环结束时一次性写入。
减少对DOM元素的查询和修改,查询时可将其赋值给局部变量。

2、减少作用域链查找
作用域查找也是消耗一定时间的,所以我们可以将要使用的对象用变量保存在局部变量中,避免作用域的全局查找。此外,要减少作用域链查找还应该减少闭包的使用。

3、慎用 with 
with(obj){ p = 1}; 代码块的行为实际上是修改了代码块中的执行环境 ,将obj放在了其作用域链的最前端,在 with代码块中访问非局部变量是都是先从 obj上开始查找,如果没有再依次按作用域链向上查找,因此使用 with相当于增加了作用域链长度。而每次查找作用域链都是要消耗时间的,过长的作用域链会导致查找性能下降。
  因此,除非你能肯定在 with代码中只访问 obj中的属性,否则慎用 with,替代的可以使用局部变量缓存需要访问的属性。
4、 避免使用 eval和 Function
每次 eval 或Function 构造函数作用于字符串表示的源代码时,脚本引擎都需要将源代码转换成可执行代码。这是很消耗资源的操作 —— 通常比简单的函数调用慢 100倍以上。
  eval 函数效率特别低,由于事先无法知晓传给 eval 的字符串中的内容,eval在其上下文中解释要处理的代码,也就是说编译器无法优化上下文,因此只能有浏览器在运行时解释代码。这对性能影响很大。
  Function 构造函数比 eval略好,因为使用此代码不会影响周围代码 ;但其速度仍很慢。
  此外,使用 eval和 Function也不利于Javascript 压缩工具执行压缩。
  
5、优化循环,妙用算法
减少循环的次数对性能的提升效果也是显著的。特别是在循环次数很多的时候,优化循环次数是很有必要的。有些时候算法可以取到事半功倍的效果。

原创粉丝点击