原文链接: Using Page Speed

使用 Page Speed

1. 运行 Page Speed

   在运行Page Speed这个工具时, 它会基于页面的状况生成分析结果. 为了确保最精确的分析结果, 你最好在页面完全载入完成后再运行Page Speed. 否则, Page Speed无法分析那些还没有载入的资源的情况.

   或者你可以选择激活 当载入完成后自动运行选项 而让Page Speed在任何页面载入完成后自动进行分析. 具体可参照下文中 高级选项 .

   如何使用 Page Speed 对页面进行分析:

   1. 运行Firefox.
   2. 选择 工具 > Firebug > 打开Firebug.
   3. 在FireBug窗口中, 选择 Page Speed 页签.
   4. 访问你需要进行分析的页面. 等到浏览器状态栏里显示 完成 并且进度条消失的时候开始使用Page Speed. 如果页面上因为有流媒体视频而没有显示 完成 信息的情况下, 等到视频开始播放时就可以开始使用Page Speed了.

      

   5. 点击 性能分析(Analyze Performance). 当页面分析完成时, Page Speed会显示 网页性能最佳实践 的列表和当前页面针对每项结果的得分, 结果是按照当前页面的重要性和优先级排列的.

      

   6. 接下来就可以做以下这些事情了:

      1. 点击打开任意规则来看可改进的建议.
      2. 点击任何规则的标题来看针对该规则的文档.
      3. 点击 资源 展示当前页面引用的资源的详细列表.
      4. 选择 导出 > 生成JSON文件 把分析结果导出成为JSON格式的文件.
      5. 选择 导出 > 发送得分到www.showslow.com 把分析的得分传送给show slow网站, show slow是一个开源的基于web的工具, 用来收集从Page Speed获得的性能参数. 如果想知道更多关于发送给Show Slow的数据的信息的话, 可以参考Page Speed开源项目的 minimalBeacon页面上的Beacon文档.

2. 对于Page Speed性能得分的注解

   对于每个规则, Page Speed都会给出针对性的改进建议, 并且会给当前页面一个基于一些因素的算法的”分数”.当然它也会给出当前页面的一个整体性能得分.

   对于每个规则得分的注解

   对于每个规则, 都会有两种得分: 一个100以内的数字分数; 和一个绿, 黄, 红的颜色分数.数字分数是一种原始得分, 用来标注当前页面在当前规则下的表现, 得分基于某些量化的维度, 例如, DOM元素的总数, 或者下载的文件数. 颜色分数是综合了数字得分和该条规则的权重, 这是一个综合了潜在影响因素和实施难度的复合参数.这就意味着没有数值得分和颜色得分之间一对一的对应关系. 比如, 一个得分是0/100的情况转换到颜色得分是是一个黄色的颜色分值, 如果该条规则的权重没有那么高的话. 因此, 你应该总是以颜色分数作为更权威的判断依据.

   以下是颜色得分的说明:

   • 高优先级. 这些建议意味着相对小的开发成本就能换来非常大的潜在性能提升. 你应该首要关注这些条目.
   • 中优先级. 这些建议意味着较小的产出或者比较大的实施难度, 你应当次要关注这些条目.
   • 状况良好的或者低优先级的. 如果有显示相关建议的 (显示一个+号), 那他们或许只有非常小的产出. 你可以在你完成了更高优先级的建议之后再来审视这些条目.
   • 仅仅只是些信息.可能是这些条目无法在当前页面应用或者在测试过程中出了些小问题.

     提示: 如果你测试的结果中有大量的信息的话, 很可能是因为你在完全载入前就试着分析这个页面了. 这时可以点击 重新分析 来重新进行页面分析.

   对于总体得分的注解

   Page Speed还给出了一个总体的数字得分和颜色得分. 数字得分是当前页面所有数字得分的结算结果, 基于所有规则的权重(包括和蓝色的信息, 就是没有得分的条目). 颜色得分是基于绿,黄,红色结果的数量根据一定规则计算出来的.

