[转]提高 web 应用性能之 CSS 性能调优

简介

Web 开发中经常会遇到性能的问题,尤其是 Web 2.0 的应用。CSS 代码是控制页面显示样式与效果的最直接“工具”,但是在性能调优时他们通常被 Web 开发工程师所忽略,而事实上不规范的 CSS 会对页面渲染的效率有严重影响,尤其是对于结构复杂的 Web 2.0 页面,这种影响更是不可磨灭。所以,写出规范的、高性能的 CSS 代码会极大的提高应用程序的效率。本文主要来探讨一下如何优化,以及从哪些方面优化应用程序的 CSS 代码,从而最大限度的提高 Web 应用的性能。

回页首

CSS 性能调优

CSS 代码的分析与渲染都是由浏览器来完成的,所以,了解浏览器的 CSS 工作机制对我们的优化有至关重要的作用。这篇文章我们主要从如下几个方面入手来介绍一下 CSS 的性能优化:

  1. Style 标签的相关调优
  2. 特殊的 CSS 样式使用方式
  3. CSS 缩写
  4. CSS 的声明
  5. CSS 选择器

把 Stylesheets 放在 HTML 页面头部:

浏览器在所有的 stylesheets 加载完成之后,才会开始渲染整个页面,在此之前,浏览器不会渲染页面里的任何内容,页面会一直呈现空白。这也是为什么要把 stylesheet 放在头部的原因。如果放在 HTML 页面底部,页面渲染就不仅仅是在等待 stylesheet 的加载,还要等待 html 内容加载完成,这样一来,用户看到页面的时间会更晚。

对于 @import 和 <link> 两种加载外部 CSS 文件的方式:@import 就相当于是把 <link> 标签放在页面的底部,所以从优化性能的角度看,应该尽量避免使用 @import 命令

避免使用 CSS Expressions:

参考下述代码:

清单 1. CSS Expression 案例
padding: 6px 0px; border: 0px; outline: 0px; vertical-align: baseline; font-family: Arial, sans-serif; color: rgb(34, 34, 34); line-height: 1.5em; font-size: 1.166em !important;">Expression 只有 IE 支持,而且他的执行比大多数人想象的要频繁的多。不仅页面渲染和改变大小 (resize) 时会执行,页面滚动 (scroll) 时也会执行,甚至连鼠标在页面上滑动时都会执行。在 expression 里面加上一个计数器就会知道,expression 的执行上相当频繁的。鼠标的滚动很容易就会使 expression 的执行次数超过 10000。

避免使用 Filter:

IE 特有的 AlphaImageLoader filter 是为了解决 IE6 及以前版本不支持半透明的 PNG 图片而存在的。但是浏览器在下载 filter 里面的图片时会“冻结”浏览器,停止渲染页面。同时 filter 也会增大内存消耗。最不能忍受的是 filter 样式在每个页面元素(使用到该 filter 样式)渲染时都会被浏览器分析一次,而不是像一般的背景图片渲染模式:使用过该背景图片的所有元素都是被浏览器一次性渲染的。

针对这种情况,最好的解决办法就是使用 PNG8。

CSS 缩写:

CSS 缩写可以让你用极少的代码定义一系列样式属性,这种做法可以极大程度的缩减代码量以达到提高性能的目的。

清单 2. Colour 缩写
 #000000     ------>>     #000
 #336699     ------>>     #369

关于颜色,重复的属性值可以省略。

清单 3. 各种缩写方式
 Margin-top: 2px;
 Margin-right: 5px;
 Margin-bottom: 2em;
 Margin-left: 15px;     ----->>     Margin: 2px 5px 2em 15px; 

 Border-width: 1px;
 Border-style: solid;
 Border-color: #000     ----->>     border: 1px solid #000 

 Font-style: italic;
 Font-variant: small-caps;
 Font-weight: bold;
 Font-size: 1em;
 Line-height: 140%;
 Font-family: sans-serif;  ----->>  font: italic small-caps bold 1em 140% sans-serief 

 Background-color: #f00;
 Background-image: url(background.gif);
 Background-repeat: no-repeat;
 Background-attachment: fixed;
 Background-position: 0 0;
  ----->>background: #f00 url(background.gif) no-repeat fixed 0 0 

 list-style-type: square;
 list-style-position: inside;
 List-style-image: url(image.gif)  ----->> list-style: square inside url(image.gif)

Multiple Declarations

关于 CSS 的 class 声明和定义,也有简写的方式

清单 4. Class 的声明
.Class1{position: absolute; left: 20px; top: 30px;}
.Class2{position: absolute; left: 20px; top: 30px;}
.Class3{position: absolute; left: 20px; top: 30px;}
.Class4{position: absolute; left: 20px; top: 30px;}
.Class5{position: absolute; left: 20px; top: 30px;}
.Class6{position: absolute; left: 20px; top: 30px;} 

 -------------------->>>>>>> 

 .class1 .class2 .class3 .class4 .class5 .class6{
 Position: absolute; left: 20px; top: 20px;
 }

这种 Class 简写的方式可以极大的缩减我们的代码,提高浏览器分析识别的效率。

