小土鳖过冬论

马云说:要过冬了

史玉柱说:要过冬了

美国人说:Winter is coming

  现在中国整个也将全面进入过冬期,股市低迷,楼市低迷,但是最终影响的并不是这个,纵观美国经济,再到中国。为什么马云会说出过冬的话来呢,应为Alibaba面对的客户是中小企业,所以中国的中小企业将在这个严寒中倒下许多,或者合并,现在我们要做的只有等待,多积累,少花钱,避免在这次大寒冬中倒下!土鳖们要注意了,勒紧自己的裤腰带,迎接“严寒”的到来,要意志坚定的等到太阳光的照射!

:)

chrome 和 safari 对 document.styleSheets 理解的差异

chrome和safari同样的使用web kit。于是他们同时支持 document.styleSheets 。

当页面上有一个<style id=”dynamicStyle”> 我们可以利用 document.styleSheets["dynamicStyle"] 来获取到style对象。

这时需要注意了 chrome 和 safari 的返回是不一样的

从chrome的调试来看 document.styleSheets["dynamicStyle"] 返回的是一个HTMLStyleElement对象而不是真正的CSSSTyleSheet 对象。于是我们不能直接获取到cssRules.

但是safari 通过document.styleSheets["dynamicStyle"] 获取到的真正的CSSStyleSheet 对象

于是在写兼容的时候不能写成

return document.styleSheets[id] || document.getElementById(id).sheet;

需要调整一下顺序就可以兼容了

return document.getElementById(id).sheet || document.styleSheets[id];

大型站点调优高级进阶整理之YSlow

Reduce DNS lookups

首先,一个页面所需要访问的域名数量为n,那么就需要n次DNS查找,而DNS查找通常是blocking call,就是说在得到结果之后才能继续,所以越多的DNS查找,反应速度就越慢;

其次,并行下载(parallel downloading)由两个因素决定:到服务器的连接数量,以及每个连接内部的流水线请求数量。

一个页面里到服务器的连接数量由两个因素决定:

   1. 页面所需访问的域名数量,和
   2. 浏览器所允许的最多连接数

后者在Mozilla/Firefox中还由浏览器所允许最多连接数(network.http.max-connections,缺省为24),和每个服务器所允许的最大连接数(network.http.max-connections-per-server,缺省为8)决定。如果max-connection-per-server是m,那么一个需要访问n个不同域名的主机的页面,最多可以有n*m个连接 - 前提是n*m小于max-connections的值;

每个连接内部的流水线请求(pipelined requests)的数量也是浏览器的参数(Firefox上由network.http.pipelining来设置,缺省为4),前提是服务器支持persistent connection(比如在Apache设置KeepAlive为On)。之前的例子就不需要那么多的连接了(对服务器和浏览器来说,一个连接里多个流水线请求能够比多个并行连接更好些),假设pipelining的值为p,那么就可以只使用n*m/p个连接了。(BTW,对Firefox做优化的一些插件其实就是对上面的几个设置做调整)

所以减少页面内不同hostname的数量不一定会减少并行下载的数量,也要看所需要的请求(css, javascript, 图片等)的数量,因此YSlow的解释说是potentially。
USE a CDN

其目的是通过在现有的Internet中增加一层新的网络架构,将网站的内容发布到最接近用户的网络”边缘”,使用户可以就近取得所需的内容,解决 Internet网络拥挤的状况,提高用户访问网站的响应速度。从技术上全面解决由于网络带宽小、用户访问量大、网点分布不均等原因所造成的用户访问网站响应速度慢的问题。

看来上述的解释后,基本上明白了CDN是怎么回事,后来咨询了下中文站点SA,得知我们网站目前的确还没有做CDN的优化,但是据说我们有更加先进的技术来解决类似的问题(具体什么技术那就保密了),但是毕竟CDN也是个相当不错的技术,所以在我们先进技术的基础上在做CDN优化,肯定比现在更好,嘿嘿。据说SA明年会做几个点的CND。

 
Add an Expires header

给文件加上关于过期时间的header报文。

这个文件过期时间,其实就是通过header报文来指定特定类型的文件在浏览器中的缓存时间。有些文件(例如样式表中调用的背景图片和文章中调用的图片)其实在很长一段时间内我们都不会对它们有什么改变,这类文件可以设置非常长的缓存时间,这样浏览器以后就不需要再从服务器下载这些文件而直接从缓存中读取,从而大大加速网站的载入速度。

我们要做的,是在网站的.htaccess文件中写入以下内容:

<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault A600
ExpiresByType image/x-icon A2592000
ExpiresByType application/x-javascript A604800
ExpiresByType text/css A604800
ExpiresByType image/gif A2592000
ExpiresByType image/png A2592000
ExpiresByType image/jpeg A2592000
ExpiresByType text/plain A86400
ExpiresByType application/x-shockwave-flash A2592000
ExpiresByType video/x-flv A2592000
ExpiresByType application/pdf A2592000
ExpiresByType text/html A600
</IfModule>

text/css表示样式表文件,text/plain代表的纯文本类文件,依次类推。那个A2592000就表示这种类型文件在浏览器中的缓存时间,以秒为单位。一天86400秒,2592000就表示这类文件可以缓存30天。如果你不是经常修改模板,那样式表文件和javasctipt文件基本上也可以设置缓存一周到一个月左右。text/html文件不要设置太长的缓存时间,因为这些东西修改的频率很高,而且大部分blog的访客平均访问时间能到10分钟的并不多。

另外Yslow中还提到了一点就是关于文件Etag标签的设置问题,其实最佳设置方案就是关闭Etag标签。在.htaccess中写入一行如下代码即可:

FileETag None

yslow_score 优化后LifeTyper最后的Yslow得分是98分,因为我这里的stylesheet很小,javascript脚本也就一个,没有必要专门为了这两个文件开启Gzip而做优化。

CDN那部分其实是假的,你见过几个blog会给自己的空间专门购买CDN服务的?作弊只是让这个得分好看一点而已,方法很简单:

在firefox地址栏输入about:config打开FF的参数设置界面,新建一个名为extensions.firebug.yslow.cdnHostnames的字符串变量,把你的网站地址作为这个变量的值。

这样Yslow就会把你的网站当成一个CDN服务器,认为这个网站上的所有文件都是经过CDN加速的,自欺欺人玩玩而已,没什么实际用处。

利用.htaccess进行地址转向,对PageRank有一定帮助。

这种方法,就是把yourdomain.com的流量全部301转向到www.yourdomain.com(或者反过来)。其实对于这种方法,国外有人认为对PageRank没有帮助。我觉得是因为他们看到Google管理员工具中有一个首选域工具,可以指定Google的爬虫把 www.yourdomain.com或者yourdomain.com作为抓取和排名的首选域,转向似乎就没有必要了。但确实又有不少人证实这是有效的,反正目前还没有人说这种方法会对SEO或者pagerank有什么损害。

在.htaccess中写入:

Options +FollowSymlinks All -Indexes
rewriteEngine on
rewriteBase /
RewriteCond %{HTTP_HOST} ^domain.com$
RewriteRule ^(.*)$ http://www.domain.com/$1 [R=301,L]

把domain.com改成你的网站域名即可。

 
Minify JS

也找到了一个不错的压缩工具,yuicompressor,雅虎美国开发的JAVA压缩包 yuicompressor.jar。压缩的相当完美,不仅把代码间的空格换行给去除掉了,而且对变量名,北部方法名都进行的简化,无意中实现了混淆脚本的作用。现在我们仅仅做到了JS合并,并没有对齐进行压缩,如果我用yuicompressor手工的去压缩,虽然实现了JS压缩,但是给我们自己的维护量增加了一倍,因为我们需要维护2套JS脚本

 
Configure ETags
实体标签(ETags)是服务器和浏览器用于确定浏览器中缓存的组件和服务器中的是否对应的一种机制。(”entity”是组件的另一种说法:图片、脚本、样式表等等)添加ETags用于辨别组件提供了比最后修改时间更为灵活的机制。ETag是一个唯一标识组件的特定版本的字符串。它的唯一格式规范是字符串比去被引号引用。来源服务器使用ETag响应头来设定一个组件的ETag:

      HTTP/1.1 200 OK
      Last-Modified: Tue, 12 Dec 2006 03:03:59 GMT
      ETag: “10c24bc-4ab-457e1c1f”
      Content-Length: 12195

 

当浏览器晚些时候需要检测一个组件时,它使用If-None-Match 头部把ETag传回来源服务器。如果ETag匹配了,会返回一个304状态码,在这个例子里它会减少12195个字节的响应:

      GET /i/yahoo.gif HTTP/1.1
      Host: us.yimg.com
      If-Modified-Since: Tue, 12 Dec 2006 03:03:59 GMT
      If-None-Match: “10c24bc-4ab-457e1c1f”
      HTTP/1.1 304 Not Modified

 

ETag的问题是他们往往在网站的一个服务器中被设为唯一的,当浏览器从一个服务器得到了组件并在稍后试图到另一个服务器验证时,ETag会不匹配,而这在使用多个服务器来处理请求的网站中是很常见的。默认情况下,Apache和IIS在ETag中嵌入的数据戏剧性的减少了应用多台服务器的网站的 ETag验证成功几率。

 

Apache1.3和2.新版本的ETag格式是inode-size-timestamp。虽然一个给定的文件在多台服务器中处于同一个目录,而且有同样的大小,权限,时间戳,但它的inode在不同服务器中是不同的。

 

IIS5.0和6.0有同样的问题。IIS中ETag的格式是Filetimestamp:ChangeNumber。ChangeNumber用来跟踪IIS配置的改变次数。一个网站的所有IIS不可能有相同的ChangeNumber。

 

这导致的结果是,Apache和IIS对完全相同的组件产生的ETag在不同服务器间不能匹配。如果ETags不匹配,用户不会得到小而快的304响应,而是一个普通的200响应和组件的所有数据。如果你把你的网站放在了一个服务器里,这不会是一个问题。但如果你的网站有多台服务器,而且你使用了Apache和IIS默认的ETag配置,你的用户会访问页面的速度会变慢,你的服务器加载的程度更高,消耗了更大的带宽,代理服务器不能有效的缓存你的内容。即使你的组件有一个ar future Expires头部,当用户重载或者刷新页面时,依然会发送一个GET请求。

 

如果你不打算利用ETags提供的灵活的验证模式,你最好把ETag统统移除。Last-Modified头部的验证方式给予组件的时间戳。移除ETag同时减少响应和随后的请求中的HTTP头部大小。这篇微软的支持文档描述了怎样在移除ETags。在Apache中,你只要在Apache配置文件中添加如下一行:

     FileETag none

在线生成GIF旋转图标

Loadinfo可以在线生成GIF旋转图标,使用Loadinfo很简单,从它给出的GIF图片库里面选择一下,然后调整前景和背景颜色,设置图片大小,是否透明,然后点击生成即可下载该GIF图标。

  

访问:http://www.loadinfo.net/

回归!

服务器更新为Linux,总算回来了,我的博客,我的家,没有博客的日子!