解决Google(谷歌)服务不可用导致WordPress后台缓慢的问题

因为某些原因近期Google的大部分服务无法使用,特别是谷歌字体和一些公共库的调用问题,因为浏览器加载这些资源多是阻塞形式的,如果不能及时获取资源,那么浏览器将一直在等待,这样就会影响页面其他元素的渲染,对于用户来说,就会表现为页面加载缓慢或者打开困难。

因为我的博客之前调用了Google的字体服务,所以前一段时间打开页面时出现了这类现象,通过FireBug调试找到是Google字体的原因。搜索网络后找到了替代的办法,那就是使用360提供的前端公共库CDN服务缓存库

这些公共库主要分为:常用前端公共库Google前端公共库Google免费字体库

继续阅读

博客改版采用新主题界面

由于不能忍受先前的在官方Twenty Eleven主题基础上定制的自用主题Blaue的种种Bug,所以决定重新定制一个新的主题自用,实在想不出什么好的名字,姑且就叫做Blaue V2吧,Blaue这个词是由于之前主题的主色调是Black & Blue,所以造出了这么个词,现实中貌似还真有这么个词,不过好像是德文,好了,扯多了,下面谈谈这次主题改造的细节吧。

这次主题改的母版是toolbox主题,但是改动比较大,特别是将Blaue的部分构架融合过来了,而之前的Blaue是基于Twenty Eleven主题的,算是混血儿,所以这次Blaue V2只算是在Blaue基础上做的改进。

1. 放弃了响应式自适应的流布局,采用固定布局模式,固定布局容易操作些,不容易错位,也能很好兼容大多数浏览器。

2. 采用JQuery库,原先我一直很抵触背这么大个JS库的,之前使用的纯JavaScript代码来实现相关功能,后来采用Sizzle选择器(也是JQuery内置的选择器),现在想想干脆直接用JQuery得了,省得为兼容问题而纠结。

3. 采用Google Web Font优化部分英文字体显示。

4. 菜单挪到了顶部,采用当前比较流行的设计样式,本来想把字体大小那段也弄到顶部的,但是感觉有点奇怪,所以作罢。

5. 评论这块采取了NeoEase的做法,将网友讨论和Trackbacks(Pingbacks)用选项卡进行分离,避免阅读评论的干扰,评论发布采用了Ajax技术,但是感觉发布成功这块处理得不是很好的。

6. 404找不到页面和搜索页面单独进行了优化,搜索页面除了显示本站结果外还将用选项卡分割显示Google自定义搜索的结果。

继续阅读

谷歌广告(Adsense)已经采用非阻塞方式(non-blocking)加载

我在2月份的时候写过一篇名叫《避免谷歌广告影响页面加载速度》的文章,其中参考了Aaron Peters提供的广告加载的方法,之所以谷歌广告会卡住页面或者影响页面速度主要是因为谷歌广告是阻塞式加载,当时提出的避免办法是将广告放在页底,这样让内容先呈现出来,最后再加载广告。Aaron Peters的想法是好的,只不过这种方法在非IE内核浏览器中存在一些问题,最后Aaron Peters不得不提示不要使用这个技巧:

Important: Will Alexander posted a comment about the failure of this trick: it may (and often will) result in double impressions for ads served to visitors with Gecko (Firefox) and WebKit (Chrome) browsers. Do Not Use This Trick!!!

据有读者反馈,在Chrome下出现了例如加载不显示等问题,所以我觉得这种技巧还是少用为妙。

难道我们没有其他办法解决这个问题吗?难道任由谷歌Adsense卡住我们的页面?可能一些没有用任何技巧加载谷歌广告的童鞋可能惊喜的发现现在页面打开速度变快了,谷歌广告不再卡住页面了。难道是谷歌官方更改了广告加载模式?

继续阅读

某些场景下请不要省去URL链接地址后的斜杠

今天在访问某个博客时,看到某位网友评论上留的网址类似于这样//wangye.org/blog(这里以我的博客作为例子),这样貌似没有什么问题,也能正常打开这个博客,大家可能注意到在打开博客时网址自动变为//wangye.org/blog/(多了个斜杠),为什么会这样,因为大多数人包括我喜欢将博客放到自己域名下的Blog文件夹里,那么//wangye.org/blog指的是wangye.org下blog这个文件,当然我们只有blog这个文件夹,那么服务器会返回如下的301转向信息:

1
2
3
4
5
6
Server: Apache/2
Location: http://wangye.org/blog/
Content-Length: 293
Keep-Alive: timeout=1, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

