Yslow

主要有12条：

 

1. Make fewer HTTP requests 尽量少的http请求。。咱们有141个请求（其中15个JS请求，3个CSS请求，47个CSS background images请求），多的可怕。思考了下，为何把这个三种请求过多列为对页面加载的重要不利因素呢，而过多的IMG请求并无列为不利因素呢？

发现原来这些请求都是能够避免的。

15个JS和3个CSS彻底能够经过特殊的办法进行合并（这个技术部已经帮咱们解决了，实在是太感谢了，嘿嘿。），这样合并之后，通常状况下页面上只会出现一个JS和一个CSS（对JS的封装得有必定的要求）。

可是47个CSS background images请求改怎么解决呢？为何页面上的纯IMG请求时合理的，而CSS background images请求过多就是不利因素了呢。这个我想了好久，总算明白，原来是这样的：

通常页面上的ICON，栏目背景啊，图片按钮啊，咱们都会用图片CSS背景来实现，而通常这个图片CSS背景用到的图片都是比较小的，因此彻底能够把这些图片合并成一个相对比较大的图片，这样页面上只会出现一个CSS background images请求，最多也就2-3个。后来仔细看了下雅虎美国的页面，他们的确也是这样作的，虽然这样作须要花必定的时间来有规则的合并这些ICON，栏目背景，图片按钮，以方便CSS调用，可是这样作绝对是合算的，并且是有必要的，YSlow也是极力推荐的。

 

2. Use a CDN这项咱们的评分是F级，最低。说实在的，我刚开始什么是CDN都不知道。后来查了GOODLE才知道。CDN的全称是Content Delivery Network，即内容分发网络。其目的是经过在现有的Internet中增长一层新的网络架构，将网站的内容发布到最接近用户的网络”边缘”，使用户能够就近取得所需的内容，解决Internet网络拥挤的情况，提升用户访问网站的响应速度。从技术上全面解决因为网络带宽小、用户访问量大、网点分布不均等缘由所形成的用户访问网站响应速度慢的问题。

看来上述的解释后，基本上明白了CDN是怎么回事，后来咨询了下中文站点SA，得知咱们网站目前的确尚未作CDN的优化，可是听说咱们有更加先进的技术来解决相似的问题（具体什么技术那就保密了），可是毕竟CDN也是个至关不错的技术，因此在咱们先进技术的基础上在作CDN优化，确定比如今更好，嘿嘿。听说SA明年会作几个点的CND。

 

3. Add an Expires header设置过时的HTTP Header.设置Expires Header能够将脚本, 样式表, 图片, Flash等缓存在浏览器的Cache中.

其实咱们网站也作了这个优化，至少图片在这个上作过优化，可是没有作彻底。咱们的CSS和JS都尚未作过优化，却是外部引入的一个广告JS作了，呵呵。其实设置过时的HTTP Header 更应该作在脚本, 样式表, Flash上.不过听说这个SA也是没有作的，可是有必定的风险，由于JS和CSS是有必定的逻辑，若是服务器端和客户端都存在缓存的话，万一出了什么问题，对咱们之后查找问题的所在和增长难度，不过我想二者中是能够权衡和并存的。

 

4. Gzip components 对咱们的页面内容进行Gzip格式的压缩，Gzip格式是一种很广泛的压缩技术，几乎全部的浏览器都有解压Gzip格式的能力，并且它能够压缩的比例很是大，通常压缩率为85%，就是说服务器端100K的页面能够压缩到25K左右的Gzip格式的数据发给客户端，客户端收到Gzip格式的数据后自动解压缩后显示页面。

这点咱们网站基本上是100%作到了，可是咱们这项的评分并无达到想象中的A级，缘由是出在咱们的外部连接，好比咱们首页，有外部的广告投放JS，这个JS说拥有的网站是没有作过GZIP优化，连累了咱们网站，因此咱们也只有B，或者C级：（

 

5. Put CSS at the top 把CSS放到页面的顶部。

其实这个原则咱们通常都遵照的，若是把CSS外部连接做为逻辑的一部分出如今页面头部如下，我我的以为这个自己就是个错误。还好，咱们的页面基本上都作到了，但是有些页面好比LIST页面，仍是出现了和逻辑挂钩的CSS连接，缘由是为了解决一些原本就不合理的产品逻辑。因此，咱们WEB前端工程师有义务杜绝这些不合理的产品逻辑破坏咱们的页面结果及页面加载速度，不能为了实现而实现。

 

 6. Put JS at the bottom 把Javascript脚本尽可能放到页面底部加载。

