艾伟_转载:谈*静态页*(或网页*静态化*)

  “静态页”,在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分发的也只是“请求内容”而不会关心“内容的生成方式”。

  此外,有朋友给出了一份应该说“比较权威”的说明,各位不妨参考一下:动态网址与静态网址

 

时间: 2024-09-11 23:24:11

艾伟_转载:谈*静态页*(或网页*静态化*)的相关文章

利用 cache 做对比静态页的网页技术_应用技巧

一直想写一套生成静态页面的文章系统 但面对生成静态后的一些复杂数据库交互问题.又望而却步! 于是就想 有没有 在不耽误数据交互的情况下,而又能降低服务器负担的方法呢! 一个网站,访问量最大的莫过于 首页 和主栏目页了. 其他的页面 我可以不去想, 首页和主栏目页 在大流量下服务器改如何承担呢. 根据我编程2年多来的总结经验我想去了一下方法! 不生成静态页 并且降低服务器负担! 复制代码 代码如下: <%@LANGUAGE="VBSCRIPT" CODEPAGE="650

利用 cache 做对比静态页的网页技术

一直想写一套生成静态页面的文章系统 但面对生成静态后的一些复杂数据库交互问题.又望而却步! 于是就想 有没有 在不耽误数据交互的情况下,而又能降低服务器负担的方法呢! 一个网站,访问量最大的莫过于 首页 和主栏目页了. 其他的页面 我可以不去想, 首页和主栏目页 在大流量下服务器改如何承担呢. 根据我编程2年多来的总结经验我想去了一下方法! 不生成静态页 并且降低服务器负担! 复制代码 代码如下: <%@LANGUAGE="VBSCRIPT" CODEPAGE="650

艾伟_转载:静态构造函数趣谈!

类的静态构造函数也叫类型构造器,静态构造器,他调用的时刻由CLR来控制: CLR会选择如下时间之一来调用静态构造函数:      1,在类型的第一个实例创建之前,或类型的非继承字段或成员第一次访问之前.这里的"之前",代表前后衔接的意思.这里的时刻是精确的!      2,在非继承的静态字段或成员第一次访问之前的某个时刻,具体时刻不定! 由于调用的时刻不确定,所以我们最好不要编写依赖于特定的静态构造函数的执行顺序的代码,这样很容易产生不可预料的后果! 下面大家看三个Demo,我们来更加

艾伟_转载:[原创]再谈IIS与ASP.NET管道

在2007年9月份,我曾经写了三篇详细介绍IIS架构和ASP.NET运行时管道的文章,深入介绍了IIS 5.x与IIS 6.0HTTP请求的监听与分发机制,以及ASP.NET运行时管道对HTTP请求的处理流程: [原创]ASP.NET Process Model之一:IIS 和 ASP.NET ISAPI[原创]ASP.NET Process Model之二:ASP.NET Http Runtime Pipeline - Part I[原创]ASP.NET Process Model之二:ASP

艾伟_转载:从ASP.NET的PHP执行速度比较谈起

上星期我在InfoQ发表了一篇新闻,对Joe Stagner在博客上发表的三篇关于ASP.NET与PHP性能对比的文章进行了总结.写新闻其实挺不爽的,因为不能夹杂个人的看法,只能平铺直叙陈述事实.当然,如果像某些新闻那样"换一种说法"是可以骗过一些"不明真相的群众",但是这就有违道德了.因此,在客观陈述完新闻内容之后,我只能选择把自己的感想.评论等内容放在自己的博客上. Joe Stagner的背景挺特殊,它是PHP的老用户,在ASP.NET出现之前就是PHP的重量

艾伟_转载:老赵谈IL(3):IL可以看到的东西,其实大都也可以用C#来发现

在上一篇文章中,我们通过一些示例谈论了IL与CLR中的一些特性.IL与C#等高级语言的作用类似,主要用于表示程序的逻辑.由于它同样了解太多CLR中的高级特性,因此它在大部分情况下依旧无法展现出比那些高级语言更多的CLR细节.因此,如果您想要通过学习IL来了解CLR,那么这个过程很可能会"事倍功半".因此,从这个角度来说,老赵并不倾向于学习IL.不过严格说来,即使IL无法看出CLR的细节,也不足以说明"IL无用"--这里说"无用"自然有些夸张.但是

艾伟_转载:ASP.NET数据缓存之数据缓存浅谈

ASP.NET数据缓存的学习是如何呢?如何使用ASP.NET数据缓存呢?在讲ASP.NET数据缓存之前还要先说一下如果在页面中使用参数缓存.前面讲过一个缓存设置VaryByParam="none"为无参数,我们也可以对VaryByParam进行设置,设置的参数与随 GET 方法属性发送的查询字符串值对应,或与使用 POST 方法发送的参数对应.将该属性设置为多个参数时,对于每个指定参数组合,输出缓存都包含一个不同版本的请求文档.可能的值包括 none.星号 (*) 以及任何有效的查询字

艾伟_转载:.NET重写URL浅谈

最近小项目要求重写url找了下资料用到了MS的2个dll,微软的例子写得太不明显了.后来终于改好了. ActionlessForm.dll------用来处理回发 URLRewriter.dll----- 是微软封装好了的一个URL重写组件 添加引用---- 具体的使用说明请去看 http://msdn.microsoft.com/zh-cn/library/ms972974.aspx#XSLTsection123121120120 比我说得好得多. 具体使用方法: 首先web.config的配

艾伟_转载:C# Design Patterns (3) - Decorator

Decorator Pattern (装饰模式) 装饰模式可「动态」地给一个对象添加一些额外的职责,提供有别于「继承」的另一种选择.就扩展功能而言,Decorator Pattern 透过 Aggregation (聚合) 的特殊应用,降低了类与类之间的耦合度,会比单独使用「继承」生成子类更为灵活. 一般用「继承」来设计子类的做法,会让程序变得较僵硬,其对象的行为,是在「编译」时期就已经「静态」决定的,而且所有的子类,都会继承到相同的行为:然而,若用「装饰模式」以及 UML 的 Aggregat