很明显,服务器做了一次判断,进行了一次301转向,浏览器也进行了重新定向才定位到正确的/blog/文件夹,表面上看这没有什么问题,但是对于链接来说,当浏览者访问类似于//wangye.org/blog这样的链接时,必然会对服务器造成资源负担,访问量少时没有什么,当流量比较大时不必要的资源浪费就比较可观了,还有据说这种转向不利于搜索引擎蜘蛛的抓取,所以请在这种情形下网址保留最后个斜杠,写成//wangye.org/blog/ 吧。

IE6设置BackgroundImageCache背景图片缓存解决闪烁问题

今天在分析拍拍网页面时注意到下面这段脚本:

1
2
3
4
5
6
7
<!--[if IE 6]>
<script type="text/javascript">
// <![CDATA[
  document.execCommand("BackgroundImageCache", false, true);
// ]]>
</script>
<![endif]-->

当看到这段脚本时觉得非常好奇,这对于IE6做了什么限制?通过搜索知道,IE6默认不缓存背景图片,CSS每次更改图片的位置时都会重新发起图片请求,这样对于视觉上有一定的闪烁,但是我过去的项目竟然感觉不到这样的问题,后来发现原来我一直用CSS Sprite解决这类加载问题的(貌似CSS Sprite也会造成这种情况,难道是本地测试看不出来?)。看来今天又学到了一招,搞前端的也真不容易,尤其是那个让人无语的Internet Explorer 6。

下面再贴出一种不推荐的办法,那就是CSS里写入expression,为什么不推荐,主要是因为效率问题,CSS expression都会带来效率上的问题,所以要避免使用。

1
2
3
html {
  filter:expression(document.execCommand("BackgroundImageCache",false,true));
}

最后我把拍拍网上的那段代码结合网上的一些讲解改动如下:

1
2
3
4
5
6
7
8
9
<!--[if IE 6]>
<script type="text/javascript">
//<![CDATA[
try {
  document.execCommand("BackgroundImageCache", false, true);
} catch(e) {}
//]]>
</script>
<![endif]-->

END

使用Closure Compiler压缩并优化JavaScript性能

大家可能还记得之前我写的《使用YUI Compressor优化你的网页》这篇文章,主要介绍的是雅虎的YUI Compressor工具,这个工具主要用来压缩JavaScript或CSS,当然效果不错,近日在逛Google Code时偶然发现了个好东东Closure Compiler,恩,也是今天介绍的主角。这个是做什么用的呢?看到我的文章标题,大家心里应该有数了吧,Closure Compiler是个强大的脚本优化利器,其主要是用来优化JavaScript,那我为什么还要说压缩呢,原来其在优化的过程中会压缩相应的JS脚本,比如把长变量名变成短变量名,这点和YUI Compressor类似,但是这两个东东究竟有什么区别呢,我认为YUI Compressor强调的是压缩,Closure Compiler强调的是优化,当然明显Closure Compiler要强大些,具体的区别也已经有人总结过了,大家可以移步这里

在其项目主页上可以看到下面的介绍:

Closure Compiler is a JavaScript optimizing compiler. It parses your JavaScript, analyzes it, removes dead code and rewrites and minimizes what’s left. It also checks syntax, variable references, and types, and warns about common JavaScript pitfalls. It is used in many of Google’s JavaScript apps, including Gmail, Google Web Search, Google Maps, and Google Docs.

看来功能真的很强大,许多谷歌应用都采用了这个东东进行优化,看来其是有谷歌官方背景的,这样我们可以放心大胆的用到我们项目里,提升我们的脚本性能了。

说了这么多,下面我就简单的介绍下如何获得并使用。

首先登录项目主页closure-compiler,然后下载程序包。解压下来,大家可能发现这是个Java程序,虽说是个Java程序,但是.jar文件已经有4MB多大小,足见其源代码的规模也不小。

当然想要运行的话,计算机上必须安装JRE的Java运行时环境,没有安装的童鞋可以在这里下载

我们把compiler.jar复制到指定的目录下,然后通过下面的命令行进行相关操作。

java -jar compiler.jar –js=src.js –js_output_file=dest.js

其中–js所指示的src.js就是待优化的脚本源文件,–js_output_file所指示的就是优化压缩好的脚本目标文件。