一开始为觉得Javascript脚本尽可能放到页面底部加载，是指全部的JS脚本都要放到底部，后来才发现，并不彻底是这样，这里所指的脚本是指那些在加载过程当中要执行的脚本，因此通常的处理办法仍是页面头部引入JS连接，页面底部执行JS脚本程序。为何要这么作呢？呵呵，其实很简单，为了实现最大的下载并行，页面加载初期作的事，最好只有下载，HTML的下载，CSS的下载,JS的下载，等下载完成后再去实现页面渲染，JS脚本运行。这个方面咱们还须要努力，不少页面咱们在加载过程当中运行了一部分脚本，或许是为了实现一些功能，没有办法，不过或许有更好的办法来替代呢。。。

 

7. Avoid CSS expressions 避免CSS表达式

其实在CSS中运行表达式和页面加载中运行大量的JS脚本差很少，或许还更慢，并且还不兼容，虽然可使咱们在页面逻辑简单很多，可是咱们彻底能够抛弃之。这个点，咱们的页面基本上都作到了。不过说实话，CSS表达式，嘿嘿，我之前还不知道有这么回事。惭愧。哈哈。

 

8. Reduce DNS lookups 尽量少的DNS查找。

这项咱们作的不是很好。D级，有9个域名，通常不要超过4个。不过这个主要是服务器架构上的问题，咱们也无能为力，如今单单首页的广告域名就有好几个，好耶的广告域名，雅虎的广告域名，淘宝店广告域名，打点的域名。若是去掉这些，咱们其实仍是够用的，一个主域名，一个图片的，一个STYLE的，最多加上IFREAM的恰好4个。

 

9. Minify JS 对Javascript代码进行压缩。

这点我很早之前就对此关注了，也找到了一个不错的压缩工具，yuicompressor，雅虎美国开发的JAVA压缩包yuicompressor.jar。压缩的至关完美，不只把代码间的空格换行给去除掉了，并且对变量名，北部方法名都进行的简化，无心中实现了混淆脚本的做用。如今咱们仅仅作到了JS合并，并无对齐进行压缩，若是我用yuicompressor手工的去压缩，虽然实现了JS压缩，可是给咱们本身的维护量增长了一倍，由于咱们须要维护2套JS脚本，一套是压缩前的（调试用的），一套是压缩后（发布到网上的），并且要保证2套代码一致。因此最完美的作法是在发布的时候实现JS脚本合并，并对其用yuicompressor进行压缩，而后发布到晚上，把关键点移到发布的时候，这样咱们只须要关心一套JS脚本（发布前的版本）。并且我以为这个方案彻底是行动通的。

 

10. Avoid redirects 避免重定向（跳转）

怎么理解这点呢？

咱们常常遇到的一种作法，注册成功后，旺旺会有一个页面提示“你已经注册成功，3秒后将自动跳转到XX页面”。我就以为很奇怪，你为何不直接跳转到该去的页面？还有一种，咱们你们很是熟悉，通常咱们页面的连接都写成：http://china.alibaba.com或者http://china.alibaba.com/,有人会问，有区别吗？我明确的告诉你们，有！服务器若是接收到的URL是http://china.alibaba.com，它会自动从新定向到http://china.alibaba.com/，虽然最后都打开了阿里巴巴中文站的首页，可是前者比后者多走了一步,重定向，显然多多少少浪费了必定的时间。因此之后咱们加URL连接的时候，别忘了把最后的“/”给加上去。

 

11. Remove duplicate scripts  去除重复的脚本

这个其实没有什么好说的，你们都应该毫无条件的去遵照，可是越是明显，越是简单的事，咱们每每会作很差，固然，不少理由的，项目时间太紧张了等等，致使代码很乱，不少重复的地方。其实谁都知道重负很差，不过还好，咱们的页面重复的脚本代码很少（至少一个页面里面，呵呵）。不过，我到是但愿，咱们不只要作到一个页面脚本不重复，并且要作到N个页面，脚本要重用。

 

12. Configure ETags  

