有关web效率

1)web开发的特点是是：没有太复杂的技术难点，一切在于迅速的把握需求，其实这正式敏捷开发的要旨所在，一切都可以非常快速的建立，非常快速的重构，我们的开发工具，底层库和框架，包括搜索引擎和web文档提供的帮助，都提我们供给了敏捷的能力。

2)此外，相应的，最有效率的交流方式必须留给web开发，那就是face2face（面对面），不要太担心你的设计不能被完备的文档所保留下来，他们会以交流，代码和小卡片的方式保存下来

3)人的因素会更加重要，无论是对用户的需求，还是开发人员的素质。

另：有关web效率，有著名的14条规则，由yahoo性能效率小组所总结，并广为流传。业已出现相关插件（YSlow），14 rules列在下面：

１． Make Fewer HTTP Requests

减少http请求次数

Image maps 　图像中增加ｕｒｌ可以将多个图片合为一个，减少http请求。

CSS Sprites 　通过css 将图片引入到页面中减少页面请求http 。

Combined files合并文件不如合并多个请求的javascript为一个。减少http请求。

http://developer.yahoo.net/blog/archives/2007/04/rule_1_make_few.html

２． Use a Content Delivery Network

３． Add an Expires Header

在下载的css、js、image组件里增加过期时间

４． Gzip Components

（对下载的组件进行压缩）

毫无疑问，对站点内容进行压缩是一个比较常用的 Web 优化手段．但是并不一定都能达到理想的效果．原因在于 mod-gzip 模块不但消耗服务器端 CPU资源，也消耗客户端 CPU资源. 而且, mod_gzip 压缩文件后创建的临时文件是放到磁盘上的，这也会给磁盘 IO带来严重的问题.

Flickr 采用的是 Httpd 2.x 以后支持的　mod_deflate 模块．压缩操作都在内存中进行．mod_deflate 在 Httpd 1.x 是不可用的, 不过可以通过创建 RAM盘的方式来间接提高性能．

当然, mod_gzip 到也不是一无是处, 对于预压缩的文件, 还是有好处的. 而且, 采用压缩的时候,也要注意策略. 图片文件压缩就没什么必要了(Flickr 上图像多, 而且压缩得不到什么好处). Flickr 只对JavaScript 和 CSS进行压缩. mod_gzip 新一点的版本能够自动通过配置 mod_gzip_update_static 选项自动处理预压缩的文件. Cal 也指出这个特性在一些旧版本的浏览器上会出问题.

压缩的另一个主要手段是内容的压缩. 针对 JavaScript 可以进行通过减少注释、合并空格、使用紧凑的语法等小技巧(Google 的所有脚本都非常难读，而且非常紧凑，思想类似).当然，经过这样处理的 JavaScript 可能带了很多括号不容易解析，Flickr 使用了 Dojo Compressor 来构建解析树。Dojo Compressor 开销很低，而且对于最终用户是透明的. JavaScript 的处理方法介绍过，CSS 处理则相对简单.通过简单的正则表达式替换(比如把多个空格替换为一个空格符), 最高可以获得 50% 的压缩比。

５． Put CSS at the Top

css文件尽可能放在页面的最上面

· Move Scripts to the Bottom

js文件尽可能放在页面的最下面

6。Put JS components as close to the bottom of the page as possible.

（js文件尽可能放在页面的最下面）

7。Avoid CSS Expressions

（在css文件中慎用表达式）

8。Make JavaScript and CSS External

（在外部包含js和css文件）

9。Reduce DNS Lookups

（减少请求中域名的解析次数）

10。Minify JavaScript

（js代码压缩）

11。Avoid doing redirects.

（避免重定向）

12。Remove Duplicates Scripts

（避免请求重复的js文件）

13。Configure ETags

（配置好ETag）

Flickr 的开发者充分利用了 Http 1.1 规范定义的 Etag 与 Last-Modified 机制 来提高 Caching 的效率. 值得注意的是，Cal 介绍了一个在负载均衡条件下的 e-Tag 小技巧. 即可以设定 Apache 通过文件调整时间与文件大小获得 E-Tag ,而默认情况下, Apache 是通过文件节点获取 e-Tag 的。当然，这也不是很完美，因为会影响 if-modified-since 。

但是有的网站的e-Tag，如yahoo，其产生规则是基于节点的。相同的css或js脚本在不同节点服务器上的e-Tag不同，所以如果有n个服务器，那么浏览器获得304应答消息的概率是1/n。

14。Make Ajax Cacheable

（缓存Ajax请求）

以下几点是新增的准则，还没有正式公布，所以大家要注意，

15。Flush the Header

（先发送Header里的信息）

We improved the page load times by flushing the apache output buffer after the document HEAD was generated.This had two benefits.

First, the HEAD contains SCRIPT and LINK tags for scripts and stylesheets. By flushing the HEAD, those tags are received and parsed by the browser sooner, and in turn the browser starts downloading those components earlier.

Second, the HEAD is flushed before actually generating the search results. This is a win for any property doing a significant backend computation or especially making one or more backend web service calls.

16。Split Static Content Across Multiple Hostnames

（把较大的静态文件分割成不同域的请求）

If you have many (10 or more) components downloaded from a single hostname, it might be better to split those across two hostnames.

17。Reduce the Size of Cookies

（不要让Cookie内容过大）

Reduce the amount of data in the cookie by storing state information on the backend, and abbreviating names and values stored in the cookie. Set expiration dates on your cookies, and make them as short as possible.

18。Host Static Content on a Different Top-Level Domain

（把静态文件放在不同的顶级域名下）

19。Minify CSS

（Css代码压缩）

20。Use GET for XHR

（有XHR时使用GET请求）

Iain Lamb did a deep study of how using POST for XMLHttpRequests is inefficient, especially in IE. His recommendation: “If the amount of data you have to send to the server is small (less than 2k), I suggest you design your webservice / client application to use GET rather than POST。

21。Avoid IFrames

（尽量避免使用IFrame）

Don’t use SRC (set it via JS instead). Each IFrame takes 20-50ms, even if it contains nothing

22。Optimize images

（优化图片）