不过使用IE条件注释的童鞋会发现,原来的条件注释被过滤掉了,非常遗憾,这个东东暂时还不能支持IE的条件注释,我建议先用(function(){/*TODO : Code*/})();闭包的形式闭包住条件注释里的脚本代码,然后去掉外围的条件注释Wrapper,然后让条件注释里的代码一起参与优化,由于这些代码是闭包的,当然就很容易在优化过的代码中区别出来,然后再加上条件注释的Wrapper就可以了。

使用pngout和RIOT压缩优化你的图片

很多朋友在完成一份网页作品时往往欣喜不已,尤其是在本地浏览时的那份UI的完美呈现,但是在实际部署时往往发觉网页的浏览会很慢,尤其是在小水管网速的情况下,使用PageSpeed查看发现原来是图片拖累了加载速度,当然PageSpeed也很厚道的提供了份压缩好的图片给我们,我们可以直接用PageSpeed压缩的图片,在网页前端完成后我们往往会忽略很多后续工作,压缩优化图片就是其中一项重要的工作。

下面我向大家介绍下压缩图片的小工具,具体的效果由个人把握,当然减少体积的前提是损失质量,具体还要看大家权衡。

PNGOUT
一个非常好用的小工具,我们可以访问Ken Silverman的主页以获取其最新版本,下载好PNGOUT.EXE然后将其放至指定目录,当然这是控制台程序,也就是说我们必须在命令提示符的状态下才能使用。简单的命令如下:

pngout 输入文件 输出文件

比如pngout logo.gif logo_out.png,那么logo_out.png就是我们压缩好的,输入文件支持png、gif、bmp、jpg、tga、pcx等格式,输出文件貌似只支持压缩成png。当然还有很多指示压缩级别的开关选项,具体可以查看作者给我们提供的在线手册

RIOT
如果说大家对PNGOUT控制台命令行过敏的话不妨试试这个,我们可以访问其官方主页获得最新版本,不过貌似其官方网站上始终下载不了,我后来在国外某知名下载站点弄到后放在这里提供给不能下载的童鞋们,RIOT给我们提供了一个易用的GUI,当然更重要的是其可以压缩输出jpg、gif、png等3种格式,基本囊括了网页上使用的图片,如果大家对刚才介绍的PNGOUT恋恋不舍的话,我们的RIOT可以将PNGOUT作为插件进行调用,这样我们可以借用RIOT的壳然后用PNGOUT的内核进行PNG图片的压缩,怎么样够强大的吧,当然你需要把刚才下载的PNGOUT.EXE放在RIOT安装目录的plugins文件夹下,然后启动RIOT并切换到PNG选项卡,然后如下图设置:

RIOT使用PNGOut

具体怎么使用我相信很简单,那些洋文应该难不倒大家,不过要提醒的是在没有熟练使用前记得备份你的源文件哦。

2011年5月11日更新

最近经常在公共电脑上写文章,图片本地压缩比较麻烦,不过我找到一个在线压缩的,还是比较方便的,网址:http://www.punypng.com/

使用YUI Compressor优化你的网页

YUI Compressor是做什么的

这个小工具主要是用来压缩CSS和JavaScript文件的,当然你觉得可以混淆这些文件里的代码也是可以的,不过我们使用它还是看中其压缩优化的功能。

为什么要优化

因为这样可以减少网页传输中不必要的字节数,节省带宽,加快页面访问速度,具体优化守则可以参考雅虎网页优化14条准则

使用YUI Compressor的好处

方便快捷,压缩后的代码文件体积小,有效率高,当然市面上不乏有很多压缩工具,但是很多工具尤其在处理压缩一些大型脚本后往往导致脚本出错失效,这点我对YUI Compressor很放心,毕竟有雅虎这个大公司的技术支持,至少我用到现在没有压坏一个脚本。

如何获取YUI Compressor

下载地址
http://yuilibrary.com/downloads/#yuicompressor

项目主页
http://developer.yahoo.com/yui/compressor/

但是有些朋友下载下来可能会有些小小的失望,为什么呢?因为这个工具是用Java编写的,也就是说我在使这个工具生效前还必须安装Java的运行环境,当然已经安装了的话,我们就可以接着开始了,关于Java运行环境JRE的下载见这里

如何使用

将下载到的YUI Compressor包中的yuicompressor-2.4.2.jar拷贝到指定的目录下。然后通过下面的命令行进行相关操作。

压缩优化JavaScript
java -jar yuicompressor-2.4.2.jar –type js –charset utf-8 -v orginal.js > packed.js

压缩优化CSS
java -jar yuicompressor-2.4.2.jar –type css –charset utf-8 -v orginal.css > packed.css