3. 记录活动

   Page Speed 活动面板展示了所有浏览器活动的时间线, 包括了网络事件和JavaScript处理. 你可以根据这个面板结合Page Speed的性能分析结果和真实的计时数据进一步分析你的页面.

   注意: Page Speed活动的特性和HTTPWatch不兼容. 在使用它之前, 要保证禁用掉HTTPWatch: 在Firefox中, 可以通过 工具 > 附加组件 , 从附加组件的列表中, 点击禁用HTTPWatch.

   注意Page Speed 活动面板会显示浏览器所有线程的浏览器事件, 那我们可以通过下面的步骤让它只记录单页面的活动.

   如何记录单页面活动:

   1. 启动(重启) Firefox并关闭所有的页签.
   2. 清除浏览器缓存.
   3. 通过在地址栏输入 about:blank 来访问一个空白页面以清除所有会被记录的浏览器活动.
   4. 选择 工具 > firebug > 打开firebug.
   5. 在Firebug窗口中, 选择 Page Speed活动 页签.

      

   6. 点击 记录活动 .
   7. 访问你想要记录的页面, 事件就已时间线的形式显示出来了.

      

   8. 任何时间想要查看结果的话, 只需要点击 停止 让移动的时间线停止下来.

      提示: 你也可以使用键盘的快捷方式来停止记录: Linux和Mac OS X上用Ctrl+R, Windows上用Alt+R.

      提示: 鼠标移动到资源信息上可以通过信息提示的方式查看资源的绝对地址.

   9. 要了解展示出来的时间的更多信息请继续往下看.

   Page Speed活动事件的注解

   活动面板根据时间线展示浏览器事件, 当前页面所需要的每个资源都会被记录. 以10毫秒的频率记录事件. 如果浏览器事件没有使用完整的10毫秒的话, 事件会以比较淡的阴影展示. 在时间线中被展示成没有颜色的区块意味着浏览器正在处理其他的过程, 比如DOM和CSS的解析, Flash ActionScript过程, 绘制, 操作系统时间等等.

   下面的表格详细的描述了事件类型.

   网络事件		描述
   	DNS	浏览器正在执行DNS查询资源的过程
   	Wait	浏览器正在等待建立和网络服务器之间的网络(TCP)连接. 因为浏览器限制了连接的上限, 并一直处于打开状态, 如果到达了限制的上限的话, 那浏览器就必须等候有一个连接关闭才能重新打开一个连接. (如果想了解更多的浏览器连接信息, 可以参考后续的跨域名并行下载.) 这个事件显示了浏览器等候其他事件结束的时间.
   	Connect	浏览器和网络服务器之间正在建立网络(TCP)连接. 这个事件只会出现在产生新的连接时, 而不会出现在连接被重用时.
   	Send	浏览器已经发送了HTTP请求, 仅仅是GET类型的请求会被展示.
   	Connected	浏览器正在等候网络数据传输. 浏览器结束TCP连接时这个事件结束. 如果资源显示了漫长的已连接状态就意味着可以通过优化来减少荷载大小以获得更好的收益, 比如压缩.
   本地事件		描述
   	Cache Hit	浏览器成功的在缓存中定位到资源.
   	Data Available	数据可被浏览器解析. 当网络服务器大量返回数据时, 如果数据是个很大的文件时, 很多这样的事件会展示在单个资源上.
   	Paint	浏览器正在渲染页面上的元素.
   	JS Parse	浏览器正在解析JavaScript. 这个事件能够和其他事件重叠. 当这种情况发生时, 这个事件以子行的形式在这个资源上展示.
   	JS Execute	浏览器正在执行 JavaScript. 这个事件能够和其他事件重叠. 当这种情况发生时, 这个事件以子行的形式在这个资源上展示. 如果你能看到在JS解析和JS执行之间有固定的延迟, 这意味着这个资源中包含的方法可能是延时的.

   收集完整的JavaScript方法执行信息

   默认状态下, Page Speed活动收集浅调用图, 在每个调用堆栈的地步记录了方法的进入和退出的时间. 这样把监控的影响最小化, 改进了时间线的精确程度.

   但是, 你可能想要收集完整的记录了所有方法调用的执行图. 那 显示未被执行方法 的选项就可以满足你的要求:

   1. 获取一个未被调用方法的列表. 有些方法被声明(解析)但是在你中断记录之前都没有被调用.
   2. 获取一个可延迟的方法列表. 有些方法在你中断记录之前被调用了, 它会显示每个方法实例化的时间和初次调用的时间之间的差值, 以从最大到最小的方式排列.
   3. 在Linux和Mac OS X系统下, 可以把完整的方法调用树, 包含了解析和声明的时间的信息以Protocol buffer的格式保存到磁盘上的文件中, 那么你可以对这些调用图进行更深入的分析. 可以看后续的 活动面板保存文件 以获得更多的关于文件的格式和如何从中获取数据的方法的信息.

   比如, 下面的截图是摄于7800ms, 并且展示了在那个点上没有被调用的方法的列表, 以及它们被解析的时间:

   

   下面的截图摄于7800ms, 显示了在那个点上已被调用了的方法的列表, 按照从最大到最小延迟的顺序展示; 就是这些方法从解析到第一次调用的时间差从最大到最小的排序.

   

   如何记录单个页面的活动和收集完整的执行图:

   1. 启动(重启)Firefox并且关闭所有的页签.
   2. 清除浏览器的缓存.
   3. 通过在地址栏输入 about:blank 来访问一个空白页面以清除所有会被记录的浏览器活动.
   4. 选择 工具 > firebug > 打开firebug
   5. 在Firebug窗口中, 选择 Page Speed活动 页签, 点击下拉箭头来展示一个选项弹出菜单.
   6. 在弹出菜单中, 选择 完整执行视图.
   7. 点击 记录活动.
   8. 访问你想要记录的页面, 事件以时间线的形式被显示.

   9. 在任何时候, 做以下任意事情(会中断记录):

      • 点击 显示没有执行的方法 来展示还没有被执行到的方法列表.
      • 点击 显示延迟的方法 来展示被执行了但是延迟了的方法列表.

        提示: 把鼠标移动到 原型 列通过提示框的形式可以看到方法的完整定义.

      • 点击 保存 将方法的完整调用数通过protocol buffer格式保存到文件(在window下无效)

   查看绘制快照

   从Page Speed 1.3(Firefox 3.5)开始, 活动面板还能够展示出浏览器如何逐步渲染一个页面的快照. 当绘制快照是激活状态的, 并且你开始记录活动时, Page Speed用黄色高亮显示出它已经渲染完成的元素. 以灰色显示的元素表示的是在当前窗口下没有滚动滚动条的情况下看不到的那部分元素. 你可以用这些快照来帮助解决逐步渲染中产生的问题, 优化页面上元素的渲染. 如果想知道更多相关信息的话, 可以查看 使用Page Speed 活动 捕捉和分析浏览器绘制事件.

   例如, 下面的截屏显示了文字和图标元素最先被绘制, 然后是表单输入域, 在然后是表单的按钮:

   

   如何记录活动和查看绘制事件:

   1. 启动(重启)Firefox并且关闭所有的页签.
   2. 清除浏览器的缓存.
   3. 通过在地址栏输入 about:blank 来访问一个空白页面以清除所有会被记录的浏览器活动.
   4. 选择 工具 > firebug > 打开firebug.
   5. 在Firebug窗口中, 选择 Page Speed活动 页签, 点击下拉箭头来展示一个选项弹出菜单.
   6. 在弹出菜单中, 选择 绘制快照.
   7. 点击 记录活动.
   8. 访问你想要记录的页面, 事件以时间线的形式被显示. 绘制快照在右边以一个分离的面板展示.
   9. 在任何时候, 想要查看结果, 点击 停止 来中断时间线.

