repaint(重绘)是在一个元素的外观被改变,但没有改变布局的情况下发生,如改变visibility、outline、前景色。当repaint发生时,浏览器会验证DOM树上的所有其它结点的visibility属性。
2. Reflow如果变化涉及元素布局 (如 width), 浏览器则抛弃原有属性, 重新计算并把结果传递给 render 以重新描绘页面元素, 此过程称为 reflow。reflow(回流)是导致DOM脚本执行低效的关键因素之一。页面上任何一个结点触发reflow,都会导致它的子结点及祖先结点重新渲染。
以下操作会引起reflow:
- 改变窗囗大小
- 改变文字大小
- 添加/删除样式表
- 内容的改变,如用户在输入框中敲字
- 激活伪类,如:hover
- 操作class属性
- 脚本操作DOM
- 计算offsetWidth和offsetHeight
- 设置style属性
Reflow是不可避免的,只能将reflow对性能的影响减小到最小,以下是一些建议:
- 尽可能限制reflow的影响范围。有时 reflow 页面中的一个元素会 reflow 它的父元素(译注:这里是复数)以及所有子元素。
- 通过设置style属性改变结点样式的话,每设置一次都会导致一次reflow。所以最好通过设置class的方式。
- 实现元素的动画,它的position属性应当设为fixed或absolute,这样不会影响其它元素的布局。
- 权衡速度的平滑。比如实现一个动画,以1个像素为单位移动这样最平滑,但reflow就会过于频繁,CPU很快就会被完全占用。如果以3个像素为单位移动就会好很多。
- 不要用tables布局的另一个原因就是tables中某个元素一旦触发reflow就会导致table里所有的其它元素reflow。在适合用table的场合,可以设置table-layout为auto或fixed,这样可以让table一行一行的渲染,这种做法也是为了限制reflow的影响范围。
- 很多情况下都会触发reflow,如果css里有expression,每次都会重新计算一遍。
- 避免在document上直接进行频繁的DOM操作,如果确实需要可以采用off-document的方式进行
- 先将元素从document中删除,完成修改后再把元素放回原来的位置
- 将元素的display设置为”none”,完成修改后再把display修改为原来的值
- 如果需要创建多个DOM节点,可以使用DocumentFragment创建完后一次性的加入
- Minimizing browser reflow
- Rendering: repaint, reflow/relayout, restyle
- 页面重构应注意的repaint和reflow
如需转载,请注明来自: BorisHuai前端修炼 > Repaint and Reflow
除此之外,也可以使用较简便的forEach 方式
Firefox 和Chrome 的Array 类型都有forEach的函数。使用如下:
<!--Add by oscar999--> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML> <HEAD> <TITLE> New Document </TITLE> <META NAME="Author" CONTENT="oscar999"> </HEAD> <BODY> <script> var arryAll = []; arryAll.push(1); arryAll.push(2); arryAll.push(3); arryAll.push(4); arryAll.forEach(function(e){ alert(e); }) </script> </BODY> </HTML>
但是以上,代码在IE中却无法正常工作。
因为IE的Array 没有这个方法
alert(Array.prototype.forEach);执行以上这句得到的是 "undefined", 也就是说在IE 中 Array 没有forEach的方法。
//Array.forEach implementation for IE support.. //https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Array/forEach if (!Array.prototype.forEach) { Array.prototype.forEach = function(callback, thisArg) { var T, k; if (this == null) { throw new TypeError(" this is null or not defined"); } var O = Object(this); var len = O.length >>> 0; // Hack to convert O.length to a UInt32 if ({}.toString.call(callback) != "[object Function]") { throw new TypeError(callback + " is not a function"); } if (thisArg) { T = thisArg; } k = 0; while (k < len) { var kValue; if (k in O) { kValue = O[k]; callback.call(T, kValue, k, O); } k++; } }; }详细介绍可以参照:
https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Array/forEach
Js 此种状况的forEach 不能使用continue, break; 可以使用如下两种方式:
1. if 语句控制
2. return . (return true, false)
return --> 类似continue
以下例子是取出数组中2的倍数和3的倍数的数;
<!--Add by oscar999--> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML> <HEAD> <TITLE> New Document </TITLE> <META NAME="Author" CONTENT="oscar999"> </HEAD> <BODY> <script> if (!Array.prototype.forEach) { Array.prototype.forEach = function(callback, thisArg) { var T, k; if (this == null) { throw new TypeError(" this is null or not defined"); } var O = Object(this); var len = O.length >>> 0; // Hack to convert O.length to a UInt32 if ({}.toString.call(callback) != "[object Function]") { throw new TypeError(callback + " is not a function"); } if (thisArg) { T = thisArg; } k = 0; while (k < len) { var kValue; if (k in O) { kValue = O[k]; callback.call(T, kValue, k, O); } k++; } }; } var arryAll = []; arryAll.push(1); arryAll.push(2); arryAll.push(3); arryAll.push(4); arryAll.push(5); var arrySpecial = []; arryAll.forEach(function(e){ if(e%2==0) { arrySpecial.push(e); }else if(e%3==0) { arrySpecial.push(e); } }) </script> </BODY> </HTML>
使用return 达到以上效果
arryAll.forEach(function(e){ if(e%2==0) { arrySpecial.push(e); return; } if(e%3==0) { arrySpecial.push(e); return; } })
至于如何写类似break 的效果,目前尚未找到比较好的办法。
有搜索一下,有的说return false 可以达成, 试了一下, 效果和return 和return ture 是一样的。
大部分前端开发人员都不关心CSS性能优化,其实对于一个复杂的页面来说,高效的选择器还是可以带来一定的性能提升的。
1. CSS 选择器浏览器是“从右往左”来分析 class 的,它的匹配规则是从右向左来进行匹配的,因此最右边的选择符就是关键选择符。
-
Descendant selector
#toc > li {font-weight: bold}
浏览器首先会查找页面上所有的“li”节点,然后再去做进一步的判断:如果它的父节点的 id 为“toc”,则匹配成功。
-
Descendant selector
#toc li {font-weight: bold}
这个效率比之前的“child selector”效率更慢,而且要慢很多。浏览器先便利所有的“li”节点,然后步步上溯其父节点,直到 DOM 结构的根节点(document),如果有某个节点的 id 为“toc”,则匹配成功,否则继续查找下一个“li”节点。
-
尽量避免 universal rules
[hidden="true"] { ... } /* A universal rule */
这里的匹配规则很明显:查找页面上的所有节点,如果有节点存在“hidden”属性,并且其属性值为“true”,则匹配成功。这是最耗时耗力的匹配,页面上的所有节点都需要进行匹配运算,这种规则应尽量避免。
-
Id-categorized 规则与 tag name 或 class 规则并行
button#goButton {...};----->>#goButton .fundation#testIcon {...};----->>#testIcon
这里,按照我们常规的理解,箭头左边的写法似乎是应该更快的,因为它的限制更多。其实不然,id 是全局唯一的,在匹配 CSS 选择器时浏览器定位到 id 是最快的,如果伴随有其他的非 id 的 selector,反而会影响匹配的效率。
-
关于 class-categorized 规则
button.indented {...}----->>.button-indented {...}
程序员们经常会给某个 Class 前面加上标签名称(Tag Name),以更精确且快速的定位该节点,但是这样往往效率更差。和清单 8 中的原理一样,页面上的 class 在全局范围内来讲应该是唯一的,用唯一的 Class 名称来定位一个节点往往比组合定位更加快捷。事实上,这种做法也可以避免由于开发修改页面元素的类型(Tag)而导致的样式失效的情况,做到样式与元素的分离,两者独立维护。
-
尽量减少规则数量
Span[mailfolder="true"] > table > tr > td.columnClass {...} ------------------->>>>>>> .span-mailfolder-tbl-tdCol {...}
规则越多,匹配越慢,上面一种规则需要进行 6 项匹配,先找“columnClass”,再找“td”,然后是“tr”,“table”,最后是符合“mailfolder”为“true”的 span,这种效率是非常慢的。如果用一个比较特殊的 class 替代(span-mailfolder-tbl-tdCol),效率会快上好几倍。
-
尽量避免使用 descendant selector
treehead treerow treecell {...} ----->> treehead > treerow > treecell {...}
Descendant 选择器是耗时相对高的选择器,通常来讲,它在 CSS 里的使用应该是尽量避免的,如果能用 child 选择器替代就应该尽量这样去做。
-
利用 CSS 的继承机制
在 CSS 中,有很多 CSS 的属性以可以继承的,如果某个节点的父节点已经设定了上述的 CSS 样式(如:color, font 等 …),并且子节点无需更改该样式,则无需再作相关设定,同时,也可以利用这一点:如果很多子节点都需要设定该 CSS 属性值,可以统一设定其父节点的该 CSS 属性,这样一来,所有的子节点再无需做额外设定,加速了 CSS 的分析效率。
浏览器在所有的 stylesheets 加载完成之后,才会开始渲染整个页面,在此之前,浏览器不会渲染页面里的任何内容,页面会一直呈现空白。这也是为什么要把 stylesheet 放在头部的原因。如果放在 HTML 页面底部,页面渲染就不仅仅是在等待 stylesheet 的加载,还要等待 html 内容加载完成,这样一来,用户看到页面的时间会更晚。
3. 避免使用 CSS Expressions:Background-color: expression( (new Date()).getHours()%2 ? "#B8D4FF" : "#F08A00" )
Expression 只有 IE 支持,而且他的执行比大多数人想象的要频繁的多。不仅页面渲染和改变大小 (resize) 时会执行,页面滚动 (scroll) 时也会执行,甚至连鼠标在页面上滑动时都会执行。在 expression 里面加上一个计数器就会知道,expression 的执行上相当频繁的。鼠标的滚动很容易就会使 expression 的执行次数超过 10000。
4. 避免使用 Filter:IE 特有的 AlphaImageLoader filter 是为了解决 IE6 及以前版本不支持半透明的 PNG 图片而存在的。但是浏览器在下载 filter 里面的图片时会“冻结”浏览器,停止渲染页面。同时 filter 也会增大内存消耗。最不能忍受的是 filter 样式在每个页面元素(使用到该 filter 样式)渲染时都会被浏览器分析一次,而不是像一般的背景图片渲染模式:使用过该背景图片的所有元素都是被浏览器一次性渲染的。针对这种情况,最好的解决办法就是使用 PNG8。
5. CSS 缩写:CSS 缩写可以让你用极少的代码定义一系列样式属性,这种做法可以极大程度的缩减代码量以达到提高性能的目的。
参考文档- Performance Impact of CSS Selectors
- Writing efficient CSS
- Optimize browser rendering
如需转载,请注明来自: BorisHuai前端修炼 > CSS性能优化探讨