Google排名优化-面向Google(Search Engine Friendly)的URL设计

没有评论

2010 年 10 月 15 日 at 下午 6:32分类:WEB开发

Google排名优化-面向Google(Search Engine Friendly)的URL设计
作者:车东 发表于:2003-05-10 18:05 最后更新于:2007-04-12 11:04
版权声明:可以任意转载,转载时请务必以超链接形式标明文章原始出处和作者信息及本声明。

http://www.chedong.com/tech/google_url.html

内容摘要:不得不承认,将动态网页链接rewriting成静态链接是最保险和稳定的面向搜索引擎优化方式

此外随着互联网上的内容以惊人速度的增长也越来越突出了搜索引擎的重要性,如果网站想更好地被搜索引擎收录,网站设计除了面向用户友好(User Friendly)外,搜索引擎友好(Search Engine Friendly)的设计也是非常重要的。进入搜索引擎的页面内容越多,则被用户用不同的关键词找到的几率越大。在Google的算法调查一文中提到一个站点被Google索引页面的数量其实对PageRank也是有一定影响的。由于Google 突出的是整个网络中相对静态的部分(动态网页索引量比较小),链接地址相对固定的静态网页比较适合被Google索引(怪不得很多大网站的邮件列表归档和BLOG按日期归档的文档很容被搜的到),因此很多关于面向搜索引擎 URL设计优化(URI Pretty)的文章中提到了很多利用一定机制将动态网页参数变成像静态网页的形式:
比如可以将:

http://phpunixman.sourceforge.net/index.php?mode=man¶meter=ls

变成:http://phpunixman.sourceforge.net/index.php/man/ls

实现方式主要有2种:

* 基于url rewrite
IIS的ISAPI REWRITE下载(免费)
* 基于path_info

把URI地址用作参数传递:URL REWRITE

最简单的是基于各种WEB服务器中的URL重写转向(Rewrite)模块的URL转换:
这样几乎可以不修改程序的实现将 news.asp?id=234 这样的链接映射成 news/234.html,从外面看上去和静态链接一样。Apache服务器上有一个模块(非缺省):mod_rewrite:URL REWRITE功能之强大足够写上一本书。

当我需要将将news.asp?id=234的映射成news/234.html时,只需设置:
RewriteRule /news/(\d+)\.html /news\.asp\?id=$1 [N,I]
这样就把 /news/234.html 这样的请求映射成了 /news.asp?id=234
当有对/news/234.html的请求时:web服务器会把实际请求转发给/news.asp?id=234

而在IIS也有相应的REWRITE模块:比如ISAPI REWRITE和IIS REWRITE,语法都是基于正则表达式,因此配置几乎和apache的mod_rewrite是相同的:

比对于某一个简单应用可以是:
RewriteRule /news/(\d+)\.html /news/news\.php\?id=$1 [N,I]
这样就把 http://www.chedong.com/news/234.html 映射到了 http://www.chedong.com/news/news.php?id=234

一个更通用的能够将所有的动态页面进行参数映射的表达式是:
把 http://www.myhost.com/foo.php?a=A&b=B&c=C
表现成 http://www.myhost.com/foo.php/a/A/b/B/c/C。
RewriteRule (.*?\.php)(\?[^/]*)?/([^/]*)/([^/]*)(.+?)?$1(?2$2&:\?)$3=$4?5$5: [N,I]

以下是针对phpBB的一个Apache mod_rewrite配置样例:

RewriteEngine On
RewriteRule /forum/topic_(.+)\.html$ /forum/viewtopic.php?t=$1 [L]
RewriteRule /forum/forum_(.+)\.html$ /forum/viewforum.php?f=$1 [L]
RewriteRule /forum/user_(.+)\.html$ /forum/profile.php?mode=viewprofile&u=$1 [L]

这样设置后就可以通过topic_1234.html forum_2.html user_34.html这样的链接访问原来的动态页面了。

通过URL REWRITE还有一些好处:
mod_rewrite和isapirewrite基本兼容,但是还是有些不同,比如:isapirewrite中”?”需要转义成”\?”,mod_rewrite不用,isapirewrite支持 “\d+” (全部数字),mod_rewrite不支持

* 隐藏后台实现:这在后台应用平台的迁移时非常有用:当从asp迁移到java平台时,对于前台用户来说,根本感受不到后台应用的变化;
* 简化数据校验:因为像(\d+)这样的参数,可以有效的控制数字的格式甚至位数;

比如我们需要将应用从news.asp?id=234迁移成news.php?query=234时,前台的表现可以一直保持为 news/234.html。从实现应用和前台表现的分离:保持了URL的稳定性,而使用mod_rewrite甚至可以把请求转发到其他后台服务器上。
基于PATH_INFO的URL美化

Url美化的另外一个方式就是基于PATH_INFO:
PATH_INFO是一个CGI 1.1的标准,经常发现很多跟在CGI后面的”/value_1/value_2″就是PATH_INFO参数:
比如:http://phpunixman.sourceforge.net/index.php/man/ls 中:$PATH_INFO = “/man/ls”