CSS 选择器 (CSS Selectors)

先来看看下面这个例子:

清单 5. Child selector
 #toc > li {font-weight: bold}

按照我们惯常的理解,编译器应该是先查找 id 为“toc”的节点,然后在他的所有直接子节点中查找类型(tag)为“li”的节点,将“font-weight”属性应用到这些节点上。

但是,不幸的是,恰恰相反,浏览器是“从右往左”来分析 class 的,它的匹配规则是从右向左来进行匹配的。这里,浏览器首先会查找页面上所有的“li”节点,然后再去做进一步的判断:如果它的父节点的 id 为“toc”,则匹配成功。

由此可知,CSS 选择器的匹配远比我们想象的要慢的多,CSS 的性能问题不容忽视。

清单 6. Descendant selector
 #toc  li {font-weight: bold}

这个效率比之前的“child selector”效率更慢,而且要慢很多。浏览器先便利所有的“li”节点,然后步步上溯其父节点,直到 DOM 结构的根节点(document),如果有某个节点的 id 为“toc”,则匹配成功,否则继续查找下一个“li”节点。

清单 7. 尽量避免 universal rules
 [hidden="true"] { ... } /* A universal rule */

这里的匹配规则很明显:查找页面上的所有节点,如果有节点存在“hidden”属性,并且其属性值为“true”,则匹配成功。这是最耗时耗力的匹配,页面上的所有节点都需要进行匹配运算,这种规则应尽量避免。

清单 8. Id-categorized 规则与 tag name 或 class 规则并行
 button#goButton {...};----->>#goButton
 .fundation#testIcon {...};----->>#testIcon

这里,按照我们常规的理解,箭头左边的写法似乎是应该更快的,因为它的限制更多。其实不然,id 是全局唯一的,在匹配 CSS 选择器时浏览器定位到 id 是最快的,如果伴随有其他的非 id 的 selector,反而会影响匹配的效率。

清单 9. 关于 class-categorized 规则
 button.indented {...}----->>.button-indented {...}

程序员们经常会给某个 Class 前面加上标签名称(Tag Name),以更精确且快速的定位该节点,但是这样往往效率更差。和清单 8 中的原理一样,页面上的 class 在全局范围内来讲应该是唯一的,用唯一的 Class 名称来定位一个节点往往比组合定位更加快捷。事实上,这种做法也可以避免由于开发修改页面元素的类型(Tag)而导致的样式失效的情况,做到样式与元素的分离,两者独立维护。

清单 10. 尽量减少规则数量
 Span[mailfolder="true"] > table > tr > td.columnClass {...} 

 ------------------->>>>>>> 

 .span-mailfolder-tbl-tdCol {...}

规则越多,匹配越慢,上面一种规则需要进行 6 项匹配,先找“columnClass”,再找“td”,然后是“tr”,“table”,最后是符合“mailfolder”为“true”的 span,这种效率是非常慢的。如果用一个比较特殊的 class 替代(span-mailfolder-tbl-tdCol),效率会快上好几倍。

清单 11. 尽量避免使用 descendant selector
 treehead treerow treecell {...} ----->> treehead > treerow > treecell {...}

Descendant 选择器是耗时相对高的选择器,通常来讲,它在 CSS 里的使用应该是尽量避免的,如果能用 child 选择器替代就应该尽量这样去做。

清单 12. 利用 CSS 的继承机制
 Color
 Font
 Letter-spacing
 Line-height
 List-style
 Text-align
 Text-indent
 Text-transform
 White-space
 Word-spacing 

 #bookmark  > .menu-left {list-style-image: url(blah)} 

 ------------>>>>>>>> 

 #bookmark  {list-style-image: url(blah)}

在 CSS 中,有很多 CSS 的属性以可以继承的,如果某个节点的父节点已经设定了上述的 CSS 样式(如:color, font 等 ...),并且子节点无需更改该样式,则无需再作相关设定,同时,也可以利用这一点:如果很多子节点都需要设定该 CSS 属性值,可以统一设定其父节点的该 CSS 属性,这样一来,所有的子节点再无需做额外设定,加速了 CSS 的分析效率。

回页首

结束语

这篇文章介绍了 Web 开发中关于 CSS 性能方面需要注意的一些小细节,从 CSS 本身着手,介绍了编写 CSS 代码中需要避免的一些写法,比如 CSS Expression 的弊端,CSS 缩写以及 CSS 选择器的注意事项等等,也分享了一些比较推荐的做法。我们可以在开发过程中尽量注意一下这些小细节,以尽可能多的提高我们 Web 应用的性能。

来源:

http://www.ibm.com/developerworks/cn/web/1109_zhouxiang_optcss/

时间: 2024-10-11 17:51:55

[转]提高 web 应用性能之 CSS 性能调优的相关文章

提高 web 应用性能之 CSS 性能调优