4. 使用高级选项

   选择 Page Speed 页签, 点击下拉箭头展示一个选项弹出菜单, 在那里可以看到 Page Speed 的附加选项:

   

   其中的每一项将在下面进行解释:

   页面加载完成时自动运行

   这个选项可以让 Page Speed 能够在页面加载完成的同时开始自动分析. 只要这个选项是被激活的, Page Speed会在后续访问的每个页面中自动执行.

   如何让Page Speed 在页面载入完成时自动运行:

   1. 打开Firefug, 选择 Page Speed 页签, 然后点击下拉箭头展示一个选项弹出菜单.
   2. 在弹出菜单中, 选择 页面加载完成时自动运行.
   3. 访问你想要分析的页面, 当页面完成加载时, Page Speed 就开始自动分析了.

   记录延迟的JavaScript

   这个选项用来测试延迟加载的JavaScript, 它一般是默认关闭的. 这个测试从Firefox的JavaScript调试器中收集JavaScript覆盖的范围内检查当前页面中在 onload 事件触发时哪些方法被调用,哪些没有. 调试器服务在单块全局内存中跟踪完整的Firefox Session的状态, 这个状态不是基于每个页面的加载, 也不会在页面被重载时清除. 这意味着你在firefox 一次会话中第一次访问这个页面时, 记录器会精确的算出的得分, 但是如果你继续使用这个页面, 额外的JS被载入和执行, 记录器就不会后续报告精确的结果了. 而且, 如果多个页面引用了同一个外链JS文件的话, 记录器只会报告其中第一页面的结果.

   为了保证你的性能得分的精确性, 你必须在刚打开Firefox时就要启用它:

   1. 启动(重启) Firefox.
   2. 选择 工具 > firebug > 打开firebug.
   3. 在firebug窗口中, 选择 Page Speed 页签, 然后点击下拉箭头展示一个选项弹出菜单.
   4. 在弹出菜单中, 选择 记录延迟的JavaScript.
   5. 访问你想要分析的页面.
   6. 当页面完成加载后, 点击 分析性能 .
   7. 想要在另一个页面下使用记录器的话, 关闭Firefox并重启程序.

      注意: 这个选项会让Firefox变慢甚至会让Firefox宕机, 特别是你想要用多页签浏览. 我们建议直到你准备好使用它再激活它, 并且在用完后马上禁用它.

   保存优化好的文件

   Page Speed会在分析页面的时候自动优化页面上引用的 JavaScript, CSS以及图片. 默认状态下, 优化好的文件会保存到如下目录:

   • Linux: /tmp/page-speed-[css | javascript | images]/
   • Windows: C:\Documents and Settings\username\Local Settings\Temp\page-speed-[css | javascript | images]\
   • Mac OS X: /Users/username/Library/Caches/page-speed=[css | javascript | images]/

   但是, 你可以更改Page Speed保存文件的路径:

   1. 打开Firebug, 选择 Page Speed 页签, 然后点击下拉箭头展示一个选项弹出菜单.
   2. 在弹出菜单中, 选择 保存优化后的文件到 , 然后从预定义选项中选择一个目录, 或者选择 选择一个自定义路径 来制定一个路径.

   设置用户代理

   Page Speed是通过页面在Firefox中载入来评判得分的, 但是, 为了适应更多的浏览器行为, 很多网站针对用户自身的浏览器提供了不同的内容. 网络服务器会根据浏览器发送的每个请求中的用户代理字符串来检查发出请求的浏览器. 如果你的网站会根据用户代理来输出不同的内容, 而你又想要Page Speed针对不同浏览器来给出评定, 那你可以使用 设置用户代理 选项.

   注意一个页面是在其他浏览器下工作,那他不一定能够在Firefox下工作, 所以可能存在的情况是你使用不同的用户代理记录下的记录不一定是用户端使用同一个用户代理的浏览器所看到的结果. 但是, 通常情况下, 这些差异只是装点门面用的, 所以 Page Speed给出的建议同样适用.

   如何选择不同的用户代理:

   1. 打开Firebug, 选择 Page Speed 页签, 然后点击下拉箭头展示一个选项弹出菜单.
   2. 选择 显示所有用户代理 来看看其他的用户代理选项.
   3. 在弹出窗口菜单中, 选择你想要测试的用户代理.
   4. 当页面载入完成后, 点击 分析性能.
   5. 要先择其他的用户代理, 请重复第2到第4步.

   注意: 用户代理选项在某些页面会造成Firefox宕机. 所以我们推荐在基础应用中保留默认的设置.

5. 卸载 Page Speed

   如何卸载Page Speed:

   1. 在Firefox中, 选择 工具 > 附加组件.
   2. 再出现的窗口中选择 Page Speed 并点击 卸载.
   3. 重启Firefox.

对这个问题确实比较好奇，看了看YUI2和jQuery关于DOM ready实现的部分源码。在IE实现DOM Ready基本都是用Diego Perini提出的方法：http://javascript.nwbox.com/IEContentLoaded/

但是jQuery的开发者已经意识到IE浏览器有时存在onload执行的比DOM Ready快的问题，因为这样确实会出现风险。jQuery是这么解决的，我节选了部分解决这个问题的jQuery代码(版本-1.4.2)：

DOMContentLoaded = function() {

if ( document.readyState === “complete” ) {

document.detachEvent( “onreadystatechange”, DOMContentLoaded );

jQuery.ready();

}

};

