好吧，进入正题。今天要讲的是如何使css的渲染效率更高效，也就是如何加快css的渲染速度。
先做一个引入。当浏览器解析HTML时首先构造一个内部文件树来代表所有显示的元素。然后浏览器根据标准的CSS级联、继承和排序规则，为元素指定匹配的各种样式。CSS搜索引擎通过样式规则为每个元素找到匹配的样式。该引擎由右至左评估每个规则，从最右边的选择器开始（称为“键”【Key】），并通过移动每个选择器，直到找到一个匹配或丢弃的规则。
例如:ul li a{......}
这样的选择器的话，a是最先被读取到的，IC报价网然后再依次往左匹配，直到最左边。在这个过程中，如果不匹配则丢弃，否则就往左走。
基于此原则，引擎要评估的规则越少越好。所以提高渲染性能的重要一步就是删除未使用的css。在此之后，对包含大量的元素和/或CSS规则的页面来说，优化规则本身的定义就能够提高性能。优化规则的关键在于尽可能具体定义规则，并避免不必要的重复，让样式引擎快速找到匹配的规则,而不用花费时间查找不适用的规则。
一般来说，目标选择器有四种：ID，class，标签和通用符。他们可以单独使用也可以组合使用。不过渲染速度各不相同。ID的渲染速度是最快的，如#menu{……}，但是当ID也其他标签组合的话他的渲染速度就有可能变得很低。如#menu li{……}，为什么呢？因为li是最先被读取的为不是#menu，就是要先读取页面中的所有li然后在判断其上一级有没有#menu。通用符的速度是最低的，就像body *{……}，要读取所有css目标选择器，其时间可想而知。
下面给大家介绍一些应该尽量避免的css写法
通配选择器作为键的规则
这个在上面已经说得很清楚了，应当减少或不用通配符来作为键的规则。
没有比用后代选择器更糟糕的做法了
后代选择器是CSS里最昂贵的选择器，就像我上面那张图的极端代码。特别是当它放在标签和通用符后面时。就下面那东东一样，绝对的效率毒瘤：html body ul li a{……}
这样做的话浏览器会从右向左一个一个的读取，相当于遍历了整棵DOM树，要花费大量的时间。这样的代码是绝对要避免的。我们可以用一些ID或class来代替以获得更高效率。
可以不使用标签的时候就不要使用#main h2{…….}
#menu li a{…….}
这个也是很重要的一个部分，IC报价网标签使用多了，那么读取的时间就会变长。所以有些地方我们可以使用ID或class来代替一些标签，是浏览器能够快速的定位到那个ID或class。比如上面我们可以给h2一个class然后直接为class定义样式，这样做也有利于css的模块化。或是直接省略标签也可以达到同样的效果。就像上面的#menu li a{…….}，如果你只想换个字体，那么完全可以这样写#menu{……}，效果相同，可是效率却更高。当然有些属性没有用标签的话是定义不了的，比如上面那个如果想改变a的颜色那么用#menu{……}是无效的，因此要看具体情况才去相应的措施。
标签选择器作为键的规则ul > li > a{…….}
子选择器和相邻选择器是低效的是因为对于每一个元素的匹配，浏览器不得不评估其他的一些元素，它需要双倍的时间耗费在匹配上。同时，越少的精确的键，越多的时间花费在匹配元素上面。尽管如此，即使是不高效的，他们比后代选择器的使用的效果要好一点。
不必要的限定选择器有这样的代码：
ul#nav li a{…….}
form#myForm{……}
你觉得去掉最前面的ul和form效果会有什么不同呢，很明显是一样的，那又何必加多一个标签增加负担呢。id选择器是唯一的，包含了tag或者class的限定仅仅是增加了一些无用的信息。
避免在一些非link的元素上使用:hover
非链接元素上的:hover伪选择器在某些情况下*会使IE 7 和IE 8 变慢。IC交易网当页面没有一个严格的doctype时，IE 7 和IE 8 将忽略除了链接外的任何元素的:hover。当页面有严格的doctype，在非链接元素上的:hover将导致性能下降。
最后，不管怎样上面提到的东东都是有意义的，你可以按照上面的方法去做，因为它并不会限制你的CSS制作。但你也没必要太教条主义。如果你是个完美主义者，而之前又没有考虑过那东东，那是时候去重新看一下你之前写的一些样式是否有改进的地方了。如果你没发现你的网站明显的渲染缓慢，那大可别太在意，在以后的工作中多注意就行了。
我们知道ID 是最高效的选择器。当你想让渲染速度最高效时，你可能会给每个独立的标签配置一个ID，然后用这些ID写样式。那会超级快，也超级荒唐。这样的结果是语义极差，维护难到了极点。即使在核心部分你也不应该见过这样做的。我认为这个可以提醒我们不要为了高效的CSS放弃语义和可维护性，什么东西都要有一个度。
"
