渲染机制

1、十六进制的颜色值对位数与大小写

编写十六进制颜色值时你可能会用小写字母或省略成3位数,关于这写法没找到确实的数据证明对浏览器的渲染效率是否有影响,但十六进制的颜色值默认标准是大写及6位数标注。在未知情况下不希望冒险而降低了渲染的效率。

* 不赞成 - color:#f3a;

* 建议用 - color:#FF33AA;

2、display与visibility的差异

他们用于设置或检索是否显示对象。display隐藏对象不保留物理空间,visibility为隐藏对象保留占据的物理空间。当浏览器渲染被占据的物理空间时,会有所消耗资源。

* 不赞成 - visibility:hidden;

* 建议用 - display:none;

3、border:none;与border:0;的区别和display与visibility的关系类似,分别不保留与保留空间。更多的是border:0;尽管可以隐藏掉边框,但它会为你保留border-color/border-style的使用权。

* 不赞成 - border:0;

* 建议用 - border:none;

4、不宜过小的背景图片平铺一张宽高1px的背景图片,虽然文件体积非常之小,但渲染宽高500px的板块需要重复平铺2500次。提高背景图片渲染效率跟图片尺寸及体积有关,最大的图片文件体积保持约70KB。

* 不赞成 - 宽高8px以下的平铺背景图片

* 建议用 - 衡量适中体积及尺寸的背景图片

5、IE的滤镜           (3lian.com)IE的滤镜除了比较消耗资源外也有兼容性问题。当中有令PNG透明的滤镜,可采用GIF或JPG似透非透的办法来避免使用此滤镜。建议只在IE6应用GIF透明,因为IE7以上已经支持了PNG透明。

* 不赞成,滥用IE滤镜因为消耗资源外也有兼容性问题。

* 建议用,最好选择其它方法能避免使用滤镜。

6、*{ margin:0; padding:0;}避免浏览器样式差异*号通配符把所有标签都初始化一遍,浏览器的渲染消耗一定的资源。有部分在标签在不同浏览器上几乎无差异,或是某些已经不推荐使用的标签(为你不会去用它),它们不需通配符要重新初始化一遍这样做能节省一点资源。

* 不赞成,使用*号通配符

* 不赞成,div span button b table等标签纳入通配符控制内外填充样式

* 建议用,有选择性地使用通配符控制内外填充样式。

7、不要添加额外的标签来描述class或id 如果你有一个选择器是以id作为关键选择符,请不要添加多余标签名上去。因为ID是唯一的,你不要为了一个不存在的理由而降低了匹配的效率。

* 不赞成 - button#backButton { }

* 不赞成 - .menu-left #newMenuIcon { }

* 建议用 - #backButton { }

* 建议用 - #newMenuIcon { }

8、尽量选择最特殊的类来存放选择器 降低系统效率的一个最大原因是我们在标签类中用了过多的选择符。通过添加 class 到元素,我们可以将类别进行再细分为 class 类,这样就不为了一个标签浪费时间去匹配过多的选择符了。

* 不赞成 - treeitem[mailfolder=”true”] > treerow > treecell { }

* 建议用 - .treecell-mailfolder { }

9、避免子孙选择符 子孙选择符是CSS中最耗资源的选择符。他真的是非常的耗资源,尤其是在选择器使用标签类或通用类的时候。很多情况中,我们真正想要的是子选择符。除非有明确说明,在 UI CSS 中是严禁使用子孙选择符的。

* 不赞成 - treehead treerow treecell { }

* 好一点,但还是不行(参照下一条) - treehead > treerow > treecell { }

10、标签类中不要包含子选择符  不要在标签类中使用子选择符。否则,每次元素的出现,都会额外地增加匹配时间。(特别是当选择器似乎多半会被匹配的情况下)

* 不赞成 - treehead > treerow > treecell { }

* 建议用 - .treecell-header { }

11、留意所有子选择符的使用 小心地使用子选择符。如果你能想出一个的不使用他的方法,那么就不要使用。特别是在 RDF 树和菜单会频繁地使用子选择符,像这样。

* 不赞成 - treeitem[IsImapServer=”true”] > treerow > .tree-folderpane-icon { }

请记住 RDF 的属性是可以在模板中被复制的!利用这一点,我们可以复制那些想基于该属性改变的子 XUL 元素上的 RDF 属性。

* 建议用 - .tree-folderpane-icon[IsImapServer=”true”] { }

从右到左   浏览器如何读取你的CSS选择器有一个很重要的原则,那就是它们从右到左读取。这意味这像 ul > li a[title="home"] 这样的选择器,a[title="home"] 将是最先被读取的。这一部分通常被称为 “key selector” (可否称为“目标选择器” -_-!)选择器的最后一部分,也是被选择的标签。ID‘s 是最有效率的,通用符是最慢的 有四种目标选择器:ID, class, tag和通用符。看下他们各自的效率如何:

#main-navigation { }

body.home #page-wrap { }

.main-navigation { }

ul li a.current { }

ul li a { }

* { }

#content [title=‘home‘] 然后我们结合从右到左和目标选择器的概念,我们可以知道下面这个选择器并不高效: #main-nav > li { }

尽管这让人有点费解......因为ID‘s是最高效的,浏览器可以通过ID迅速的找到 li。但事实是,li 标签是被先读取的。

不要用标签修饰死也不要像下面这样干:ul#main-navigation { }

ID‘s 是唯一的,所以不需要用标签修饰,这只会让它更低效。

如果你可以避免的话,也不要用它修饰 class 。class 不是唯一的,所以理论上你可以把它用在不同的标签。如果你愿意的话,你可以用标签控制不同的样式,这样你可能需要标签修饰(比如:li.first),但这样做的人很少,所以,don‘t .绝对没有比用后代选择器更糟糕的做法了 后代选择器是CSS里最昂贵的选择器,昂贵得可怕——特别是当它放在标签和通用符后面时。就如下面这个东东一样,绝对的效率毒瘤:html body ul li a { }

一个选择器渲染失败比这个选择器被渲染更高效

我不是很确定是否有更好的证据去证明这一点,因为如果你有大量的选择器在CSS样式表里无法找到,这样的事情貌似很离奇,但一点必需注意的是,从右到左的解释一个选择器来说,一旦它找不到,那它就会停止尝试。然而如果它找到了,那它就需要花更多精力去解释了。

试想一下为何你这样写选择器

思考下这东东:

#main-navigation li a { font-family: Georgia, Serif; }

你可能不需要从 a 选择器开始(如果你只是想换个字体)。下面这个可能更高效些:

#main-navigation { font-family: Georgia, Serif; } 实用性

还刻前面提到的Mozilla的一篇文章?已经有十年了。事实是:计算机比十年前变慢了(不是我理解错了,还是作者想说现在的WEB越来越复杂了)。

我感觉这东东在当年似乎还更受重视。十年前我还是个21岁的英俊小生,当然我不觉得那里我会认识css这东东。所以我也无法跟你讲以前的情况......但我觉得渲染效率的问题之所以没被重视是因为这从来就不是一个大问题。 这是我的一些看法:不管怎样上面提到的东东都是有意义的,你可以按照上面的方法去做,因为它并不会限制你的CSS制作。但你也没必要太教条主义。如果你是个完美主义者,而之前又没有考虑过那东东,那是时候去重新看一下你之前写的一些样式是否有改进的地方了。如果你没发现你的网站明显的渲染缓慢,那大可别太在意,在以后的工作中多注意就行了。

超级快速,零实用性

我们知道ID‘s 是最高效的选择器。当你想让渲染速度最高效时,你可能会给每个独立的标签配置一个ID,然后用这些ID写样式。那会超级快,也超级荒唐。这样的结果是语义极差,维护难到了极点。即使在核心部分你也不应该见过这样做的。我认为这个可以提醒我们不要为了高效的CSS放弃语义和可维护性。

Link : http://blog.sina.com.cn/s/blog_77a4568a0101d6di.html

时间: 2024-10-11 15:25:04

渲染机制的相关文章

webkit 渲染机制