PATH_INFO是CGI标准,因此PHP Servlet等都有的支持。比如Servlet中就有request.getPathInfo()方法。
注意:/myapp/servlet/Hello/foo的 getPathInfo()返回的是/foo,而/myapp/dir/hello.jsp/foo的getPathInfo()将返回的 /hello.jsp,从这里你也可以知道jsp其实就是一个Servlet的PATH_INFO参数。ASP不支持PATH_INFO
PHP中基于PATH_INFO的参数解析的例子如下:
//注意:参数按”/”分割,第一个参数是空的:从/param1/param2中解析出$param1 $param2这2个参数
if ( isset($_SERVER["PATH_INFO"]) ) {
list($nothing, $param1, $param2) = explode(‘/’, $_SERVER["PATH_INFO"]);
}

如何隐蔽应用:例如 .php,的扩展名:
在APACHE中这样配置:

ForceType application/x-httpd-php

如何更像静态页面:app_name/my/app.html
解析的PATH_INFO参数的时候,把最后一个参数的最后5个字符“.html”截断即可。
注意:APACHE2中缺省是不允许PATH_INFO的,需要设置 AcceptPathInfo on

特别是针对使用虚拟主机用户,无权安装和配置mod_rewrite的时候,PATH_INFO往往就成了唯一的选择。

OK,这样以后看见类似于http://www.example.com/article/234这样的网页你就知道可能是 article/show.php?id=234这个php程序生成的动态网页,很多站点表面看上去可能有很多静态目录,其实很有可能都是使用1,2个程序实现的内容发布。比如很多WIKIWIKI系统都使用了这个机制:整个系统就一个简单的wiki程序,而看上去的目录其实都是这个应用拿后面的地址作为参数的查询结果。

利用基于MOD_REWRITE/PATH_INFO + CACHE服务器的解决方案对原有的动态发布系统进行改造,也可以大大降低旧有系统升级到新的内容管理系统的成本。并且方便了搜索引擎收录入索引。
附:如何在IIS上利用PHP支持PATH_INFO

PHP的ISAPI模式安装备忘:只试成 php-4.2.3-Win32

解包目录
========
php-4.2.3-Win32.zip c:\php

PHP.INI初始化文件
=================
复制:c:\php\php.ini-dist 到 c:\winnt\php.ini

配置文件关联
============
按照install.txt中的说明配置文件关联

运行库文件
==========
复制 c:\php\php4ts.dll 到 c:\winnt\system32\php4ts.dll

这样运行后:会发现php把PATH_INFO映射到了物理路径上
Warning: Unknown(C:\CheDong\Downloads\ariadne\www\test.php\path): failed to create stream: No such file or directory in Unknown on line 0

Warning: Unknown(): Failed opening ‘C:\CheDong\Downloads\ariadne\www\test.php\path’ for inclusion (include_path=’.;c:\php4\pear’) in Unknown on line 0

安装ariadne的PATCH
==================
停止IIS服务
net stop iisadmin
ftp://ftp.muze.nl/pub/ariadne/win/iis/php-4.2.3/php4isapi.dll
覆盖原有的c:\php\sapi\php4isapi.dll

注:
ariadne是一个基于PATH_INFO的内容发布系统,
PHP 4.3.2 RC2中CGI模式的PATH_INFO已经修正,照常安装即可。

jQuery Sizzle

没有评论

2010 年 10 月 15 日 at 下午 1:35分类:JavaScript | jQuery

