ISD Webteam的大布同学（twitter：@tc_bryanzhang）牺牲了自己大量的xx时间翻译了Page Speed系列中的Optimize browser rendering，因其blog还在重新打造当中，所以偶这里先转载了，以下是翻译全文：

优化浏览器渲染

资源被下载到客户端后，浏览器仍需加载，解释，并渲染HTML、CSS和Javascript代码。只需利用现有浏览器的特性简单地编排你的代码和页面，就可以提升客户端的性能。

1. 使用高效率的CSS选择器
2. 避免CSS expressions
3. 将样式表放在页面顶部
4. 指定图像尺寸

使用高效率的CSS选择器

概述

避免低效率的匹配大量元素的键选择器【key selectors】可以加快页面渲染。

详细信息

当浏览器解析HTML时首先构造一个内部文件树来代表所有显示的元素。然后浏览器根据标准的CSS级联、继承和排序规则，为元素指定匹配的各种样式。在Mozilla里的执行情况(可能在其他浏览器也是这样)，CSS搜索引擎通过样式规则为每个元素找到匹配的样式。该引擎由右至左评估每个规则，从最右边的选择器开始（称为“键”【Key】），并通过移动每个选择器，直到找到一个匹配或丢弃的规则。（“选择器”是应用规则的文档元素。）

基于此原则，引擎要评估的规则越少越好。所以提高渲染性能的重要一步就是删除未使用的CSS。在此之后，对包含大量的元素和/或CSS规则的页面来说，优化规则本身的定义就能够提高性能。优化规则的关键在于尽可能具体定义规则，并避免不必要的重复，让样式引擎快速找到匹配的规则,而不用花费时间查找不适用的规则。

下列各类规则被认为是低效的：

后代选择器的规则

例如：

通配选择器作为键的规则

body * {...} 
.hide-scrollbars * {...}

标签选择器作为键的规则

ul li a {...} 
#footer h3 {...} 
* html #atticPromo ul li a {...}

后代选择器是低效的，因为对于每个与键相匹配的元素，浏览器必须遍历DOM树，评估每一个祖先元素，直到找到一个匹配或到达根元素。键越不具体，需要进行评估的节点数量就越大。

子代选择器和相邻选择器的规则

例如：

通配选择器作为键的规则

body > * {...} 
.hide-scrollbars > * {...}

标签选择器作为键的规则

ul > li > a {...} 
#footer > h3 {...}

子代选择器和相邻选择器是低效的，因为对每个匹配的元素，浏览器必须评估另一个节点。这样导致规则中的每个子选择器加倍消耗。同样，键越不具体，需要进行评估的节点数量就越大。尽管如此，虽然同样效率低下，在性能方面相对后代选择器而言，它们仍然是可取的。

有多余修饰的规则

例如：

ul#top_blue_nav {...} 
form#UserLogin {...}

ID选择是唯一的定义。加上标签或类的限制只增加了多余的、引起不必要评估的信息。

对非链接元素应用:hover伪选择器的规则

例如：

h3:hover {...} 
.foo:hover {...}
#foo:hover {...} 
div.faa:hover {...}

非链接元素上的:hover伪选择器在某些情况下*会使IE 7 和IE 8 变慢。当页面没有一个严格的doctype时，IE 7 和IE 8 将忽略除了链接外的任何元素的:hover。当页面有严格的doctype，在非链接元素上的:hover将导致性能下降。

*查看bug报告http://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=391387。

建议

避免通配选择器。

允许元素继承祖先的样式，或者使用一个类来给多个元素应用样式。

使您的规则尽可能具体。

尽量使用class和ID选择器而非标签选择器。

删除多余的修饰语。

这些修饰语是多余的:

ID选择器被class选择器和/或者标签选择器限制。

class选择器被标签选择器限制(当一个类只是用于一个标签，无论如何这都是一个很好的设计实践)。

避免使用后代选择器，特别是那些指定多余祖先的。

例如，这一个规则 body ul li a {...} 指定了一个多余的body选择器, 因为所有的元素都是body标签的后代。

使用class选择器代替后代选择器。

例如，如果您需要有序列表项和无序列表项有不同的两个样式，而不是使用两个规则:

ul li {color: blue;} 
ol li {color: red;}

你可以将样式编码成两个类名并在规则中使用，例如：

.unordered-list-item {color: blue;}
.ordered-list-item {color: red;}