document.attachEvent(“onreadystatechange”, DOMContentLoaded);

YUI没有这样做，我估计是因为效率问题，上面的代码虽然让domready执行的比window.onload快，但是因为绑定了onreadystatechange事件，效率会低一点。

而jQuery采用了更加安全的策略，慢就慢一点，安全一点更重要。如果在使用YUI2的时候确实遇到了这个安全问题，我们也可以牺牲一点效率，修改一下YUI的源码。

终于搞清楚了，又是一个需要权衡的问题。

但是我也抛出一个我没有想明白的问题，YUI2里面为什么不去尝试

document.documentElement.doScroll(‘left’);来判断domready，而是先要在超空间先创造一个p节点，然后再doScroll，domready以后再把这个p节点清空掉，这样做有什么好呢？为什么不采用jQuery和Diego Perini的做法呢？个人觉得创造一个p节点，再释放掉效率更低呀。

我承认我并不经常想这个问题……我们写的css的效率是怎么样的呢，浏览器渲染的速度又如何呢？

这是应该是浏览器开发者应该关心的(页面加载更快，用户就会更愉快)。Mozilla有一篇文章： about best practices . Google 当然也很关心这个问题，他们也有这样一篇文章：Optimize browser rendering 。

让我们了解下他们主要倡导的东东，然后讨论他们的实用性。

从右到左

浏览器如何读取你的CSS选择器有一个很重要的原则，那就是它们从右到左读取。这意味这像 ul > li a[title="home"] 这样的选择器，a[title="home"] 将是最先被读取的。这一部分通常被称为 “key selector” （可否称为“目标选择器” -_-!）选择器的最后一部分，也是被选择的标签。

ID’s 是最有效率的，通用符是最慢的

有四种目标选择器：ID, class, tag和通用符。看下他们各自的效率如何:

#main-navigation { } /* ID (最快) */
body.home #page-wrap { } /* ID */
.main-navigation { } /* Class */
ul li a.current { } /* Class *
ul { } /* Tag */
ul li a { } /* Tag */
* { } /* Universal (最慢) */
#content [title='home'] /* Universal */

然后我们结合从右到左和目标选择器的概念，我们可以知道下面这个选择器并不高效：

#main-nav > li { } /* 看着很快实则很慢 */

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

不要用标签修饰

死也不要像下面这样干：

ul#main-navigation { }

ID’s 是唯一的，所以不需要用标签修饰，这只会让它更低效。
如果你可以避免的话，也不要用它修饰 class 。class 不是唯一的，所以理论上你可以把它用在不同的标签。如果你愿意的话，你可以用标签控制不同的样式，这样你可能需要标签修饰（比如：li.first），但这样做的人很少，所以，don’t .

绝对没有比用后代选择器更糟糕的做法了
David Hyatt:
后代选择器是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放弃语义和可维护性。

Thanks to Jason Beaudoin for emailing me about the idea. If anyone knows more about this stuff, or if you have additional tips that you use in this same vein, let’s hear it!

顺便提一下，因为CSS选择器被很多javascript库使用，上面提到的东东仍然适用，ID选择器还是最快的，后代选择器和类似的东东比较慢。

PS：看谁还敢用N多的后代选择器。。。还有反对我用ID的。。。哇哈哈。。。

实现1
  String.prototype.trim = function() {
    return this.replace(/^\s\s*/, ”).replace(/\s\s*$/, ”);
  }
看起来不怎么样，动用了两次正则替换，实际速度非常惊人，主要得益于浏览器的内部优化。一个著名的例子字符串拼接，直接相加比用Array做成的StringBuffer还快。base2类库使用这种实现。

实现2
  String.prototype.trim = function() {
    return this.replace(/^\s+/, ”).replace(/\s+$/, ”);
  }
和实现1很相似，但稍慢一点，主要原因是它最先是假设至少存在一个空白符。Prototype.js使用这种实现，不过其名字为strip，因为Prototype的方法都是力求与Ruby同名。

实现3
  String.prototype.trim = function() {
    return  this.substring(Math.max(this.search(/\S/), 0),this.search(/\S\s*$/) + 1);
  }
以截取方式取得空白部分（当然允许中间存在空白符），总共调用了四个原生方法。设计得非常巧妙，substring以两个数字作为参数。Math.max以两个数字作参数，search则返回一个数字。速度比上面两个慢一点，但比下面大多数都快。

实现4
  String.prototype.trim = function() {
    return  this.replace(/^\s+|\s+$/g, ”);
  }
这个可以称得上实现2的简化版，就是利用候选操作符连接两个正则。但这样做就失去了浏览器优化的机会，比不上实现3。由于看来很优雅，许多类库都使用它，如JQuery与mootools

实现5
  String.prototype.trim = function() {
    var str = this;
    str = str.match(/\S+(?:\s+\S+)*/);
    return str ? str[0] : ”;
  }
match是返回一个数组，因此原字符串符合要求的部分就成为它的元素。为了防止字符串中间的空白符被排除，我们需要动用到非捕获性分组（?:exp）。由于数组可能为空，我们在后面还要做进一步的判定。好像浏览器在处理分组上比较无力，一个字慢。所以不要迷信正则，虽然它基本上是万能的。

实现6
  String.prototype.trim = function() {
    return this.replace(/^\s*(\S*(\s+\S+)*)\s*$/, ‘$1′);
  }
把符合要求的部分提供出来，放到一个空字符串中。不过效率很差，尤其是在IE6中。

实现7
  String.prototype.trim = function() {
    return this.replace(/^\s*(\S*(?:\s+\S+)*)\s*$/, ‘$1′);
  }