这个相似last modified，客户端总会返回etag到服务端作验证，看看资源是否发生了变化，若是没有就返回304。

但他完成了一些last modified不能的，以下：

a、一些文件也许会周期性的更改，可是他的内容并不改变(仅仅改变的修改时间)，这个时候咱们并不但愿客户端认为这个文件被修改了，而从新GET;

b、某些文件修改很是频繁，好比在秒如下的时间内进行修改，(比方说1s内修改了N次)，If-Modified-Since能检查到的粒度是s级的，这种修改没法判断(或者说UNIX记录MTIME只能精确到秒)

c、某些服务器不能精确的获得文件的最后修改时间；

 

Etag由服务器端生成，客户端经过If-Match或者说If-None-Match这个条件判断请求来验证资源是否修改。常见的是使用If-None-Match.请求一个文件的流程可能以下：

====第一次请求===

1.客户端发起 HTTP GET 请求一个文件；

2.服务器处理请求，返回文件内容和一堆Header，固然包括Etag(例如"2e681a-6-5d044840")(假设服务器支持Etag生成和已经开启了Etag).状态码200

====第二次请求===

1.客户端发起 HTTP GET 请求一个文件，注意这个时候客户端同时发送一个If-None-Match头，这个头的内容就是第一次请求时服务器返回的Etag：2e681a-6-5d044840

2.服务器判断发送过来的Etag和计算出来的Etag匹配，所以If-None-Match为False，不返回200，返回304，客户端继续使用本地缓存；

流程很简单，问题是，若是服务器又设置了Cache-Control:max-age和Expires呢，怎么办？

答案是同时使用，也就是说在彻底匹配If-Modified-Since和If-None-Match即检查完修改时间和Etag以后，服务器才能返回304.(不要陷入到底使用谁的问题怪圈)

 

1三、Make AJAX cacheable

虽然ajax是异步的，但不能保证不会等待异步的这段时间，不过为避免重复的ajax请求，加上缓存也是件好事吧

 

1四、Use GET for AJAX requests

用GET方式进行AJAX请求。Get方法和服务器只有一次交互（发送数据），而Post要两次（发送头部再发送数据）。

 

1五、Reduce the number of DOM elements

减小DOM元素数量。复杂的页面结构意味着更长的下载及响应时间，更合理更高效的使用标签来架构页面，是好的前端的必备条件。

 

1六、Avoid HTTP 404 (Not Found) error

避免404错误页（非搜索结果）。

 

1七、Reduce cookie size

减少cooki体积，博客通常不须要考虑。

 

1八、Use cookie-free domains

使用无Cookie的域名。对静态组件的Cookie读取是一种浪费，使用另外一个无Cookie的域名来存放你的静态组件式一个好方法，或者也能够在Cookie中只存放带www的域名。

这里是有关静态服务器的问题，主要是指一些静态文件好比说图片、CSS等等，若是没用二级域名，那么在请求这些的时候会发送cookie下的域名，但Server又不会理他，因此会浪费带宽和时间。

若是设置了泛域名，那只能从新申请一个域名来作静态的了。

好比说YAHOO，他的静态文件都在 yimg.com 上，客户端请求静态文件的时候，减小了 Cookie 的反复传输对主域名的影响

 

 

1九、Avoid AlphaImageLoader filter

避免过滤器的使用。若是须要Alpha透明，不要使用Alpha Image Loader，它效率低下并且只对IE6及如下的版本适用，用PNG8图片。若是你非要使用，加上_filter以避免影响IE7以上的用户。

 

20、Do not scale images in HTML

不要在HTML中缩放图片。图片要用多大的就用多大的，1000x1000的图片被width=”100″height=”100″之后，自己的体积是不会减小的。

 

2一、Make favicon small and cacheable

压缩favicon. ico的体积并缓存。通常来讲favicon. ico的大小都是16x16，体积1至2k。

 

2二、Make JS and CSS external–将CSS和JS使用外部的独立文件。

看起来跟第1条有点矛盾，不过这应该看具体状况了。javascript和css都有缓存，独立成外部文件的话，有利于提升用户再次访问时的效率。而某些 大站好比yahoo，会把CSS及JS都写在页面里，那是由于访问量太大，尽量的减小请求数。若是你的网站访问量还不是那么地惊人的话，仍是独立出来比 较好。