为什么谷歌搜索会使用客户端URL参数?

谷歌有许多实时实验功能,可以根据你的喜好、位置和其他因素(可能也是随机选择)打开/关闭。我相信你提到的也是其中之一。

当使用散列而不是查询字符串参数时,后台会发生什么情况:它查询“real”URL( http://www.google.com/search?q=hello )使用javascript,然后用内容修改现有页面。由于页面不必完全重新加载,因此对用户的响应会更为迅速。散列的原因是为了维护浏览器的历史记录和状态。如果你去 http://www.google.com/#q=hello 你会发现你实际上得到了“你好”的搜索结果(即使你的浏览器只是在请求 http://www.google.com/ )然而,如果关闭了javascript,它就不起作用了,你只需要得到谷歌的首页。

随着动态网站逐渐成为标准,散列法越来越多地出现。哈希完全在客户机上维护,因此在更改时不会引发服务器请求。这使得它们非常适合在保持Web应用程序的不同状态下保持唯一地址,同时仍在完全相同的页面上。

最近我越来越多地使用它们,您可以在这里找到一个例子: http://blixt.org/js --如果您查看了该页面上的“hash”库,您将看到我在浏览器中支持hash的实现。

以下是使用哈希存储状态的小指南:

怎么用?

在散列中维护状态意味着您的应用程序(我将称之为应用程序,因为您通常只对高级Web解决方案中的状态使用散列)依赖于JavaScript。如果没有javascript,哈希的唯一功能就是告诉浏览器在页面上的某个地方找到内容。

一旦实现了一些JavaScript来检测对哈希的更改,下一步就是将哈希解析为有意义的数据(就像使用查询字符串参数一样)。

为什么?

在散列中获得状态后,可以通过代码(或用户)修改它来表示应用程序中的当前状态。你为什么要这样做有很多原因。

一个常见的情况是,当一个页面中只有一小部分基于变量进行更改时,重新加载整个页面以反映该更改将是低效的(例如:您有一个带有选项卡的框)。活动选项卡可以在哈希中标识。)

其他情况是,当您在javascript中动态加载内容时,您想告诉客户要加载什么内容(例如: http://beta.multifarce.com/#?state=7001 ,将带您到文本冒险中的特定点。)

什么时候?

如果你看过我的“javascript领域”,你会看到一个边界线过度杀戮的案例。我之所以这么做,仅仅是因为我想在那个页面中尽可能多地填充JavaScript动态。在一个正常的项目中,我会保守地考虑何时这样做,并且只在您看到以下一个或多个方面的积极变化时才这样做:

• 用户交互
  • 通常用户不会看到太大的差异,但URL可能会令人困惑。
  • 记得 正在加载指示器!如果需要时间,动态加载内容可能会让用户感到沮丧。
• 响应(从一种状态到另一种状态的时间)
• 性能(带宽、服务器CPU)

没有JavaScript?

这是一个巨大的威慑。虽然您可以安全地依靠99%的用户来拥有一个能够将页面与哈希一起用于状态的浏览器,但在许多情况下,您仍然不能完全依赖它。例如,搜索引擎爬虫。虽然谷歌一直在努力让他们的爬虫程序使用最新的网络技术(你知道他们索引闪存应用程序吗?)它仍然不是一个人,也不能理解某些事情。

基本上,您正处在兼容性和用户体验之间的十字路口。

但是你可以在中间筑路,这当然需要更多的工作。用较少的隐喻术语来说:实现这两个解决方案,以便为每个输出相关内容的客户端URL都提供一个服务器端URL。对于兼容的客户机,它会将它们重定向到哈希URL。这样,Google就可以索引“硬”URL,当用户点击它们时,它们就会得到动态状态的东西!

最近,谷歌也停止在搜索结果中提供直接链接,转而提供重定向服务。

我相信这两者都与收集使用统计数据、同一用户执行的搜索、按什么顺序、用户跟踪的搜索结果等有关。

另外,有趣的是,直接链接又回来了。我绝对记得在过去的几周里只看到了重定向。他们肯定在试验什么。