和实现6很相似，但用了非捕获分组进行了优点，性能效之有一点点提升。

实现8
  String.prototype.trim = function() {
    return this.replace(/^\s*((?:[\S\s]*\S)?)\s*$/, ‘$1′);
  }
沿着上面两个的思路进行改进，动用了非捕获分组与字符集合，用?顶替了*，效果非常惊人。尤其在IE6中，可以用疯狂来形容这次性能的提升，直接秒杀火狐。

实现9
  String.prototype.trim = function() {
    return this.replace(/^\s*([\S\s]*?)\s*$/, ‘$1′);
  }
这次是用懒惰匹配顶替非捕获分组，在火狐中得到改善，IE没有上次那么疯狂。

实现10
  String.prototype.trim = function() {
    var str = this,
    whitespace = ‘ \n\r\t\f\x0b\xa0\u2000\u2001\u2002\u2003\u2004\u2005\u2006\u2007\u2008\u2009\u200a\u200b\u2028\u2029\u3000′;
    for (var i = 0,len = str.length; i < len; i++) {
      if (whitespace.indexOf(str.charAt(i)) === -1) {
        str = str.substring(i);
        break;
      }
    }
    for (i = str.length – 1; i >= 0; i–) {
      if (whitespace.indexOf(str.charAt(i)) === -1) {
        str = str.substring(0, i + 1);
        break;
      }
    }
    return whitespace.indexOf(str.charAt(0)) === -1 ? str : ”;
  }
我只想说，搞出这个的人已经不是用牛来形容，已是神一样的级别。它先是把可能的空白符全部列出来，在第一次遍历中砍掉前面的空白，第二次砍掉后面的空白。全过程只用了indexOf与substring这个专门为处理字符串而生的原生方法，没有使用到正则。速度快得惊人，估计直逼上内部的二进制实现，并且在IE与火狐（其他浏览器当然也毫无疑问）都有良好的表现。速度都是零毫秒级别的。

实现11
  String.prototype.trim = function() {
    var str = this,
    str = str.replace(/^\s+/, ”);
    for (var i = str.length – 1; i >= 0; i–) {
      if (/\S/.test(str.charAt(i))) {
        str = str.substring(0, i + 1);
        break;
      }
    }
    return str;
  }
实现10已经告诉我们普通的原生字符串截取方法是远胜于正则替换，虽然是复杂一点。但只要正则不过于复杂，我们就可以利用浏览器对正则的优化，改善程序执行效率，如实现8在IE的表现。我想通常不会有人在项目中应用实现10，因为那个whitespace 实现太长太难记了（当然如果你在打造一个类库，它绝对是首先）。实现11可谓其改进版，前面部分的空白由正则替换负责砍掉，后面用原生方法处理，效果不逊于原版，但速度都是非常逆天。

实现12
  String.prototype.trim = function() {
    var str = this,
    str = str.replace(/^\s\s*/, ”),
    ws = /\s/,
    i = str.length;
    while (ws.test(str.charAt(–i)));
    return str.slice(0, i + 1);
  }
实现10与实现11在写法上更好的改进版，注意说的不是性能速度，而是易记与使用上。和它的两个前辈都是零毫秒级别的，以后就用这个来工作与吓人。

下面是老外给出的比较结果，执行背景是对Magna Carta 这文章（超过27,600字符）进行trim操作。

实现 Firefox 2 IE 6
trim1 15ms < 0.5ms
trim2 31ms < 0.5ms
trim3 46ms 31ms
trim4 47ms 46ms
trim5 156ms 1656ms
trim6 172ms 2406ms
trim7 172ms 1640ms
trim8 281ms < 0.5ms
trim9 125ms 78ms
trim10 < 0.5ms < 0.5ms
trim11 < 0.5ms < 0.5ms
trim12 < 0.5ms < 0.5ms

原文链接：http://blog.stevenlevithan.com/archives/faster-trim-javascript

注意本文非翻译，只是根据其中提到的trim函数实现发表自己的想法，想知道原作者说什么请看原文。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/cheng5128/archive/2009/09/18/4613763.aspx

　　最近看到淘宝的招聘上多出一个职位叫做设计质量保证(DQA)，粗看他的名称类似于风险质量管理的岗位，但又落在设计团队中。他的职务内容如下：

　　1、管理设计规范，流程，各种机制;并保证过程的有效实施，同时组织对内培训

　　2、为项目过程的事实提供咨询和指导

　　3、按计划执行过程的审计，跟踪协调质量问题的解决

　　4、根据度量指标，建立度量体系，收集过程数据，分析度量指标的达成情况

　　5、收集过程改进建议，制定改进方案，持续开展过程改进工作

　　6、熟悉软件功能，具有良好的文档写作能力、沟通能力和协调能力

　　淘宝的设计质量保证招聘页面，点此应聘

　　从他的职务内容可以看出，对设计负责是客观的数据和指标，而并非是主观的资历。当然要能够制定规范、流程以及各种机制也一定要实际经验的人才能领悟其中的奥妙，昨天部门内部做了一次分享，我们老大觉得只要在公司的SQA(风险质量管理)的流程中加上一步来规范设计便可以起到管理的效果，但是SQA并非设计人员，他对里面的各个环节的把控没有一个亲身体验的过程，他很难去融入到每个环节中去。要做到一个DQA必须要有设计经验，至少要能够把设计流程中的每个角色都经历一次，才能有管理的能力。一个DQA不仅要管理流程并要不断创新，让流程中的问题越来越少。沟通文化是项目管理中必不可少的文化，但是一个好的流程管理可以避免沟通的浪费，最到效益最大化。既然是管理那肯定离不开数据跟踪和分析，这又要求DQA对数据的敏感性和分析能力，并且有数据挖掘的能力。

