为自己写代码，为使用而编译
任何一个程序员都很清楚地知道，之所以不把自己所使用的代码作为最终的代码来交付是有它合理的原因的。写代码时最好要尽可能多写些注释，通过编排格式在最大程度上提高代码的可阅读性，同时避免过分的简洁不让晦涩的代码给日后的维护带来困难。之后，我们再使用编译器等把源代码转化成其他格式，一方面达到最优执行，另一方面可以防止反编译，以免造成源代码被剽窃。上述的这种模式其实也适用于网站的开发。具体做法是：先制作好网站和网页的源代码，再利用一些简单的技术（比如：减少空白区域，进行图片和脚本的优化，文件重命名等）把源代码减肥然后你就可以将准备好的网站和网页交付使用了。
希望这种概念对于你来说并不突兀，因为起码你很有可能正是在您站点的副本上操作，而不是直接在正在运行的站点上作修改更新。如果你不是这样做的，那么请马上停止阅读本文，赶紧去给你的站点做个副本吧！无论您的网站的内容是静态的手册还是非常复杂的使用内容管理系统来驱动（CMS-driven）的应用，这都是唯一正确的开发网站的方式。你要是现在还不相信的话，那么我敢说很快的等到你损毁了网站的一些文件却发现难以恢复的时候你就信了。
在建造网站时，您可能会把注意力放在导致下载速度降低的最大元凶—图片、二进制文件（如Flash等）上。减少GIF图片文件的颜色数、压缩JPEG图片文件的大小、优化SWF文件固然颇有裨益，其他大有帮助的方法也不能小觑。要记得网站性能法则中的第一条，我们得不断的努力以尽可能少地传输数据，不论它是markup文件、图片还是脚本。把精力放在减少(X)HTML、CSS和JavaScript文件的字节数上似乎是瞎忙乎，可是，这可能恰恰就是最应该注意的地方。
在一个典型的网页加载过程中，(X)HTML文件是最先被浏览器读到的。既然这个文件决定了其他文件的关系，我们可以管这个文件叫主文件(host document)。浏览器一旦接收到这个主文件，便开始解析各种markup；一般在解析的同时，也会触发一系列对相关对象的请求，例如外部脚本、关联的样式表单、图片、或嵌入式Flash等等。这些CSS和JavaScript文件有可能继续触发一些对相关图片或脚本等的请求。这些对相关文件的请求排成队列的速度越快，它们到达浏览器的速度也就越快，从而越早的开始显示出页面来。了解了主文件的重要性，我们便知道把它尽快地传给浏览器并加以解析的重要性，因为尽管主文件本身相对来说整个传输量来说只是一小部分，它却能够严重地阻碍网页的加载速度。要明白，用户才不在乎你使用的字节数的多少，用户在乎的是时间！
那么您具体需要怎么做才能作到最优传输的万全准备呢？一个基本的方法是减少空白区域，精简CSS和JavaScript，更改文件名，以及对要提交的代码也采用前述相同的策略，使之越简洁越好(Google 就是一个例子). 这些目前大家都熟知的通用技巧，在很多网站和一些书中比如Andy King的 《Speed up Your Site: Website Optimisation 》都能找到。本文则列出我们认为最有效的优化markup和代码的二十大技巧。当然，您可以手动来做部分优化，或者使用网页编辑器及工具来完成一些优化，当然还可以开发出您自己的精简工具。我们要向你介绍一个由Port80软件公司开发的工具w3compiler. 它几乎实现了下面将要提到的所有技巧，而且它也反映出在“真实”世界里代码优化任务的商业价值。接下来，我们来谈谈这些技巧！
Markup优化
典型的markup要么是手工编辑出来的，在非常紧凑，注重标准的格式基础上加入注释和空白区域(white space)的文件；要么是编辑器生成的，非常之肥胖，带有过分的格式编排及编辑器特有的通常用来控制结构的注释，甚至还会有不少重复的和没有用修饰或者代码。这两者都不是最优传输的情况。下列技巧既安全又容易，是减小文件尺寸的好方法：
1、尽可能的除去空白区域
一般而言，空白区域字符（空格、制表符、换行符等）都可以安全删除，但要避免修改pre, textarea, 及受CSS属性中white-space影响的标签。
2、除去注释
除了在客户端给IE和doctype声明的条件注释外，几乎所有的注释都可以安全去除掉。
3、使用最短格式的颜色表示
使用颜色时，不要一股脑的使用十六进制或全颜色名称(full color name)，要尽可能根据实际情况使用最短格式的颜色表示。比如，一个为#ff0000 的颜色属性可以直接用red</code来说明，而lightgoldenrodyellow可以换成 #FAFAD2#FAFAD2。
4、 使用最短格式的字符表示
和最短颜色表示一样，一些名称可以用最短字符来表示，我们可以用较短的数字来代替某些长长的字母。比如：È 可以变成È。或者，偶尔这个方法反过来也行，比如：ð 如果变成ð则可以省一个字节。不过，这个方法不太安全，而且成效有限。
5、 除去无用的标签
有些‘垃圾’markup，比如使用了多次的重复标签或者某些编辑器里用作广告的meta 标签，都可以安全地被删除。
CSS优化
CSS也有一套成熟而又简单的优化方法。实际上，时下大多数的CSS都较 (X)HTML更容易压缩。下面所列的技巧除了最后一条都是安全的。最后一条涉及到客户端的网页技术，可能会变得比较复杂。
6、除去CSS中的空白区域
相比起(X)HTML来，CSS对于空白区域没有那么敏感，所以除去空白区域便可以极大地减少CSS文件和style样式表区域的大小。
7、 除去CSS注释
如同除去markup代码中的注释一样，由于CSS中的注释对普通的最终用户来说并没有什么实用价值，所以也应该被除去。不过，如果考虑到较低级的浏览器，则在CSS中的style标签中的屏蔽注释信息不可以被除去。
8. 使用最短格式来表示颜色值
和HTML一样，CSS颜色也可以用词语或十六进制格式表示。注意，在CSS中这样做的效果会稍微明显一些。主要是因为CSS中支持3位的十六进制色值，例如对白色可用#fff 来表示。
9、对CSS的规则进行合并、减少或删除
CSS中的诸如字体大小、字体重量等规则往往可以使用一种单属性字体的速记注释方式来表示。使用得当的话，这个技巧可以让您把如下的规则：
p {font-size: 36pt;
font-family: Arial;
line-height: 48pt;
font-weight: bold;}
改写成下面简短的形式：
p{font:bold 36pt/48pt Arial;}
如果继承方法使用得当的话，您还会发现在样式表单中的一些规则可以显著的减少或干脆删掉。到目前为止尚没有能自动移除规则的工具，所以只能通过手工调整CSS向导(Wizard)来进行这些工作。不过即将推出的w2compiler 2.0会有这个功能。
10、对类和ID值进行重命名
在CSS优化中最危险的动作可能是重命名类或ID值了。看看如下规则：
.superSpecial {color: red; font-size: 36pt;}
可将其更名为sS。而对ID值一样可以遵循这样的原则，例如对于：
#firstParagraph {background-color: yellow;}
则可将原来的 ”#firstParagraph” 重命名为 ”#fp”，并在整个文档中重复这一动作 。诚然，这样做可能会涉及到“标识-样式-脚本”互相依赖的问题：如果一个“tag”有一个ID值，而这个值又可能不但用于样式表，还可能用于脚本参考，甚至可能是一个链接目标地址。在这种情况下，您一旦修改了这个值，您就必须得保证对所有相关的脚本和链接参考都进行了相应的修改，包括其他文件中的这个值，所以千万要小心细致。
改变类的值相对改变ID值来说，危险性小一些。因为经验告诉我们，比较起ID值来说，大多数JavaScript程序员都不太经常处理类的值。然而，改变类的名称来缩减CSS的尺寸也面临着和改变ID名称同样的问题，所以再次强调，要小心谨慎。
请注意：最好不要更改名称属性，尤其是表单区域中的名称属性。因为这些数值也会被服务器端程序所操作。虽然不是不可能，但对多数的网站来讲，要计算好这些相互依赖关系是困难的。
JavaScript优化
越来越多的网站都依赖于JavaScript来生成导航菜单、表格确认和其他各种各样实用的东西。不足为奇，大多数这些代码都非常笨重，亟待优化。对JavaScript代码的很多优化技术同那些用于markup代码和CSS的技术很相似。不过，对JavaScript的优化必须更加小心翼翼，因为一旦操作有误，其后果可能不仅仅是显示变形，并且可能导致网页残缺不全。下面我们先来看看一些最简单明了的方法，然后再探讨那些需要小心操作的技巧。
11. 除去JavaScript注释
除了 注释，其他所有的 // or /* */ 注释都可以安全删除，因为 它们对于最终使用者来说没有任何意义（除非有人想了解您的脚本是如何工作的）。
12.除去JavaScript中的空白区域
有意思的是，除去JavaScript中的空白区域并不象想象的那么有用。一方面，像如下代码：
x = x + 1;
显然可以简短得写成
x=x+1;
然而，很多随便的JavaScript程序员会忘记在两行之间加上分号，这时空白区域的除去就会带来问题。比如，下面合法的JavaScript使用了暗示的(implied)分号：
x=x+1
y=y+1
草率地删除了空白区域则会产生如下表达式：
x=x+1y=y+1
显然，错误就产生了。但如果您加上必需的分号，如下：
x=x+1;y=y+1;
则在字节数上并没有减少。然而在此，我们仍然鼓励这种格式的变化，因为对w3compiler Beta版的测试反馈中，很多人对‘看起来压缩了的’脚本非常满意（也许这是因为视觉上确认了对原始代码的格式转变）。他们也喜欢这种处理方法产生的另一个效果，那就是让交付的代码变得更难读。
13.进行代码优化
简单的方法如除去暗示的(implied)分号，某些情形下的变量声明或者空回车语句都可以进一步减少脚本代码。一些简略的表达方式也会产生很好的优化，例如：
x=x+1;
可以写成：
x++;
不过得小心谨慎，不然代码很容易出错。
14.重命名用户自定义的变量和函数
为了阅读方便，我们都知道在脚本中应该使用象sumTotal这样的变量而不是s。不过，考虑到下载的速度，sumTotal这个变量就显得冗长了。这个长度对于最终使用者来说没有意义，但对浏览器下载则是个负担。这个时候s就成为较好的选择了。先写好方便阅读的代码，然后再使用一些工具来处理以供交付。这种处理方式在这里再一次展示了其价值所在。将所有的名称都重新用一个或两个字母来命名将带来显著的改善。
15.改写内建(built-in)对象
长长用户变量名会造成JavaScript代码过长，除此之外，内建(built-in)对象（比如Window、Document、Navigator等）也是原因之一。例如：
alert(window.navigator.appName);
alert(window.navigator.appVersion);
alert(window.navigator.userAgent);
可以改写成如下简短的代码：
w=window;n=w.navigator;a=alert;
a(n.appName);
a(n.appVersion);
a(n.userAgent);
如果这几个对象使用频繁的话，这样改写带来的好处就不言而喻了。事实上这些对象也的确经常被调用。然而我要提醒的是，如果Window或Navigator对象仅仅被使用了一次的话，这样的替换反而使代码变得更长。所以手工进行这种优化时要格外小心，不过好在目前市面的常用的JavaScript代码优化工具都已经考虑到这个因素了。
这个技巧带来一个对象更名后脚本执行效率的问题：除了代码长短上带来的好处，这种改写更名实际上还会稍微的提高一点脚本执行的速度，因为这些对象将会被放在所有被调用对象中比较靠前的位置。JavaScript游戏开发程序员使用这个技巧已经有多年了，下载和执行速度都会有所提高，并且对本地浏览器的内存花销也会降低，可谓一石三鸟。
文件方面的优化
最后一类的优化技巧与文件和站点的组织有关。下面谈及的一些技巧可能会牵扯到服务器的调整和站点的重构。
16.重命名用户访问不到的独立文件和目录
一些站点往往包含有诸如SubHeaderAbout.gif或 rollover.js等是用户无法通过URL来访问的文件。它们通常都保存在一个标准名称的目录中，比如/images，因此我们常常会在markup代码中看到这样的句子：
<img src="/images/SubHeaderAbout.gif">
或者更糟糕的象
<img src="../../../images/SubHeaderAbout.gif">
既然这些文件从来都不会被访问到，对于最终使用者而言，方便不方便阅读便无关紧要。考虑下载速度的因素，上述句子改成下列形式更有意义：
<img src="/0/a.gif">
然而手工的文件和目录的修改工作量太大了，我们可以借助一些内容管理系统来完成相关的工作，比如将内容重命名成简短格式等。前面提到的w3compiler就有自动复制并且检查相互依赖关系的功能。如果使用得当，这个技巧会给引用这些文件的(X)HTML文件减肥不少，并且也让那些剽窃(X)HTML的人重新使用这些文件设置了重重障碍。
17.使用URL rewriter来缩短所有的网页URL
注意在刚才提到的技巧中并不建议对网页的文件名（例如 products.html）进行重命名。那样的话，则下面的标示：
<a href="products.html">Products</a>
就会变成
<a href="p.html">Products</a>
这背后的主要原因是读者会看到一个这样的URL： http://www.sitename.com/p.html相比起http://www.sitename.com/products.html来，后者比前者要来的更有意义、更好用的多。
不过，在不牺牲网页URL原义的前提下，假如我们结合更名技巧和修改服务器配置的话，我们还是有可能从缩短文件名中得到收获。譬如，在源代码中把products.html用p.htmll替换掉，之后再设立一个URL复写(rewrite)规则，由服务器端的一个类似复写模块的过滤器比如 来使用这个规则，从而再把这个URL扩展成一个较为用户友好的值。注意这个窍门，如果这个复写规则只执行‘外部’(external)重定向的话，新的URL仅仅会写在使用者浏览器的地址条处，因而会强迫浏览器重新请求该页。在此种情况下，文件本身没有被重命名，仅仅是在源代码中URL里使用了重命名的简短的文件名。
由于这个技巧依赖于URL的复写，并且缺少对服务器端工具(如复写模块)的广泛接触渠道和理解，即使是象w3compiler之类的高级工具在目前也不推崇使用这个技巧。然而， 考虑到像Yahoo!这样的大型网站通过积极使用该技巧得到了显著的获益，这个技巧是不能够被忽视的，毕竟它给目录及文件名称都是非常具描述性的站点提供了明显的减肥(X)HTML文件的效果。
18.除去或缩短文件扩展名
想想看，其实有些情况下文件的扩展名并没有多大用处，比如.gif, .jpg, .js等。浏览器不会依赖这些扩展名来显示页面，而是在处理时使用MIME类的头信息（header）。了解了这一点，我们就可以把：
<img src="images/SubHeaderAbout.gif">
简化为：
<img src="images/SubHeaderAbout">
或是结合文件名目录名重命名，我们可以得到：
<img src="/0/sA">.
您可别乍一看这个结果就吓跑了， .sA.gif仍然是.sA.gif文件，只不过网页的访问者不知道罢了。
不过，为了使用这个相对高级的技巧，您还需要对服务器来做一下修改。主要要做的工作是启用一个叫做“内容协商”(content negotiation)的东西。它可能是服务器自带的，也可能需要一个扩展（比如象Apache的mod_negotation 模块或者IIS里Port80的PageXchanger ）来支持。这样做会有一个负面的影响，它可能会造成服务器性能的一点损失。然而，内容协商的功能所带来的好处远大于所付出的。干净利落的URL可让您的网站即安全又轻便，甚至还使得自适应的内容传递变成可能：根据访问者浏览器的功能和系统的设置来向他传输不同类型的图片或语言！更多的说明请参看同作者所著的 Towards Next Generation URLs 一文。
注意：少了扩展名的URL不会降低您网站在搜索引擎上的排名。Port80软件和其他知名网站（如W3C网站）都使用此技术而没有负面效果。
19. 重构<script>和<style> 调用方式来优化请求次数
我们常常在一个HTML文件头中看到这样标记代码：
<script src="/scripts/rollovers.js"></script>
<script src="/scripts/validation.js"></script>
<script src="/scripts/tracking.js"></script>
大多数情况下，上述代码应该被简化成：
<script src="/0/g.js"></script>
其中g.js包含了所有供全局使用的函数。虽然把脚本文件分成三份对于维护来说是有道理的，但对于代码的传输则没有意义。单个的脚本下载要比三个分离的请求高效的多，并且这也同时简化了markup代码的长度。有趣的是，这个方法模仿了传统编程语言编译器的连接概念
20.考虑代码级的cache能力
提高网站性能中最重要的方法之一是提高缓冲能力（cacheability）。网页开发者对使用<meta> 标签来设置缓冲控制都很熟悉，可是撇开meta对代理的缓冲毫无用处不说，缓冲能力的真正价值是其对相关对象（比如图片或脚本）方面的应用。为了提高缓冲能力，您要考虑根据改变频率对相关对象进行分段，把更适合缓冲处理的东西放在某个目录中（比如：/cache或者/images/cache。一旦您按照这个方法来组织您的网站，添加缓冲控制规则就很容易了，这样你的网站就会向经常来的访问者“跳”出来。
现在，您已经了解了20条有用的优化技巧来使您的网站变得更快。从单条来看它们可能没有很大的作用。可是把它们合起来使用的话，网站的传输能力便会有明显的提高。
