谈*静态页*(或网页*静态化*)的时候,请区分一些概念
2009-07-05 01:37 Jeffrey Zhao 阅读(29969) 评论(115) 编辑 收藏 举报“静态页”,在Web应用程序开发中是很常见的概念。只是我发现目前还是有相当部分的朋友,在这方面的存在一定的误区。因此现在独立写一篇文章,也想把一些问题讲讲清楚,以后在讨论的时候也好有个准。
不久前有朋友写了一篇题为《提供生成静态页核心代码》的文章,介绍了一种“向硬盘写入页面文件”的方式。这篇文章的内容在此并不多作讨论,这里引用一下作者给出的摘要:
网页生成静态Html文件有许多好处,比如生成html网页有利于被搜索引擎收录,不仅被收录的快还收录的全。前台脱离了数据访问,减轻对数据库访问的压力,加快网页打开速度。
这种说法存在一个严重的问题,因为它混淆了两个概念:“静态页”有利于网站性能,和“静态页”有利于SEO。有朋友可能会说:“这两点说的都没有错啊,不信你去搜索引擎上查一下,都有很多资料”。是的,这两种说法都能在搜索引擎上找出“依据”来,只可惜在这种两种情况下的“静态页”所指的内容,或者说是“做法”完全不同,可以说没有任何关系。换句话说,这里造成“混淆”的原因是“指代不明”。为了方便阐述,在本文接下来的部分中将尽可能避免“静态页”,“静态化”等词语,而是使用以下两种区分明显的说法进行阐述:
- 规范页面URL
- 缓存页面内容
规范页面URL
如今在开发的Web应用程序时,往往需要从客户端获取一些信息,然后根据这些信息生成页面。例如,我们需要从客户端获取一个“页码”,然后在页面上呈现出这一页的内容。从客户端传递信息的方式有多种,其中最常见的便是通过Query String进行传递。例如,我们可以通过Article.aspx?id=3这样的方式来请求id为3的文章。不过如果纯粹使用Query String来传递信息的话,一个URL可能会带有许多项Query String。例如ArticleList.aspx?page=3&keywords=helloworld&category=6&....。
有种说法是,这样的URL由于明显是动态的,因此搜索引擎对它的处理会有所负面倾斜,例如将其权值放低。因此,很多程序都会把为URL规范为特别的形式,例如Article/3,甚至是Article_3.html。使用htm或html作为URL的结尾,是为了“欺骗”搜索引擎,让搜索引擎以为这是一个直接从存储设备上直接读取的资源,它不会改变,因此“它的权值会相对提高”。实际上老赵并不同意这个说法,而且似乎也没有实际案例可以证明这一点——当然我也无法证否,因此无法判断这个说法的正确性。不过这篇文章并不是在追究这个问题,在这里我们暂且认为它有道理吧。
要实现这点,我们所要实现的是进行URL重写。URL重写的目的,是在服务器端把客户端请求的URL(如Article_3.html)当作另一个请求进行处理(如Article.aspx?id=3)。请注意,这个工作是在服务器端完成的:
客户端 | 服务器端 |
Article_3.html | Article_3.html => Article.aspx?id=3 => 处理 => 输出 |
对于搜索引擎的爬虫来说,它根本意识不到这个URL是在直接读取资源,还是经过了动态的请求。我们是Web应用程序的编写者,对于一个请求我们可以使用我们任意的方式进行处理,想欺骗搜索引擎还不是易如反掌?不过这种做法对于网站性能来说是否有帮助?没有,肯定没有。
这种改变URL,想要获取更好SEO效果的做法,有些人也会把它叫做“伪静态化”。老赵不知道这种说法合不合适,我是从来不会使用这样的说法的。
缓存页面内容
动态生成一个页面的开销往往很大,例如需要多次查询数据库或者外部服务。为了减少服务器端的开销,为了加快网站的运行效率,有时候在服务器端会将一个页面的整体内容保存为一个文件,这样每次在服务器端获取客户端请求的时候,只要读取相应的文件即可,而不需要重新查询数据库或外部服务并重新生成页面内容:
客户端 | 服务器端 |
Article.aspx?id=3 | Article.aspx?id=3 => 读取文件 => 输出 |
同样的,这些事情完全是在服务器端进行的处理,搜索引擎的爬虫对此一无所知。即使搜索引擎认为Article.aspx?id=3这样的请求是由服务器端即时生成的(当然搜索引擎真不会考虑这些),我们编写的服务器端逻辑同样可以直接读取磁盘上的文件,并且直接输出。这种做法自然是为了效率,不过……
这种做法和SEO有没有关系?没有任何关系,因为爬虫根本不知道我们做了这些。
这种做法是否需要在硬盘上生成一个html文件?没有必要,我可以生成txt文件,可以生成jeffz文件,甚至我可以不生成文件,而是将页面内容直接存放在内存中,甚至是高性能的Key/Value Store里。
这种做法是否需要把URL修改为html结尾?没有必要,URL改不改都无所谓,改成什么也都无所谓。
总结
有时候事情其实就是那么简单,但是还是会让人混淆。一句话听上去很正确,但是一旦“指代不明”,正确的话也变成错误的了。例如本文一开始引用的文章,它是为了“缓存页面内容”而使用的做法,这个做法和SEO没有任何关系,因此说“生成html网页有利于被搜索引擎收录,不仅被收录的快还收录的全”是将其目的与“规范页面URL”混淆了起来。错误产生在这里。在那片文章后面的评论中,有朋友回复说目前的搜索引擎已经不关心URL是否是html还是别的什么形式了。这种说法可能也是正确的,不过并没有谈在点子上。因为无论搜索引擎如何处理HTML,文章的内容都和搜索引擎没有一丝一缕关系。
因此,如果您以后要谈“静态页”或网页“静态化”的时候,请区分您究竟是在谈“规范页面URL”还是“缓存页面内容”。
如果您说“静态页有助于SEO”,明白人知道您是再指“规范页面URL”,而某些朋友可能就会认为您是指在服务器端缓存页面内容。
如果您说“静态页有助于提高网站性能”,明白人知道您是指“缓存页面内容”,而某些朋友可能就会认为您是指使用“URL重写”来规范URL样式。
如果您说“静态页,既有助于SEO,又有助于提高网站性能”,那么(我希望)明白人就会带您来看现在这篇文章,而某些朋友可能就会……哎哎。
补充说明
有朋友提到静态资源适合被CDN分发,其实不然。CDN难道不能分发动态请求生成的内容了吗?对于CDN来说,动态和静态是没有区别的。不说CDN,就说Squid吧,Squid知道后面连接的请求是静态还是动态的吗?是Windows系统还是Linux吗?其实这就是“分层”,抽象出来以后完全不知道后端的递交方式。而且换个角度想,世界上有“静态请求”这个东西吗?不都是需要经过Web服务器处理的吗?只不过,一个是复杂运算,一个是直接读取硬盘文件。对访问者来说,是看不出任何区别的。CDN分发的也只是“请求内容”而不会关心“内容的生成方式”。
此外,有朋友给出了一份应该说“比较权威”的说明,各位不妨参考一下:动态网址与静态网址