　　产品开发是一个环：想法(产品经理)—>策划(交互设计师)—>实施(视觉设计、前端开发、系统开发)—>测试、发布—>新想法(产品经理)…，称为循环式生命周期，这种方式有利于不断改进和突破创新。但是在很多情况下这个环会变成一条直线，称为终结式生命周期，这种方式不利于设计师提升产品价值，而且这种对产品始终不负责任的方式,让产品进入“有娘生没娘养”的地步。这就是缺乏设计质量管理的结果。产品就像一个点，分布在公司中，设计师如果过多的注重点就很难去考虑面，如此继续会导致恶性循环。

　　那怎么样才能做一个好的DQA来保证设计质量呢?从设计角度来讲可以分为两个部分：

　　一、产品设计：

　　1、在产品设计前期的用户分析中，交互设计师要根据产品特征建立相应地有效用户模型，并要符合产品用户模型等式：

　　其中有效用户模型(Available User Model)是产品上线后对于使用用户的一个数量和特征的描述，设计用户模型(Designed User Model)是用户测试工程师建立的理想用户数量和特征描述，产品用户模型(Producted User Model )是产品经理所定义的预期用户数量和特征描述。等式中将设计用户和产品用户相加除以二的目的是为了得出交集，不仅从数量上给出更贴近设计要求和商业目标，而且从特征描述上能够更有针对性地进行参考设计。

　　DQA工作内容：这一步的DQA主要是对用户模型的管理和完善，充分协调交互设计师、产品经理和用户测试工程师之间的沟通问题，降低沟通成本，并且做好用户模型分类存档的工作。一个好的交互设计师会不断积累用户特征，并会给出和完善不同方案下的用户模型。(这个可以做成一个搜索引擎，将条件设置为产品目标人群，摘录设置为用户生理特征，内容包括用户的生理心理活动和特征以及典型用户脚本)

　　2、在友好分析(亦称为竞争对手分析)中，交互设计师要针对新产品的同行竞争者进行分析，并给出关键设计数据，从而使设计更有目的性。

　　DQA工作内容：这一步的DQA主要是管理关键设计数据并形成一个库，便于二次使用。

　　3、在故事板等流程图设计的时候，交互设计师所做的就是将有效用户模型中的用户脚本进行编译成为一个可用性流程，这一步是为前期分析和后期设计做一个承上启下的作用，也是关键步骤。很多设计师并不关注这一步，但其实在设计的时候我们往往都会在头脑中过一遍这个流程，之所以要写出来也是为了保证产品设计质量(避免遗漏等问题)、提高二次利用效率。故事板还有个作用是通过故事形式的“起承转合”让设计师更多地去探索如何让用户去使用，如何让用户用得顺，如何让用户喜欢用的方法。

　　DQA工作内容：这一步DQA主要是要把故事板等流程图进行整理归类，并且给出用户脚本的度量指标，并预估整个设计过程中出现的流程和模块问题，这里谈及的模块是指流程模块间的配合，比如A流程中有B\C\D三个模块，那个DQA要根据项目需要对B\C\D进行模块分解，如果B模块是已经有现成的，那么直接给到交互设计师即可;如果C模块是现成的，但是要根据现有产品进行改良，那么DQA要根据改良目的和方法和交互设计师进行沟通，并协调整个设计团队间的改良工作。

　　4、在实施过程中，线框图的设计要求精准。管理这块内容的时候需要最仔细，因为往往这就是产品的雏形，如果最终产品的样子和线框图中描述的大相径庭，那么这个设计肯定是出了问题的，设计质量也是最差的。在我的设计中，我要求线框图必须和产品最终样子是基本一致，甚至连每个元素中的间距和排布都要完成，当然色彩上应当交给视觉设计师去把握(线框图是黑白灰的表述方式)。所以这一步也要求交互设计师一定要有坚实的视觉基础和实现能力，并且对前端开发有深入的了解和判断(有些设计天花乱坠，前端开发工程师叫苦不迭，甚至是影响了整个产品的实际体验效果)。

　　DQA工作内容：这一步中DQA主要是把握需求变更的问题，解决多方沟通和确定的时间和方式，从项目本身的利益出发使工作效率最大化。还有就是要整理每个实施阶段出现的问题和结果，并提交反馈给相应的团队进行补丁制作(Bug Fix)。例如视觉设计师觉得有必要突破原有规范进行创新型设计，那么在完成设计之后DQA要将结果保存归类并提交给设计研究的流程中做成一个新的视觉场景规范。

　　5、最终产品的测试阶段的设计质量管理更是整个质量的关键步骤，他要掌握测试Bug的数量并且和设计质量预估目标中的数据进行比较，才能够得出真正设计师应该注意的问题，并反馈给设计师进行二次确认。

　　DQA工作内容：这一步DQA主要是把问题列表和实际情况进行对比审计，得出修改意见和实施方案，以最快的速度完成Bug的修复和产品的上线。

　　6、大家可能觉得这样已经结束了，其实还有一步就是上线之后对于产品的数据和用户反馈的跟踪也是设计质量保证中必不可少的步骤，这样也保证了产品既有娘生也有爹养。

　　DQA工作内容：这一步也是DQA的一个日常运营的工作，他要定期检查线上每个产品的运行情况、监视反馈数据，并进行跟踪回报，得出新的设计建议和设计流程改进方案，为下次工作做好预估能力的积累。

　　二、设计研究

　　1、在交互研究中交互设计师要针对实际项目中的经验教训结合设计质量保证的反馈进行设计的创新研究，从有效用户模型、用户脚本和创新性设计等方面去提高自身的设计能力。

