网页代码优化专题

优化中最危险的动作可能是重命名类或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的优化必须更加小心翼翼，因为一旦操作有误，其后果可能不仅仅是显示变形，并且可能导致网页残缺不全。下面我们先来看看一些最简单明了的方法，然后再探讨那些需要小心操作的技巧。

 

n         除去JavaScript注释

除了 注释，其他所有的 // or /* */ 注释都可以安全删除，因为 它们对于最终使用者来说没有任何意义（除非有人想了解您的脚本是如何工作的）。

 

n         除去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版的测试反馈中，很多人对‘看起来压缩了的’脚本非常满意（也许这是因为视觉上确认了对原始代码的格式转变）。他们也喜欢这种处理方法产生的另一个效果，那就是让交付的代码变得更难读。

 

n         进行代码优化

简单的方法如除去暗示的(implied)分号，某些情形下的变量声明或者空回车语句都可以进一步减少脚本代码。一些简略的表达方式也会产生很好的优化，例如：

x=x+1;

可以写成：

x++;

不过得小心谨慎，不然代码很容易出错。

 

n         14.重命名用户自定义的变量和函数

为了阅读方便，我们都知道在脚本中应该使用象sumTotal这样的变量而不是s。不过，考虑到下载的速度，sumTotal这个变量就显得冗长了。这个长度对于最终使用者来说没有意义，但对浏览器下载则是个负担。这个时候s就成为较好的选择了。先写好方便阅读的代码，然后再使用一些工具来处理以供交付。这种处理方式在这里再一次展示了其价值所在。将所有的名称都重新用一个或两个字母来命名将带来显著的改善。

 

n         改写内建(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游戏开发程序员使用这个技巧已经有多年了，下载和执行速度都会有所提高，并且对本地浏览器的内存花销也会降低，可谓一石三鸟。

 

文件方面的优化

 

最后一类的优化技巧与文件和站点的组织有关。下面谈及的一些技巧可能会牵扯到服务器的调整和站点的重构。

 

n         重命名用户访问不到的独立文件和目录

一些站点往往包含有诸如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的人重新使用这些文件设置了重重障碍。

 

n         使用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文件的效果。

 

n         除去或缩短文件扩展名

想想看，其实有些情况下文件的扩展名并没有多大用处，比如.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网站）都使用此技术而没有负面效果。

 

n         重构<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代码的长度。有趣的是，这个方法模仿了传统编程语言编译器的连接概念

 

n         考虑代码级的cache能力

提高网站性能中最重要的方法之一是提高缓冲能力（cacheability）。网页开发者对使用<meta> 标签来设置缓冲控制都很熟悉，可是撇开meta对代理的缓冲毫无用处不说，缓冲能力的真正价值是其对相关对象（比如图片或脚本）方面的应用。为了提高缓冲能力，您要考虑根据改变频率对相关对象进行分段，把更适合缓冲处理的东西放在某个目录中（比如：/cache或者/images/cache。一旦您按照这个方法来组织您的网站，添加缓冲控制规则就很容易了，这样你的网站就会向经常来的访问者“跳”出来。

现在，您已经了解了20条有用的优化技巧来使您的网站变得更快。从单条来看它们可能没有很大的作用。可是把它们合起来使用的话，网站的传输能力便会有明显的提高。在下一篇文章中，我们将重点放在缓冲处理上。我们会解释缓冲如何经常会被错误使用，以及如何通过一些小小的改动来取得性能的显著提高。

 

CSS优化网站:

http://www.cssoptimiser.com/

http://www.cleancss.com/

http://iceyboard.no-ip.org/projects/css_compressor/