CSS 性能调优 CSS 代码的分析与渲染都是由浏览器来完成的,所以,了解浏览器的 CSS 工作机制对我们的优化有至关重要的作用.这篇文章我们主要从如下几个方面入手来介绍一下 CSS 的性能优化: Style 标签的相关调优 特殊的 CSS 样式使用方式 CSS 缩写 CSS 的声明 CSS 选择器 把 Stylesheets 放在 HTML 页面头部: 浏 览器在所有的 stylesheets 加载完成之后,才会开始渲染整个页面,@import 就相当于是把 <link> 标签放在页面的底部

spark性能优化:shuffle调优

调优概述 大多数Spark作业的性能主要就是消耗在了shuffle环节,因为该环节包含了大量的磁盘IO.序列化.网络数据传输等操作.因此,如果要让作业的性能更上一层楼,就有必要对shuffle过程进行调优.但是也必须提醒大家的是,影响一个Spark作业性能的因素,主要还是代码开发.资源参数以及数据倾斜,shuffle调优只能在整个Spark的性能调优中占到一小部分而已.因此大家务必把握住调优的基本原则,千万不要舍本逐末.下面我们就给大家详细讲解shuffle的原理,以及相关参数的说明,同时给出各

【转载】 Spark性能优化:资源调优篇

在开发完Spark作业之后,就该为作业配置合适的资源了.Spark的资源参数,基本都可以在spark-submit命令中作为参数设置.很多Spark初学者,通常不知道该设置哪些必要的参数,以及如何设置这些参数,最后就只能胡乱设置,甚至压根儿不设置.资源参数设置的不合理,可能会导致没有充分利用集群资源,作业运行会极其缓慢:或者设置的资源过大,队列没有足够的资源来提供,进而导致各种异常.总之,无论是哪种情况,都会导致Spark作业的运行效率低下,甚至根本无法运行.因此我们必须对Spark作业的资源使

jvm性能监控与GC调优

目录 一 提出问题 二 基于JDK命令行工具的监控 1. JVM的三种参数类型 1.1 标准参数 1.2 X 参数 1.3 XX 参数 1.4 常用命令 2. jstat查看虚拟机统计信息 2.1 类加载信息 2.2 垃圾回收信息 2.3 JIT编译信息 3. jmap + MAT分析内存溢出 [实战] 3.1 模拟内存溢出 3.2 导出内存影像文件 3.3 使用MAT分析dump文件 4. jstack分析死循环与死锁 [实战] 三 基于JVisualVM的可视化监控 四 基于Btrace的监

SOLR管理配置和性能优化JVM参数调优

我个配置:JAVA_OPTIONS="-Xmx1024m -Xms1024m -Xmn512m -XX:MaxPermSize=128m -XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0 -Xnoclassgc -XX:+DisableExplicitGC -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBefor

性能优化-优化-JVM调优

1.JDK版本 尽可能的使用高版本的JDK版本,这通常可以带来免费的性能提升.当前前提是版本是稳定的,并且相应的应用服务器或者开源第三方工具等,也可以基于此版本稳定运行. 2.字节码验证 如果编译的代码,以及依赖的第三方jar包都是可信赖的话,可以关闭字节码验证,从而节省类加载时间,可通过-XVerify:none关闭字节码验证. 3.JIT编译方式 HotSpot有2种JIT编译方式,分别是Client模式和Server模式,Client模式的特点是启动快.占用内存少.JIT编译器生成代码的速

性能优化之MySQL调优篇

MySQL对于很多Linux从业者而言,是一个非常棘手的问题,多数情况都是因为对数据库出现问题的情况和处理思路不清晰.在进行MySQL的优化之前必须要了解的就是MySQL的查询过程,很多的查询优化工作实际上就是遵循一些原则让MySQL的优化器能够按照预想的合理方式运行而已. 图 - MySQL查询过程 1.2 优化的哲学 优化有风险,涉足需谨慎 1.2.1 优化可能带来的问题 优化不总是对一个单纯的环境进行,还很可能是一个复杂的已投产的系统. 优化手段本来就有很大的风险,只不过你没能力意识到和预

机器学习:模型性能评估与参数调优

模型性能评估的常用指标 真阳性(True Positive,TP):指被分类器正确分类的正例数据 真阴性(True Negative,TN):指被分类器正确分类的负例数据 假阳性(False Positive,FP):被错误地标记为正例数据的负例数据 假阴性(False Negative,FN):被错误地标记为负例数据的正例数据 精确率=TP/(TP+FP),TP+FP是模型预测的正样本总数,精确率衡量的是准确性: 召回率=TP/(TP+FN),TP+FN是真实的正样本总数,召回率衡量的是覆盖率

磁盘 I/O 性能监控指标和调优方法

在介绍磁盘 I/O 监控命令前,我们需要了解磁盘 I/O 性能监控的指标,以及每个指标的所揭示的磁盘某方面的性能.磁盘 I/O 性能监控的指标主要包括: 指标 1:每秒 I/O 数(IOPS 或 tps) 对于磁盘来说,一次磁盘的连续读或者连续写称为一次磁盘 I/O, 磁盘的 IOPS 就是每秒磁盘连续读次数和连续写次数之和.当传输小块不连续数据时,该指标有重要参考意义. 指标 2:吞吐量(Throughput) 指硬盘传输数据流的速度,传输数据为读出数据和写入数据的和.其单位一般为 Kbps,