可见–type指定了压缩文件的类型,–charset指定了压缩文件的编码,紧接着-v开关后面是要压缩的源文件orginal,>后是压缩好的文件packed。

对于CSS的压缩,我发现了一点奇怪的现象,比如形如 body {color:#000;background:#fff} 会变成 body {color:#000;background:#fff;},最后花括号前面的分号是可以省略的,我一直也是省略的写法,不晓得为什么压缩后又添加上去了。

避免谷歌广告影响页面加载速度

也许大家喜欢往自己的站点上放点广告来捞取外快,但是当确实这么做时却发现网页的加载速度变慢了,为什么呢?

因为目前浏览器总是阻塞式(blocking)的读取网页引用的外部JavaScript,所以雅虎网页优化14条准则中也提到把外部引用的脚本放在页面的底部,差不多是</body>之前。这样网页基本上能最快渲染完毕,然后再加载这些外部脚本。

好了,了解这么多,大家肯定想这样广告只能显示到页面底部了,我想自定义广告的位置该怎么办?Aaron Peters给出了个办法,大家可以参考他博客上的这篇文章《Non-blocking Google Adsense ads: improve page speed》,也就是说我们可以在要放广告的地方放置一个div层,然后把页面底部的广告脚本代码appendChild加载到这个层即可。

不过我不太明白的是为什么Aaron Peters要把页面底部的广告层设置为display:block,貌似这样加载页面的时候,底部会先出现广告,然后才加载至指定位置的层,起初我是这样想的,首先把底部位置的广告层设置为display:none,然后加载至指定位置时再display:block,想法很好,但是实际操作的时候,广告死活显示不出来,经过摸索,终于找到了解决方案,也就是说,在底部的广告代码层的display:block,但是外面再套个display:none的层,这样基本就完美了,下面分享下我的做法。(注:发现原来是自己脚本写错了实际这个方法也是可以的)

1
2
3
4
5
6
7
8
9
10
11
function speed_ads() {
	var ad = document.getElementById('adsense'),
		loader = document.getElementById('adsense-loader');
	if (ad && loader) {
		ad.appendChild(loader);
		loader.style.display='block';
		ad.style.display='block';
		ad.style.height='60px';
	}
}
window.onload=function() {speed_ads();}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<html>
 <head>
 <!--上述脚本位置-->
 </head>
 <body>
   <!--指定的广告显示位置-->
   <div id="adsense"></div>
   <!--其他内容位置-->
   <p></p>
   <p></p>
   <!--广告代码位置-->
   <div style="display:none">
     <div id="adsense-loader" style="display:block">
       <script type="text/javascript">
       // 谷歌广告代码
       </script>
     </div>
   </div>
 </body>
</html>

有网友给Aaron Peters指出了个问题,原文如下。

Important: Will Alexander posted a comment about the failure of this trick: it may (and often will) result in double impressions for ads served to visitors with Gecko (Firefox) and WebKit (Chrome) browsers. Do Not Use This Trick!!!

大概意思是在Gecko核心 (Firefox) 和 WebKit核心 (Chrome)的浏览器下,广告的展示会变为两次?我试了下,暂时没有发现异常,如果有朋友发现问题的话记得告诉我哦:-)

2011年8月26日更新

看到Aaron Peters的这篇文章又有了更新,谷歌广告已经支持非阻塞(Non-blocking)方式加载广告了:

Adsense releases non-blocking Adsense!
Yes, it happened, finally: Google has released a new version of the Adsense show_ads.js file that loads in a non-blocking way. Per today, March 18 2011, Google serves it to Chrome, Firefox and IE8 browsers and support for more browsers is coming. As a bonus: publishers do not have to change their code! Read the Google Code blog post about the new Adsense code(注:由于特殊原因,这里的链接我就不放了,大家可以到作者那篇文章上去找下。)

我试了一下,确实不再卡住页面了,看来谷歌的技术还是比较强大的!

巧用htaccess客户端网页缓存实现网站加速

网站加快访问速度的一个基本原则就是减少HTTP请求数,在我们实现了合并CSS和脚本,使用了图片CSS Sprites后,发现YSlowPageSpeed的评分并没有提高(当然淘宝UED团队给了我们一个新的优化思路,不必拘泥于这两个工具,详细请见这里),仔细研究后才发现原来我们没有很好的利用客户端缓存,仔细分析了淘宝等大网站的HTTP反馈信息如下。

淘宝网

1
2
3
Date: Tue, 22 Feb 2011 14:02:56 GMT
Expires: Tue, 22 Feb 2011 15:02:56 GMT
Cache-Control: max-age=3600

