Why does Google Search use client-side URL parameters?

Question

Yesterday morning, I noticed that Google Search uses hash parameters:

• http://www.google.com/#q=Client-side+URL+parameters

which seems to coincide with a more conventional search (with search parameters? q = Client + URL +). (It looks like they no longer use it by default when doing searches using their form.)

Why would they do this?

More generally, I see hash parameters that occur on many websites. This is a good thing? Is it a hack? Is this a departure from the principles of REST? I am wondering whether to use this technique in web applications and when.

There's a W3C discussion of different use cases , but I don’t see which one applies to the above example. They also seem to be unsure of the recommendations.

Answer 1

Google has a lot of live experimental features that turn on / off based on your preferences, location, and other factors (probably random choices.) I'm pretty sure that the one you mentioned is also one of them.

What happens in the background, when a hash is used instead of a query string parameter, it requests a "real" URL ( http://www.google.com/search?q=hello ) using JavaScript, then it modifies the existing content page. This will be much more responsive to the user, as the page should not be completely reloaded. The reason for the hash is to keep browser history and status. If you go to http://www.google.com/#q=hello , you will find that you are actually getting search results for “hi” (even if your browser is actually requesting http://www.google.com/ ) With JavaScript disabled, it will not work, and you just get the first Google page.

Hashes are increasingly appearing as dynamic websites become the norm. Hashes are fully supported by the client and therefore do not require a server request when changing. This makes them excellent candidates for maintaining unique addresses in different states of the web application, while still on the same page.

I have been using them more and more recently, and you can find one example here: http://blixt.org/js - if you have a look at the Hash library on this page, you will see my implementation of the support hashes in browsers.

---

Here's a little guide on using hashes to keep state:

How?

Maintaining state in hashes means that your application (I will call it application, since you usually use hashes for state in more advanced web solutions) relies on JavaScript. Without JavaScript, the only hash function would be to tell the browser to find content somewhere on the page.

After you have implemented some JavaScript to detect hash changes, the next step is to parse the syntax for meaningful data (just like with query string parameters).

Why?

Once you have the hash state, it can be modified by your code (or by your user) to represent the current state of your application. There are many reasons why you would like to do this.

One common case is that only a small part of the page changes based on the variable, and it would be inefficient to reload the entire page to reflect this change (for example: you have a tabbed window. Can be identified in a hash.)

Other cases are when you dynamically load content in JavaScript, and want to tell the client which content to load (Example: http://beta.multifarce.com/#?state=7001 , you will go to a certain point in the text adventure.)

When?

If you had a look at my “realm of JavaScript”, you would see a case with an excess border line. I did this simply because I wanted to insert JavaScript dynamics into this page as much as possible. In a normal project, I would be conservative when to do this, and only do this when you see positive changes in one or more of the following areas:

• User interactivity
  • Usually the user does not see much difference, but the URLs can be misleading
  • Remember download rates! Downloading content can dynamically upset the user if time is required.
• Responsiveness (time from one state to another)
• Performance (bandwidth, server processor)

No javascript?

There is a big deterrent here. Although you can safely rely on 99% of your users to have a browser capable of using your hash page for status, there are still many cases where you simply cannot rely on it. Search robots, for example. While Google is constantly working to get their crawler to work with the latest web technologies (did you know that they index Flash applications?), He is still not human and cannot understand some things.

Basically, you are at the crossroads between compatibility and user experience.

But you can always build a road between them, which, of course, requires more work. In less metaphorical terms: Deploy both solutions to have a server-side URL for each client-side URL that displays the relevant content. For compatible clients, it redirects them to the hash URL. This way Google can index hard URLs, and when users click on them, they get dynamic state!

Answer 2

Google recently also stopped serving direct links in search results, instead redirecting them.

I believe that both of them are related to the collection of usage statistics, which searches were performed by the same user, in what order, what search results were performed by the user, etc.

PS Now these interesting, direct links are back. I absolutely remember that in the last couple of weeks there have been only redirects. They are definitely experimenting with something.