如果您必须使用后代选择器，尽量使用子代选择器，这最少只需评估一个额外的节点，而非中间直至祖先的所有节点。

在IE中避免对非链接元素应用:hover。

如果您对非链接元素应用:hover，请在IE7和IE8中测试并确保页面可用。如果您发现:hover导致性能问题，可以考虑条件性的为IE使用JavaScript onmouseover事件（只对IE写mouseover事件）。

附加资源

更多关于Mozilla里的高效CSS规则的细节，请看>https://developer.mozilla.org/en/Writing_Efficient_CSS。

有关CSS的完整信息，请看Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification。有关CSS选择器的资料，请看Chapter 5。

避免CSS expressions

概述

CSS表达式会降低浏览器的渲染性能；用其他方案替换它们将会改善IE浏览器的渲染性能。

**注意：**本节最佳实践只适用于Internet Explorer 5到7，它们支持CSS表达式。Internet Explorer 8放弃使用CSS表达式，而其他浏览器是不支持的。

详细信息

作为一种动态改变文档属性来响应各种事件的的手段，Internet Explorer 5引入了CSS表达式或 “动态属性”。它们由在CSS声明中的CSS属性值里嵌入JavaScript表达式构成。在大多数情况下，它们用于以下目的：

模拟其他浏览器支持但IE浏览器尚未支持的标准CSS属性。

使用比编写全面JavaScript注入式样式更小巧，更便捷的方法，来提供动态样式和高级的事件处理。

不幸的是，CSS表达式对于性能的不良影响是相当大的，因为每当有事件触发，浏览器都要重新计算每个表达式，如一个窗口改变大小，鼠标移动等。CSS表达式的低性能表现是IE 8弃用它们的原因之一。如果你在网页里使用CSS表达式，应该尽一切努力来消除它们并且使用其他方法来达到同样的功能。

建议

尽可能使用标准的CSS属性。

IE 8已高度兼容标准CSS；IE 8只有在“兼容”模式才支持运行CSS表达式，而在“标准”模式下则不支持。如果你不需要向后兼容旧版本的IE，你应该转换成标准的CSS属性来替换所有对应的CSS表达式。如需CSS属性和支持它们的IE版本的完整列表，请参见MSDN的CSS属性索引。如果你确实需要支持所需CSS属性不可用的旧版本IE浏览器，请使用JavaScript来实现等效的功能。

使用JavaScript脚本样式。

如果你正在使用CSS表达式来实现动态样式，用纯JavaScript重写它们是很有意义的，因为这样既能提高IE性能，同时在其他浏览器获得相同效果的支持。在这个由MSDN动态属性页提供的例子里，下面的CSS表达式用于在浏览器里居中一个HTML块元素，并且该元素的尺寸可以在运行时改变，每次调整窗口大小都能重新定位在浏览器中心：

下面是一个使用JavaScript和标准CSS的等价例子：

<style>
  #oDiv { position: absolute; background-color: #CFCFCF;}
</style>

<script type="text/javascript">
 // Check for browser support of event handling capability
  if (window.addEventListener) {
  window.addEventListener("load", centerDiv, false);
 window.addEventListener("resize", centerDiv, false);
  } else if (window.attachEvent) {
  window.attachEvent("onload", centerDiv);
  window.attachEvent("onresize", centerDiv);
  } else {
  window.onload = centerDiv;
  window.resize = centerDiv;
  }

  function centerDiv() {
  var myDiv = document.getElementById("oDiv");
  var myBody = document.body;
  var bodyWidth = myBody.offsetWidth;

  //Needed for Firefox, which doesn't support offsetHeight
  var bodyHeight;
 if (myBody.scrollHeight)
 bodyHeight = myBody.scrollHeight;
 else bodyHeight = myBody.offsetHeight;

  var divWidth = myDiv.offsetWidth;

  if (myDiv.scrollHeight)
   var divHeight = myDiv.scrollHeight;
   else var divHeight = myDiv.offsetHeight;

 myDiv.style.top = (bodyHeight - divHeight) / 2;
  myDiv.style.left = (bodyWidth - divWidth) / 2;
  }

</script>

如果您使用CSS表达式来模拟早期IE版本中不可用的CSS属性，你应该提供版本测试的javascript代码，为支持CSS的浏览器禁止CSS表达式。举例来说，max-width属性，这个属性在一定数量的像素范围内强制文本换行，在IE 7前是不支持的。下面的CSS表达式作为一种解决方法，为IE 5和6提供了这个功能：