腾讯QQ

1
2
3
Date: Tue, 22 Feb 2011 14:04:26 GMT
Expires: Tue, 22 Feb 2011 14:19:26 GMT
Cache-Control: max-age=900

网易163

1
2
3
Date: Tue, 22 Feb 2011 14:07:35 GMT
Expires: Tue, 22 Feb 2011 14:08:21 GMT
Cache-Control: max-age=80

都可以看到这些网站有个共同点就是使用了Cache-Control控制了客户端的网页缓存,这样,客户端在频繁访问网站时不必每次都向服务器发出请求,大大提高访问的速度和减轻了服务器的负担。

Cache-Control的关键部分就在于max-age,其值代表缓存的时间,单位为秒,对于较快更新的网站这个时间应该短一些,对于更新较慢的网站,这个时间应该长一些,对于个人博客,我认为这个值可以设定为600(10分钟),当然如果时间过长的话,可能评论文章需要刷新或等待指定时间过后才能看见。

对于客户端缓存控制,还有Pragma和ETag值得注意,一般情况下Param: no-cache,代表不缓存文件,当然我们要缓存就必须去掉这项,有关ETag,在查询HTTP反馈后发现是一个标识符,也就是说客户端在收到这个页面的时候会记下这个ETag标识,当再次访问时,客户端将把这个ETag发回给服务器,服务器在收到这个ETag后,会与当前的ETag进行对比,如果一致,代表页面没有改动,直接反馈304 Not Modified的消息,这样浏览器就直接在本地取出缓存页面。实际考察下来发现大多数Web应用均没有实现对ETag的管理控制,所以保留这个信息对于这些应用来说纯属浪费,完全可以去掉,去掉Pragma和ETag头信息可以在.htaccess输入下面两行。

1
2
3
4
5
<FilesMatch ".(html|htm|php|txt)$">
Header unset Pragma
Header unset ETag
FileETag None
</FilesMatch>

其中html|htm|php|txt对应的是要处理的文件类型扩展名。再解决了这两项后,下面可以添加Cache-Control信息了,这里我们设定为10分钟。原来的.htaccess配置如下。

1
2
3
4
5
6
<FilesMatch ".(html|htm|php|txt)$">
Header unset Pragma
Header unset ETag
FileETag None
Header set Cache-Control "max-age=600"
</FilesMatch>

同样的道理,我们知道一般网站上图片、样式表、脚本文件等等都是基本上不改动的,我们可以通过下面的代码将其缓存时间设定长一些。

1
2
3
4
5
6
<FilesMatch ".(gif|jpg|jpeg|png|ico|css|js)$">
Header unset Pragma
Header unset ETag
FileETag None
Header set Cache-Control "max-age=315360000"
</FilesMatch>

怎么样,是不是觉得时间太长了,假如我要改个样式,客户端可能需要刷新才能看见,那怎么办?我们知道,前面对于网页设置了个比较短的时间,也就是说网页在那个时间过后就需要重新到服务器上获取最新版。我们可以在引用的样式表style.css的后面加上style.css?t=20110222这样的时间戳,当然为了照顾一些特殊的浏览器,一般建议这样写style.css?t=20110222.css,当你改动了样式表后,你只需要对网页里的link引用的样式表时间戳进行修改即可。

1
<link rel="stylesheet" href="style.css?t=20110222.css" type="text/css" />

好吧,做完这些,我们可以歇口气喝杯咖啡了?等等,你会发现把配置好的.htaccess文件上传到网站根目录下,然后你登录博客后台时一些后台操作变得不正常了,比如我们删掉一条记录,系统提示删除成功,但是当你返回的时候,发现那条记录仍然存在,真的是这样吗?当你再刷新下该页,才发现那条记录已经没了,聪明的你应该晓得是怎么回事了,对!就是缓存在作怪。

所以我们需要去掉后台管理页面的缓存,假设后台管理路径是/admin/,我们可以针对该文件夹单独配置个.htaccess,内容如下。

1
2
3
4
5
6
<FilesMatch ".(html|htm|php|txt)$">
Header unset ETag
FileETag None
Header set Cache-Control "no-cache, no-store, max-age=0, must-revalidate"
Header set Pragma "no-cache"
</FilesMatch>

好了,就是这么简单,做完这一切,现在访问你的网站看看,是不是感觉不错:-)

另外还有种设置缓存的方法可以参考《How to Set an Expires Header in Apache》这篇文章。