　　2、视觉设计师更多在前期的视觉规范制定和创新设计中起到决定作用，视觉设计师在实际项目中所碰到的问题和创新问题都要在视觉研究中有所体现，并且设计质量保证也要进一步把控研究成果。

　　3、前端研究主要是让前端开发工程师能够将前端开发的代码进行整理打包成为可二次利用的插件，不仅提高效率而且也提升了自身实力。

　　4、产品线上研究，这一步是现在很多公司都没有的一步，应该说是都交给了其他部门去研究的一步。其实作为“生母”的设计师来讲，关注线上产品才能有更多好的idea的产生，设计质量保证也要进行配合管理，让产品的输入输出通路能够打通，不再让研究始终只是研究。

　　在设计研究中，DQA扮演的往往是指引和提供数据方向的角色，他更多的是让所有设计师对设计流程能够达成一致，在以数据为前提下了解每个人的个性和合作方式并合理安排团队成员进行设计研究和产品开发。

　　三、DQA的其他职责

　　DQA的还有个职责是制定设计流程，之前我也写过将流程模块化的管理方案，大家有兴趣可以去看看。

　　要管理好一个团队很难，但是只要获得人心，一切都会很顺利。但是要管理好一个设计团队间的协作和流程，单单靠人心和资历都是没用的，一切以数据和现状分析为导向，加入适当的协调才能真正让一个团队的设计质量有大幅度的提高，才能把产品效益最大化。

参与人员: Sourcing和Wholesale今天在公司的所有同学

会议进程:

1. 公布2010年Q1前端同学Bug情况, 总数计1900分, 主要引起Bug产生的几大方面:
   • a. 多彩秀(富文本编辑器)产品: 682.57
   • b. minisite产品(sourcing): 541.51
   • c. 前端文件编码问题: 538.56
2. 几大问题剖析:
   • a. 多彩秀:
     • 多彩秀团队资源有限, 无后续更新修复资源, 导致产品不完善而造成最基础的产品级别问题
     • 多彩秀产品上线产品规划的问题, 为对相应风险有足够的预估以及风险对策设立, (对历史数据的处理存在非常大的风险)
     • 多彩秀产品上线时资源没有保障, 开发测试环节缺失严重
   • b. Minisite:
     • minisite本身架构古老, 无法在延展性上符合目前的业务复杂性, 且结构复杂, 不利于维护与测试
     • minisite相应的需求只考虑自身模块的功能实现, 相关模块的牵扯风险预估不到位
     • 测试不彻底
   • c. 文件编码问题:
     • 缺失相关的规范
     • 测试不充分
     • 国际站的文件编码混乱
3. 问题总结及相应的行动计划:
   • 风险预估不到位
   • 责任感不强
   • 代码质量检测及测试缺失
   • 风险预估保障: 专家评估
     找熟知的人进行相应风险的评估, 确保风险预估的完整性
   • 风险预估结果的推动:
     预估风险的知晓, 风险不可控的应对策略的向上走机制
   • 代码Review:
     保证在实现层面的代码质量问题
   • 测试环节加强: ?
   • 从问题出发的架构机制保障及推动

例1：

例2：

2、使用具有语义的标签

3、尽量减少使用的<div>标签

例1：

例2：

4、使用缩进格式化代码

5、对代码注释使用结束标记

结论：养成好的编码习惯，尽量编写简洁的符合语义的代码，会无形中提高搜索引擎对你网页的可访问性！当然对SEO会起到事半功倍的效果！

许多JavaScript框架都带有大量的实用函数，这些函数使得应用JavaScript开发应用程序更加容易。这篇文章有太多内容需要补充，所以我将讨论大多数框架中更为引人注目的函数中的一个。

如果你曾经使用过JavaScript数组，你可能对使用循环来迭代数组操作其值非常熟悉。例如，想想清单2的代码：

清单2：迭代JavaScript数组的传统方法

var fruit = ['apple', 'banana', 'orange'];
for(var i = 0; i < fruit.length; i++) {
alert(fruit[i]);
}

清单2中的代码没错，但有点麻烦。大多数JavaScript框架包括each功能，它为数组中的每一个元素调用一个特定的函数。使用MooTools，用清单3中的代码可以完成清单2中相同的操作。

清单3：使用MooTools的each函数

['apple', 'banana', 'orange'].each(function(item) {
alert(item);
});

清单3中在语法上与Prototype和jQuery是相同的，YUI 和 ExtJS.略微不同。但是，当应用到hash或对象时，不同的框架语法是不同的。例如，在MooTools中，你可以使用下面清单中的代码：

清单4：对键/值对的各个对象使用MooTools的each函数

var hash = new Hash({name: "Joe Lennon", email: "<a href="mailto:joe@joelennon.ie">joe@joelennon.ie</a>"});
hash.each(function(value, key) {
alert(key + ": " + value);
});

但是，使用Prototype库，这看起来就像清单5的代码：

清单5：对键/值对的各个对象使用Prototype的each函数

var hash = $H({name: "Joe Lennon", email: "<a href="mailto:joe@joelennon.ie">joe@joelennon.ie</a>"});
hash.each(function(pair) {
alert(pair.key + ": " + pair.value);
});

每个框架包含了许多更实用的函数，通常分为String函数、 Number函数、Array函数、Hash函数、 Date函数等等。要了解更多信息，请参阅相关JavaScript框架的API手册。

在此之前，你已经看到JavaScript框架使用选择器和DOM遍历可以很容易的获得特定的元素。但是，为了改变网页上特定元素的内容和外观，你需要操作DOM并应用改变。使用纯粹的JavaScript将是一件繁重的工作，但幸运的是，大多数JavaScript框架提供有用的函数，可以很容易地做到这些。

假设你有一个ID为the-box的盒子。

<div id="the-box">Message goes here</div>