p { width: expression( document.body.clientWidth > 600 ? "600px" : "auto" ); }

为不支持此属性的IE浏览器版本使用等价的JavaScript替换CSS表达式，可以使用类似于下面的内容：

<style>
  p { max-width: 300px; }
</style>

<script type="text/javascript">

  if ((navigator.appName == "Microsoft Internet Explorer") && (parseInt(navigator.appVersion) < 7))
  window.attachEvent("onresize", setMaxWidth);

  function setMaxWidth() {
  var paragraphs = document.getElementsByTagName("p");
  for ( var i = 0; i < paragraphs.length; i++ )
  paragraphs[i].style.width = ( document.body.clientWidth > 300 ? "300px" : "auto" );

</script>

将样式放在页面头部

概述

将内联样式块和<link>元素从页面移动到页面<head>中，这样能提高渲染性能。

详细信息

在HTML文件中指定外部样式表和内联样式块可能对浏览器的渲染性能产生不利影响。浏览器阻塞渲染网页直到所有外部的样式表都已被下载。（用 <style> 标记指定的）内联样式块可能会导致reflows和页面跳动。因此，把外部样式表和内联样式块放在页面的``中是很重要的。通过确保样式首先被下载和解析，可以让浏览器逐步渲染页面

建议

HTML 4.01规范（第12.3节）规定，始终把使用<link>标签的外部样式表放在<head>部分里。不要使用@import。还要确保您指定的样式有[正确的顺序](http://code.google.com/intl/zh-CN/speed/page-speed/docs/rtt.html#PutStylesBeforeScripts。

把<style>区块放在``部分里。

指定图片尺寸

概述

为页面中所有图片指定宽度和高度可以消除不必要的reflows和重新绘制页面【repaints】，使页面渲染速度更快。

详细信息

当浏览器勾画页面时，它需要能够流动的，如图片这样的可替换的元素。提供了图片尺寸，浏览器知道去环绕附近的不可替换元素，甚至可以在图片下载之前开始渲染页面。如果没有指定的图片尺寸，或者如果指定的尺寸不符合图片的实际尺寸，一旦图片下载，浏览器将需要reflows和重新绘制页面。为了防止reflows，在HTML的<img>标签中或在CSS中为所有图片指定宽度和高度。

建议

指定与图片本身相一致的尺寸

不要使用非图片原始尺寸来缩放图片。如果一个图片文件实际上的大小是60×60像素，不要在HTML或CSS里设置尺寸为30×30像素。如果图片需要较小的尺寸，在图像编辑软件中，设置成相一致的尺寸(详见优化图像。)

一定要指定图片或它的块级父元素的尺寸

一定要设置<img>元素本身，或它的块级父元素的尺寸。如果父元素不是块级元素，尺寸将被忽略。不要在一个非最近父元素的祖先元素上设置尺寸。

注：浏览器为了重新渲染部分或整个页面，重新计算页面元素位置和几何结构的进程叫做reflow

———————— 2011-3-18 补充 —————————–

Google后来对此文档做了更改，新增部分翻译见对《优化浏览器渲染》的补充【译】

• 原文：Speeding up JavaScript: Working with the DOM
• 作者：KeeKim Heng, Google 页面工程师
• 翻译：ytzong

当制作 RIA(Rich Internet Application) 时，我们使用 JavaScript 来改变或增加元素。这是靠 DOM (Document
Object Model 文档对象模型) 来完成的，这是如何影响 app 的速度呢？

处理 DOM 会使浏览器 reflow (浏览器决定如何显示东东的进程)。直接操作 DOM，改变元素的 CSS 样式，改变浏览器窗口的大小会触发 reflow。访问元素的布局属性(如offsetHeight 和 offsetWidth) 会触发 reflow。由于每次 reflow 需要时间，所有我们能减少 reflow 越多，app 越快。

处理 DOM 不仅操作页面中存在的元素还包括创建的元素。下面四个部分覆盖了 DOM 操作和 DOM generation，减少浏览器中 reflow 触发的次数。

CSS class 切换 DOM 操作

这个部分我们改变一个元素和它后代的多个样式属性，只触发一次回流。

问题

我们写一个函数来改变一个元素中的所有链接的 className 属性。可以通过简单遍历每个 a 并更新他们的 className 属性。

function selectAnchor(element) {
  element.style.fontWeight = 'bold';
  element.style.textDecoration = 'none';
  element.style.color = '#000';
}

解决方法

我们可以增加一个设置所有样式属性的 class 来解决这个问题。通过给元素增加这个class，现在我们只触发一次浏览器 reflow。同时分离了表现和行为(译注：这个在我之前的《body标签class属性的妙用(Google Reader前端简单分析)》中也有提及)

.selectedAnchor {
  font-weight: bold;
  text-decoration: none;
  color: #000;
}

function selectAnchor(element) {
  element.className = 'selectedAnchor';
}

Out-of-the-flow DOM 操作

这个部分我们创建多个元素并把它们插入 DOM 只触发一次 reflow。使用了叫做 DocumentFragment 的东东。我们在 DOM 外创建一个DocumentFragment (所以是 out-of-the-flow)。之后创建并添加进多个元素。最后，我们移动该 DocumentFragment 中的所有元素到 DOM，这只触发一次 reflow。

问题

让我们写一个改变一个元素中所遇链接的 className 属性的函数。通过简单的遍历每个 a 并更新他们的 href 属性。问题在于，每个 a 会触发一次reflow。

function updateAllAnchors(element, anchorClass) {
  var anchors = element.getElementsByTagName('a');
  for (var i = 0, length = anchors.length; i < length; i ++) {
    anchors[i].className = anchorClass;
  }
}

解决方法

解决这个问题，可以从 DOM 中移除元素，更新所有链接，之后插入回元素到原始位置。为此，我们写一个可复用的函数，不仅从 DOM中移除元素，并且返回一个将会插入回元素至元素位置的函数。

/**
 * Remove an element and provide a function that inserts it into its original position
 * @param element {Element} The element to be temporarily removed
 * @return {Function} A function that inserts the element into its original position
 **/
function removeToInsertLater(element) {
  var parentNode = element.parentNode;
  var nextSibling = element.nextSibling;
  parentNode.removeChild(element);
  return function() {
    if (nextSibling) {
      parentNode.insertBefore(element, nextSibling);
    } else {
      parentNode.appendChild(element);
    }
  };
}

现在我们用这个函数去更新一个元素中的所有链接，这 out-of-the-flow，并且在移除元素时和插入元素时只触发一次 reflow。

function updateAllAnchors(element, anchorClass) {
  var insertFunction = removeToInsertLater(element);
  var anchors = element.getElementsByTagName('a');
  for (var i = 0, length = anchors.length; i < length; i ++) {
    anchors[i].className = anchorClass;
  }
  insertFunction();
}

单个元素的 DOM Generation

这个部分我们创建并添加一个元素至 DOM 中，仅触发一次 reflow。创建元素后，在新元素添加至 DOM 前做好所有的改变。

问题

写一个添加新a 元素至父元素的函数。这个函数让你为该链接提供 class 和 文本。我们可以创建元素，添加进 DOM，之后设置这些属性。这触发3次 reflow。

function addAnchor(parentElement, anchorText, anchorClass) {
  var element = document.createElement('a');
  parentElement.appendChild(element);
  element.innerHTML = anchorText;
  element.className = anchorClass;
}

解决方法

最后插入这个子节点至 DOM。这触发一次 reflow。

function addAnchor(parentElement, anchorText, anchorClass) {
  var element = document.createElement('a');
  element.innerHTML = anchorText;
  element.className = anchorClass;
  parentElement.appendChild(element);
}

尽管如此，如果我们要添加大量的链接至一个元素时这有一些问题。通过这个方法，每添加一个链接触发一次 reflow。下一部分解决这个问题。

DocumentFragment DOM Generation

这个部分，我们创建多个元素并把它们插入 DOM 触发一次 reflow。使用了一个叫做 DocumentFragment 的东东。我们在 DOM 外创建一个DocumentFragment (所以是 out-of-the-flow)。之后创建并添加多个元素进来。最后，把所有DocumentFragment 中的元素移至DOM 并只触发一次 reflow。

问题

写一个添加10个连接至一个元素的函数。如果只是简单的添加每个新链接至这个元素，会触发10次 reflow。

function addAnchors(element) {
  var anchor;
  for (var i = 0; i < 10; i ++) {
    anchor = document.createElement('a');
    anchor.innerHTML = 'test';
    element.appendChild(anchor);
  }
}

解决方法

为了解决这个问题，我们创建一个 DocumentFragment 并添加每个新链接至此。当我们使用appendChild 添加 DocumentFragment至元素时，所有 DocumentFragment 的子节点 实际上添加进了这个元素中。这只触发一次 reflow。

function addAnchors(element) {
  var anchor, fragment = document.createDocumentFragment();
  for (var i = 0; i < 10; i ++) {
    anchor = document.createElement('a');
    anchor.innerHTML = 'test';
    fragment.appendChild(anchor);
  }
  element.appendChild(fragment);
}

• 原文：Capturing and analyzing browser paint events using Page Speed Activity
• 作者：Bryan McQuade, 软件工程师
• 翻译：ytzong

安装

Page Speed 是一个 Firebug/Firefox 扩展，安装地址：http://code.google.com/speed/page-speed/download.html

背景：逐步呈现

快速的网页逐步呈现。即随浏览器的加载而逐步显示其内容。一个逐步呈现的页面给浏览者页面在加载的视觉回馈，并尽快给给用户请求信息。Google和Yahoo 都建议逐步呈现页面，比如把 CSS 写在页面 head 中。

对多绝大多数页面来说，有一些很好的实践来优化逐步呈现。一个快速的页面应该先给用户呈现可见的内容(译注：浏览器第一屏)，随后呈现视线外的内容(即当前滚动区域外的内容)。一个快速的页面会在加载和渲染重量级的资源(如图片和视频)之前加载和渲染轻量级的资源(如文字)。

一些众所周知的技术会禁止逐步呈现。使用大量表格，甚至用来布局，在一些浏览器中会使逐步呈现失效。应用样式表在页面后方，即便这些样式表在开始的页面加载中使用不到，也会阻止逐步呈现。

用Page Speed Activity捕获浏览器渲染

很难决定一个页面是否要进行逐步呈现优化。大多数页面对肉眼来说呈现太快，以至于意识不到个别的渲染事件(尤其是在高速网络连接下)，而且看不到屏幕区域外的内容是否呈现了。

幸运的是，Firefox 3.5 支持捕获浏览器渲染事件。Page Speed Activity 面板用这个功能可为页面呈现过程录制一个“幻灯片”。幻灯片的每一单元显示了哪一个屏幕区域被渲染(黄色)，哪些区域在屏幕外(灰色)用户看不到。

启用渲染快照

由于捕获渲染快照会增加一些开销并拖慢浏览器，Page Speed Activity 屏幕快照默认是禁用的。启用渲染快照，确保Activity 下拉菜单中的”Paint Snapshots (slow)” 被选中。

Activity 面板中的渲染快照

一旦渲染快照启用，就开始用 Activity 面板录制。Activity 面板将在时间线上显示网络，缓存，和 JavaScript 事件。渲染快照幻灯片出在Activity 面板右侧。渲染快照会按捕获顺序绘制，最早的快照在顶部。拖动右侧的滚动条可看到所有的快照。

快照回放示例

译注：请到这里看演示

用 Page Speed Activity 回放这个例子的渲染快照，请点击 Play Paint Events按钮。

在快照中，用户可见的区域为白色，用户不看见的区域(当前浏览器滚动区域之外)用灰色遮罩。每个快照用黄色遮罩显示重绘区域。

请注意，可见区域的文本内容首先呈现，之后是屏幕外的文本内容。通过先呈现屏幕内的可见区域，用户尽早获取了尽可能多的有用信息。

文本内容呈现后，图像内容接着呈现。推迟图像内容呈现直到文本内容下载完成并呈现完成，这使得浏览器尽早的显示文本内容，再一次尽早给用户尽可能多的有用信息。

在页面标签中给所有图像指定宽度和高度属性，浏览器不需在图像加载后 reflow 页面。尽管没有严格的与逐步呈现有关，指定图像的宽高会带来更好的用户体验，在页面加载时页面内容不会在附近移动。

最后，注意图像自身的逐渐呈现。允许用户在全部图像完成加载前看到图像内容。现代浏览器在 HTML 中用 标签逐步呈现图像。相反，许多浏览器中用CSS 的background-image 属性不会逐步呈现。为了逐步呈现图像，用 HTML 的 标签来代替 CSS 的 background-image属性。

总结

使用 Page Speed Activity 面板的渲染快照功能，我们可以清晰的观察页面的逐步呈现行为。这使得网页开发者可以为逐步呈现而优化页面，这是快速网页非常重要的特性之一。

延伸阅读

• Page Speed – 开源的 Firefox/Firebug扩展，评估页面性能并捕获屏幕快照
• Web Performance Best Practices: Put CSS in the document head – Google 的最佳网页优化实践讨论 CSS 放在页面
  head 的重要性
• Response Times: The Three Important Limits – Jakob Nielsen 指出了一些关于响应时间的经验准则，并强调当页面加载过程中给用户持续反馈的重要性
• How Design Affects Performance: Progressive Rendering – 做了一个非常好的并排视觉对比来说明逐步呈现的好处，讨论了HTML表格对逐步呈现的影响
• High Performance Web Sites: Put Stylesheets at the Top – Steve Souders 的第一本网页性能的书介绍了如何加载样式表可以禁止逐步呈现
• Charles Web Debugging Proxy – Charles 允许网页开发者调节他们的网络连接，去模拟低速用户的页面加载

Google 网站管理员 Jens Meiert 发表了一篇《Using HTML 5 for performance improvements》，大部分内容在《Reducing
the file size of HTML documents》(中文版)中都有提及，新增的部分为async(和 defer)，以下为该段的翻译：

async 和 defer 使用在 script 元素上。

要解释为什么这些属性会提升性能，最好是看一下未使用时发生了什么 — 各自的脚本在用户代理(浏览器，下同)继续解析页面前将被提取并直接执行，有时这个行为是我们想要的，有时不是。

新的 async 属性允许各自的脚本在可用时异步执行。HTML 4 中已经包含 defer 属性，指出 defer “对用户代理提供一个暗示：脚本不产生任何文档内容(比如，在Javascript 中没有 document.write )，这样，用户代理会继续解析并渲染”。

如果不使用 async 属性而只使用 defer，脚本在页面解析完成时已经执行。即使指定了 async 属性，也可同时指定defer 属性。这使得那些旧的只理解defer 的浏览器来回退 defer 行为而非默认的同步阻塞行为。

译注：本打算翻译这篇文章的，搜了一下已经有人翻译过了，不过网站失效，通过快照获取了部分内容，在此基础之上进行了一些修改，感谢 bloglei。

• 原文：How gzip compression works
• 作者：Kevin Khaw & Eric Higgins，Google 网站管理员
• 翻译：bloglei &ytzong

译注：以上是 youtube 视频，请翻墙观看（文中图片调用自 picasa，若显示不了也要翻墙）

浏览器请求有无 gzip 压缩的高级预览

服务器未 gzip：

浏览器：

• 连接服务器并请求页面。
• 通知服务器，浏览器支持 gzip “Accept-Encoding: gzip”。

服务器：

• 不支持 gzip。忽略 gzip 请求。发送未压缩的页面。

浏览器：

• 接收页面。
• 显示页面。

服务器 gzip：

浏览器：

• 连接服务器。
• 通知服务器，浏览器支持 gzip “Accept-Encoding: gzip”。

服务器：

• 收到 gzip 支持通知。
• 发送 gzip 编码过的页面，并设置响应头“Content-Encoding: gzip”。

浏览器：

• 接收页面。
• 根据响应头“Content-Encoding: gzip” 解码 gzip 编码过的页面。
• 显示页面。

如何进行 gzip 压缩

简单的说，gzip 压缩是在一个文本文件中找出类似的字符串，并临时替换他们，使整个文件变小。这种形式的压缩对 web 来说特别适合，因为 HTML 和 CSS文件通常包含大量的重复字符串，例如空格，标签，及样式定义。

例子

在这个例子中，我将用一小段代码演示 gzip 压缩中用相同的标签跟不同的标签的对比。

在第一段代码中，我用了5个标题标签。

未压缩: 69 bytes

压缩后: 85 bytes (译注：某天77问我怎么压缩后比压缩前还大？我回来后看了下原文并测试了一下，事实如此，并非翻译错)

<h1>One</h1><h2>Two</h2><h3>Three</h3><h4>Four</h4><h5>Five</h5>

把标题标签改为相同的 div 标签，源代码增大了 10 bytes，但是压缩后，它缩小到 66 bytes，比先前的源代码片段还小！

未压缩: 79字节

压缩后: 66 字节

<div>One</div><div>Two</div><div>Three</div><div>Four</div><div>Five</div>

许多开发者可能依此只使用 div 和 span 标签而使页面更大程度的压缩。在多数情况下当然无可非议，但必须注意到正确的语义化标记对可访问性（accessibility）来说非常重要，而且使页面更容易阅读。即便如此，可以使用此方法做一些优化，这取决于你，开发者来决定哪些是合适的。

延伸阅读

• Page Speed – Enable gzip compression

• 原文：UI messaging and perceived latency
• 作者：Roma Shah，用户体验研究员
• 翻译：ytzong

对一般的用户而言，速度并不意味着性能。用户对网站速度的感知很大程度上取决于其整体感受，包括他们如何高效的从网站获取所需，以及网站反映出来的易响应性。

当设计 Web 站点或 Web 应用时，谨记用户来你的网站是有目的的。他们能越快（越容易）达到他们的访问目的越好。如果用户在获取内容时遇到了许多困难，他们将会离开你的网站，而去能让他们更快达成目标的其他网站。

节省用户时间，让他们感觉没那么慢有很多工作可以做，本文只涉及提示信息。

提示信息，要考虑三点：

1. **网站是否足够简单和直观，首次访问者是否可以很容易上手？**如果不是，花些时间去设计首次运行经验（first-run-experience）提示。 比方说，你的网站是一个拥有数项功能的强大的 Web 应用。鉴于为此类型的应用程序设计一套直观的“开箱即用”（out-of-the-box ）体验并不是一项容易的事情，用户可能需要一个入门帮助。

首次运行经验简单的为用户说明产品是什么以及/或如何使用其亮点。从长远上看，花一点点时间让用户提前了解产品的一些关键点会给他们节省大量时间。

提示：不要过头！不要阻止用户获取实际内容，这会令首次运行经验变成额外的一步（a cumbersome multi-step process）。

2. **提示信息是否会中断或增加用户操作？**仔细考虑如何显示信息会增加用户的操作流程。在不影响用户操作的情况下可能有更合适的方式去显示提示信息。 想象一个场景，用户完成一个动作，你认为很完美的。你认为需要二次确认（double-checking）的，为了防止用户意外出错。所以你弹出一个提示“你确定这样做吗？”，这阻止了用户的一个大的错误操作，但对于确定要执行这个动作的用户来说，你增加了一个额外的操作。作为替代，你可以运行操作立即执行，同时在操作后增加一个撤消的功能。

3. **等待时如何让用户静心（reassure）**面对现实吧，有些时候用户不得不等待。然而，你可以做一些工作使不可避免的等待时间变得比较好度过（bearable）。 如果用户等待的时间较长，使用进度条。进度条不只表明必须等待，同时粗略的显示要等多久。如果要更详细一点，甚至可以显示已经完成的数据（例如 40kb of 64kb）。尽量避免估算完成时间，因为连接速度波动时，没有什么比看到完成时间一直在增长更郁闷的了。

当用户等待的时间较短时，可以用 loading 指示器。loading 指示器通常是一个旋转变化的小东东（a spinning doo-dad of sorts），但也可以是很简单的文字”loading”。

你也许会问，为什么极短的时间也要显示这些？loading 指示器是给用户的反馈：用户的操作已经通过，网站正在执行。没有指示器的话，用户不确定是否执行，从而可能企图再次尝试。

延伸阅读

这些建议只是为用户设计时需铭记的事项中的冰山一角。下面是一些可以让你入门（get you started）的关于交互设计和 Web 设计原则的资料：

• About Face by Cooper, Reimann, Cronin
• Bulletproof Web Design by Dan Cederholm
• Contextual Design by Beyer and Holtzblatt
• Designing the User Interface by Ben Schneiderman and Catherine Plaisant
• Interaction Design by Jenny Preece, et al
• The Elements of User Experience by Jesse James Garrett

• 原文：Minimizing browser reflow
• 作者：Author: Lindsey Simon
• 翻译：ytzong

浏览器为了重新渲染部分或整个页面，重新计算页面元素位置和几何结构（geometries）的进程叫做 reflow。由于 reflow 是一种浏览器中的用户拦截（user-blocking）操作，所以了解如何减少reflow 次数，及不同的文档属性（DOM 层级（DOM depth），CSS 效率，不用类型的 style 变化）对 reflow 次数的影响对开发者来说非常必要。有时reflow 页面中的一个元素会 reflow 它的父元素（译注：这里是复数）以及所有子元素。

有多种用户操作和 DHTML 变化可能会触发 reflow。调整浏览器窗口的大小，用 javascript 计算样式（computed styles），在 DOM 中创建删除元素，改变元素的 class 都会触发 reflow。值得注意的是，有些操作会多次触发 reflow，超出你的想象。下图源自Steve Souders 的演讲 “Even Faster Web Sites“：

从上表可以很明显的看出，在所有浏览器中并非所有 javascript 控制的样式都触发 reflow，即使触发了触发的次数也不尽相同。同时可以看出现代浏览器在控制reflow 次数方面做的越来越好。

在 Google，我们通过多种方式对我们的页面及 Web 应用测速，同时 reflow 是我们增加 UI 时考虑的一个关键因素。我们致力于传达轻快的（lively），交互性强的（interactive）和令人愉悦的（delightful）的用户体验。

原则

下面是一些减小 reflow 的原则：

1. 减少不必要的 DOM 层级（DOM depth）。改变 DOM 树中的一级会导致所有层级的改变，上至根部，下至被改变节点的子节点。这导致大量时间耗费在执行reflow 上面。
2. 尽量减少 CSS 规则，去除未用到的 CSS。
3. 如果做复杂的表现变化，如动画，让它脱离文档流。用绝对定位或 fixed 定位来完成。
4. 避免不必要的复杂的 CSS 选择器，尤其是后代选择器（descendant selectors），因为为了匹配选择器将耗费更多的 CPU。

在下面的视频中（译注：引用自 youtube，请翻墙），Lindsey 介绍了一些减少 reflow 的方法。

延伸阅读

• Mozilla 关于 HTML reflow 的记录（Mozilla’s Notes on HTML reflow）
• Opera的重绘和reflow（Opera’s Repaints and reflows）
• Satoshi Ueyama 在 Firefox 中调试 reflow 的例子（Satoshi Ueyama’s debug-Firefox reflow demos）: - google.co.jp reflow
• mozilla.org reflow
• ja.wikipedia.org reflow
• Nicole Sullivan 的关于 reflow 和 重绘（Nicole Sullivan on Reflows and Repaints）

• 原文：Reducing the file size of HTML documents
• 作者：Jens Meiert & Kevin Khaw， Google 网站管理员
• 翻译：ytzong

改善网站速度的一个很明显的方法是减小 HTML 文件的大小。有一些方法，比如：硬压缩（rigid compression），acupuncture-like ID 及改变 class 名（译注：这一句不是很确定，原文：There are several ways to do this, from rigid compression to acupuncture-like ID and class name changes）。下面是一些我们总结的使 HTML 标记更精简的方法。

译注：上面是引用 youtube 的视频，请翻墙观看。

HTML 4

HTML （非XHTML），MIME type 为 text/html ，允许省略一些标签。通过
HTML 4 DTD，你可以省略以下标签（那些所谓可避免的元素，这里用删除线加以标记（感谢一楼的翻译））

</area>

</base>

<body>

</body>

</br>

</col>

</colgroup>

</dd>

</dt>

<head>

</head>

</hr>

<html>

</html>

</img>

</input>

</li>

</link>

</meta>

</option>

</p>

</param>

<tbody>

</tbody>

</td>

</tfoot>

</th>

</thead>

</tr>

比如，你的代码是

<li>List item</li>

可以写为

<li>List item

又比如段落要以

</p>

结尾，你可以只写

<p>My paragraph

甚至可以去掉 html，head，body（把这作为你的编码规范之前请确保这会令你舒服）。

省略标签后 HTML 依然有效，同时减小了文件大小。对一般的页面来说，可以节省 5-20%。

HTML 5

正在发展中的 HTML 5 提供了一些减小文件大小的方法。

比如，页面文档类型声明

<!DOCTYPE html>

对比

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

很显然 HTML 5 的 DTD 更短。

当为页面指定编码时，HTML 5 很易用而且更短：

<meta charset="utf-8">

代替

<meta http-equiv="content-type" content="text/html; charset=utf-8">

通常情况下，浏览器会正确处理 HTML。

另外，在今天的 HTML 5 中，你可以去除声明 MIME 类型的 type 属性，比如

type="text/css"

或

type="text/javascript"

你可以用

<script>

替代

<script type="text/javascript">

用

<style>

替代

<style type="text/css">

在所有类型的页面中（甚至是 XHTHML）你可以省略

type="text/css"

HTML 5 使这一切变得更简单。

同时使用上面所有的方法会使文件节省 10%-20%（甚至更多），这取决于你的编码风格和页面中的文本内容数量。代码将更干净，访问者会更快的获取网站内容。在隐私中心项目中我们采用很多这类技术，节省了原始文件大小的20%。