最近看了< webkit技术内幕 >,虽然并不能完全看懂,但是对浏览器的渲染机制也算是有了一个比较完整的认识. 我们从浏览器地址栏输入网址开始到web页面被完整的呈现在眼前,大概的经过了这样一个过程:网址被DNS解析为IP地址 -> 通过IP地址建立TCP连接 -> 发送HTTP请求 -> 服务器处理请求并返回响应 ->  浏览器解析渲染页面 -> 断开TCP连接 可是浏览器是怎么去解析渲染页面的呢?这里就要涉及到浏览器的内核,也就是浏览器的渲染引擎(严格来说应该

浏览器的渲染机制

Google Web Fundamentals 是一个非常优秀的文档,里面讲到了跟web.浏览器.前端的方方面面.我总结一下其中的 Ilya Grigorik 写的 Critical rendering path 浏览器渲染机制部分的内容如下: 几个概念 1.DOM:Document Object Model,浏览器将HTML解析成树形的数据结构,简称DOM. 2.CSSOM:CSS Object Model,浏览器将CSS代码解析成树形的数据结构. 3.DOM 和 CSSOM 都是以 Byte

深入理解Android渲染机制

基础知识 CPU: 中央处理器,它集成了运算,缓冲,控制等单元,包括绘图功能.CPU将对象处理为多维图形,纹理(Bitmaps.Drawables等都是一起打包到统一的纹理). GPU:一个类似于CPU的专门用来处理Graphics的处理器, 作用用来帮助加快格栅化操作,当然,也有相应的缓存数据(例如缓存已经光栅化过的bitmap等)机制. OpenGL ES:是手持嵌入式设备的3DAPI,跨平台的.功能完善的2D和3D图形应用程序接口API,有一套固定渲染管线流程. OpenGL ES详解 D

[转]浏览器渲染机制——一定要放在body底部的js引用

转自:http://blog.csdn.net/u012251421/article/details/50536265 说明: 本文提到的浏览器均是指Chrome. “script标签“指的都是普通的不带其他属性的外联javascript. web性能优化的手段并不是非黑即白的,有些手段过头了反而降低性能,所以在讨论条件和结论的时候,虽然很多条件本身会带来其他细微的负面或正面影响,为了不使论述失去重点,不会扩展太开. 一.从一个面试题说起 面试前端的时候我喜欢问一些看上去是常识的问题.比如:为什

Chromium网页渲染机制简要介绍和学习计划

作为一个浏览器,快速地将网页渲染出来是最重要的工作.Chromium为了做到这一点,费尽了心机,做了大量优化工作.这些优化工作是卓有成效的,代表了当今最先进的网页渲染技术.值得一提的是,这些渲染技术不仅适用于网页渲染,也可以应用在原生系统的UI渲染上.例如,在Android系统上,我们就可以看到两者在渲染技术上的相似之处.本文接下来就对Chromium的网页渲染机制进行简要介绍,并且制定学习计划. 老罗的新浪微博:http://weibo.com/shengyangluo,欢迎关注! Chrom

转---JS 一定要放在 Body 的最底部么?聊聊浏览器的渲染机制

作者:德来 segmentfault.com/a/1190000004292479 如有好文章投稿,请点击 → 这里了解详情 一.从一个面试题说起 面试前端的时候我喜欢问一些看上去是常识的问题.比如:为什么大家普遍把<script src=""></script>这样的代码放在body最底部?(为了沟通效率,我会提前和对方约定所有的讨论都以chrome为例) 应聘者一般会回答:因为浏览器生成Dom树的时候是一行一行读HTML代码的,script标签放在最后面就不

Android渲染机制和丢帧分析

http://blog.csdn.net/bd_zengxinxin/article/details/52525781 自己编写App的时候,有时会感觉界面卡顿,尤其是自定义View的时候,大多数是因为布局的层次过多,存在不必要的绘制, 或者onDraw等方法中过于耗时.那么究竟需要多快,才能给用户一个流畅的体验呢?那么就需要简单了解下Android的渲染机制: Android系统每隔16ms发出VSYNC信号,触发对UI进行渲染,那么整个过程如果保证在16ms以内就能达到一个流畅的画面. 那么

深入Android渲染机制

1.知识储备 CPU: 中央处理器,它集成了运算,缓冲,控制等单元,包括绘图功能.CPU将对象处理为多维图形,纹理(Bitmaps.Drawables等都是一起打包到统一的纹理). GPU:一个类似于CPU的专门用来处理Graphics的处理器, 作用用来帮助加快格栅化操作,当然,也有相应的缓存数据(例如缓存已经光栅化过的bitmap等)机制. OpenGL ES是手持嵌入式设备的3DAPI,跨平台的.功能完善的2D和3D图形应用程序接口API,有一套固定渲染管线流程. 附相关OpenGL渲染流

浏览器的渲染机制,白屏和FOUC

关于浏览器的渲染机制,先要了解一些基本概念: DOM:浏览器解析html构建DOM树 CSSOM:浏览器解析CSS构建CSSOM规则树 Render Tree:DOM和CSSOM合并后生成Render Tree layout:layout:有了Render Tree,浏览器已经能知道网页中有哪些节点.各个节点的CSS定义以及他们的从属关系,从而去计算出每个节点在屏幕中的位置 painting:按照算出来的规则,通过显卡,把内容画到屏幕上 reflow(回流):当浏览器发现某个部分发生了点变化影响

Nuklear渲染机制分析

最近打算用C写个东西,想找个轻量的UI库,想起以前star过的一个repo,只有一个头文件约15000行的ANSI C代码,没有任何标准库以外的依赖.就是这个:https://github.com/vurtun/nuklear .嗯,Nuklear,核动力. 看效果真心不错,让我想起另一个UI库zebkit,HTML5 canvas的.事实上这两个还真有点像,就是都是命令式绘制的.本来想照着demo用SDL做一个简单的界面出来,结果久别重逢C语言,一不小心把源码review了一遍(张全蛋:sil