jquery1.3将选择器引擎独立,定名为Sizzle,这也是jQuery第一个独立的模块。在Sizzle的介绍里,关于它的首要目的就是在”最常用的选择器使用”比之前版本的引擎更快。(什么是”最常用的选择器使用”,请参见 http://ejohn.org/blog/selectors-that-people-actually-use )
实际上,选择器引擎的运用对于页面性能起了至关重要的作用。使用合适的选择器表达式可以轻易的提高性能、增强语义并简化逻辑,而你所需要做的,不过是培养几个习惯而已。
旧习惯我 们最常用的简单选择器包括”id选择器”、”类选择器”、”标签选择器”,毫无疑问的是id选择器有着最好的速度。这取决于dom内置的函数 getElementById,其次是标签选择器,使用的是dom内置的函数getElementsByTag,最差的是类选择器,其需要通过正则解析 html,并且需要在浏览器内核外递归,这种递归遍历是无法被优化的。就需求来说,css中选择器是为了通过语义来渲染样式,而jQuery中大部分情况只是为了选出一类DOMElement,加以同一逻辑的操作。而在”最常用的选择器使用”中,类选择器以13.082%的使用率排在第二位。也就是说在13.082%的情况下,整个document的html被解析了一遍,并递归到DOM树的叶子节点。这部分无意义的性能损耗令人发指。

使用率 统计数
#id 51.290% 1431
.class 13.082% 365
tag 6.416% 179
tag.class 3.978% 111
#id tag 2.151% 60
tag#id 1.935% 54
#id:visible 1.577% 44
#id .class 1.434% 40
.class .class 1.183% 33
* 0.968% 27
#id tag.class 0.932% 26
#id:hidden 0.789% 22
tag[name=value] 0.645% 18
.class tag 0.573% 16
[name=value] 0.538% 15
tag tag 0.502% 14
#id #id 0.430% 12
#id tag tag 0.358% 10
最重要的四个建议习惯
1.以#id开始
任何情况下,请从id选择器开始,哪怕不存在这个id,也请为选择器操作添加一个id。因为这样选择器会从一个相对末端的DOMNode开始。

2.使用tag.class代替.class

关于选择器性能,jQuery官方文档有这么一段描述:

For example, “.class” is far more popular than “tag.class” even though
the second one is much more performant. What’s especially important
about this is that the degree of performance hit isn’t that much of an
issue. For example, the difference between 4ms and 30ms is virtually
imperceptible.

标签是有限的,而类则可以看作是拓展标签的语义的一种方法,那么大部分情况下,使用同一个类的标签也是相同的。

3.尽可能使用parent>child而非parent child

“>”是child选择器,只从子节点里匹配,不递归。而” “是后代选择器,递归匹配所有子节点及子节点的子节点(后代节点)。
4.缓存选出的jQuery对象
  for (i = 0 ; i < 1000 ; i ++ ) … { 
      var myList = $( ‘ .myList ‘ ); 
     myList.append( ‘ This is list item ‘ + i); 

// case 2 
var myList = $( ‘ .myList ‘ ); 

for (i = 0 ; i < 1000 ; i ++ ) … { 
     myList.append( ‘ This is list item ‘ + i); 
}

如果选出结果不发生变化的话,不妨缓存选出的jQuery对象,哪怕只有一会儿。比如下面的代码里,这种性能差异就被循环放大了,养成缓存jQuery对象的习惯可以让你在不经意间就完成主要的性能优化。其他建议习惯

1.摒除表达式中的冗余部分,类似于#id2 #id1 或者 tag#id1 的表达式中,都存在冗余部分,实际上只要#id1即可。
2.选择特定的表单元素使用[name=x
虽然name选择器写法上属于属性选择器,但是实际上普通的属性选择器使用的是递归遍历子节点来匹配,而name选择器解析优先级更高,并调用DOM内置
函 数getElementsByName。虽然在IE和Opera里,指定了name但未指定id的DOMElement也会可以使用
getElementById得到,但是在jQuery里,为了保证跨浏览器,$(“#id”)会多做一次判断,把这些不一致的结果给过滤掉。所以
name选择器成了jQuery下的唯一选择。

3.选择同一type的input元素使用[:type]

这是唯一符合需要的简单写法。

4.有条件的使用反向选择器,反向选择器是指类似于”:not(exp)”的表达式。反向选择器实际上性能并不比同逻辑的正向选择器差很多。而在一些情况
下,为了达到反向选择器的效果,
我们或许要写出很复杂的表达式,或需要添加额外的类,或需要选出结果后再筛选一遍。这都不如使用反响选择器,无论是在性能上还是在保持逻辑的简单上。而
jQuery 1.3里,反向选择器得到了增强,之前只可以接受简单的反向表达式。关于jQuery 1.3的变化,大家也可以参考( jQuery
1.3 发布

)

5.有条件的使用prev + next,在语义化的DOM里,我们常常使用结构来为两个DOMElement建立关系,以表达它们对应的实体的意义。

请参考下面的html片段

< div id =”entities” > 
< div id =”entityid” class =”entity” > 
< div class =”namelabel” > name </ div > 
< div class =”name” > entityname </ div > 
</ div > 
</ div >
当我们需要对所有.entity的.namelabel进行操作的的时候,我们可以
用$(“#entities>div.entity>div.namelabel”)来选择。这里的关系就是通过.entity
和.namelabel父子节点的结构来建立的。

不过有的时候我们无法选出一个合适的父节点来,例如<dt></dt><dd></dd>,或
是<label></label><input/>。

其实相邻节点也是我们惯用的表达关系的结构,而且这种关系用jQuery选择器效率比父子选择器更好。

prev + next用来表示1对1的关系,在1对多的情况下,可以考虑使用prev ~ siblings

结论:jQuery的选择器引擎非常强大,正因为如此,我们才更应该谨慎的并充分的使用它。

来源:http://space.cnblogs.com/group/topic/9737

在”最常用的选择器使用”比之前版本的引擎更快。(什么是”最常用的选择器使用”,请参见 http://ejohn.org/blog/selectors-that-people-actually-use
)

实际上,选择器引擎的运用对于页面性能起了至关重要的作用。使用合适的选择器表达式可以轻易的提高性能、增强语义并简化逻辑,而你所需要做的,不过是培养几个习惯而已