使用jQuery将其文本改变为“Message goes here”，可以很简单的这样使用：

$('#the-box').html('This is the new message!');

事实上，你可以在函数中使用HTML代码，它能被浏览器解析，例如：

$('#the-box').html('This is the <strong>new</strong> message!');

在本例中，DIV元素中的内容看起来像这样：

<div id="the-box">This is the <strong>new</strong> message!</div>

当然，在实例中你需要使用大于或小于等特殊字符，而不是指定特殊的HTML实体代码。你可以使用jQuery的text函数来代替：

$('#the-box').text('300 >200');

div元素更新后代码如下：

<div id="the-box">300 &gt; 200</div>

在上面的例子中，现有的内容被替换为新的内容。如果你只想给文本附加一些信息该怎么办？幸运的是，jQuery提供append函数达到此目的。

$('#the-box').append(', here goes message');

对原始的div作如上操作后，div元素里的内容看起来是这样的：

<div id="the-box">Message goes here, here goes message</div>

除了追加，你可以在前面追加内容，将其插入到现存内容的前面而不是后面。此外，jQuery提供的函数可以在给定元素内插入内容，要么在前要么在后。还有函数替换内容、清空内容、移除元素、克隆元素等等。

除了DOM操作函数外，JavaScript框架通常还包含几个函数操作元素的样式和class。例如，你有一个表格，当鼠标经过时高亮显示某行。你可以创建一个特殊的类名hover，你可以将该类动态的添加到某行。利用YUI你可以使用下面的代码判断该行是否拥有hover类名，有则免之，无则加之。

if(row.hasClass('hover')) row.removeClass('hover'); else row.addClass('hover');

同样，大多数JavaScript框架都拥有操作CSS的内置函数。

基于ID、元素类型、类名查找元素非常有用，但是如果你想基于它在DOM树中的位置来查找元素该怎么办？换句话说，你有一个给定的元素，你想查找它的父元素、子元素中的一个、它的上一个或下一个节点兄弟节点。例如，采用下面这段零碎的HTML代码：

清单1：HTML碎片（一个table）

<table>
<thead>
<tr>
<th>Name</th>
<th>Email Address</th>
<th>Actions</th>
</tr>
</thead>
<tbody>
<tr id="row-001">
<td>Joe Lennon</td>
<td>joe@joelennon.ie</td>
<td><a href="#">Edit</a>
                <a href="#">Delete</a></td>
</tr>
<tr id="row-002">
<td>Jill Mac Sweeney</td>
<td>jill@example.com</td>
<td><a href="#">Edit</a>
                <a href="#">Delete</a></td>
</tr>
</tbody>
</table>

tml”>
清单1使用缩进来说明其中每个元素节点在DOM树中的位置。在这个实例中，table元素是根元素，有两个子节点thead和tbody。thead元素有一个tr子节点，tr有三个孩子－－所有的th元素。tbody元素有两个tr子节点，每个tr节点有三个孩子。在上述每一行的第三个节点中进一步包含子节点，都是两个链接标记。

正如你知道的那样，你可以使用一个JavaScript框架的选择函数通过ID很轻松的选择一个元素。在这个实例中，有两个元素拥有ID，它们是ID分别为row-001和row-002的tr元素。使用Prototype库选择第一个tr，可以使用下面的代码：

var theRow = $('row-001');

在上一章，你还了解到，基于元素的类型或class使用选择器来获取元素。在这个实例中，你可以使用下面的语法来得到所有的td元素。

var allCells = $$('td');

改代码的主要问题在于它返回了每一个td 元素。但是，如果你只想得到ID为row-001的tr的所有td元素该怎么办？这正是DOM遍历函数发挥作用的地方。首先，让我们使用原型来选择ID为row-001的tr的所有的子级。

var firstRowCells = theRow.childElements();

这将返回theRow变量（你最初设置的ID为row-001的tr）所有子元素的数组。

接下来，我们假设你只想得到该行的第一个子元素。在本例中，即包含“Joe Lennon”文本的td元素。要做到这一点，使用下面的语句：

var firstRowFirstCell = theRow.down();

真简单！这个特定的使用方法等价于：

var firstRowFirstCell = theRow.childElements()[0];

也可以这样表示：

var firstRowFirstCell = theRow.down(0);

JavaScript的索引从零开始，所以上面的语句主要告知JavaScript来选择第一个子元素。要选择第二个子元素（单元格包含电子邮件地址joe@joelennon.ie），你可以这样用：

var firstRowSecondCell = theRow.down(1);

或者，你可以在兄弟节点之间浏览DOM。本例中，第二个单元格是第一个单元格的下一个兄弟节点。因此，你可以使用下面的语句：

var firstRowSecondCell = firstRowFirstCell.next();

与down()函数工作一样，选择第三个单元格可以这样使用。

var firstRowThirdCell = firstRowFirstCell.next(1);

除了使用索引来查找特定节点外，Prototype库还可以使用CSS选择器语法。在清单1中，我们要找到第二个包含 Jill Mac Sweeney’ 详细信息的链接（“删除”链接）。

var secondRowSecondLink = $('row-002').down('a', 1);

在本例中，使用$函数来查找ID为row-002的那一行，向下遍历到第二个后代a元素（锚点）。

一些框架还允许“菊花链式”的遍历功能，这意味着你可以彼此连接遍历命令。上面的例子中，Prototype库的另一种表达方式是这样的：

var secondRowSecondLink = $('row-002').down('a').next();

看看下面的例子：

var domTraversal = $('row-001').down().up().next().previous();

正如你所见，菊花链允许你连接多个DOM遍历语句。事实上，上述例子实际上最终选择ID为row-001的tr元素，所以菊花链又回到了开始的地方。