0

I have a user on what we will call PageA.aspx. This user needs to get to PageB.aspx. The obvious way is have a hyperlink that simply sends them to PageB.aspx. That got me thinking about the other ways to get between pages. One could use javascript to do a client side jump. There is also the seemingly bulky server side redirection.

What, if any, are the performance hits between these different methods?

I am going to assume the server side is a bit more heavy weight but by how much?

Do these methods scale differently?

Are there any hidden issues with doing it one way versus another?

TylerH
  • 20,799
  • 66
  • 75
  • 101
Craig
  • 11,614
  • 13
  • 44
  • 62

3 Answers3

3

A real link is best for most circumstances. All user agents know what a link is and what it represents. It's best for SEO, accessibility and usability.

A server-side (via postback) redirect is good if you need to, say, need to track specifics about which link was clicked... But it's an additional request to the server (and time to the user). It also botches SEO (et al) so it's only a viable option inside a proper "web app" where spidering or accessibility are controlled or disregarded.

JS can give you the power of tracking but it's useless (on its own) in environments where JS is disabled. Sending activity back to the server adds load so that's something to consider.

If you need it, consider using standard links and using jquery to hook the click events to track things. But really... Only if you need it as it will slow the user experience slightly.

In short: unless you've good reason not to, stick with the standards.

Oli
  • 235,628
  • 64
  • 220
  • 299
1

I think the important question is WHY did the user go from PageA to PageB? What do they do to cause this to happen?

Was it because they requested some different resource (a "get"), did they submit data to your server (i.e was it part of a "post"), does the user know that PageA is different to PageB (are they conceptually the same resource, but different views of it) or something else?

Other considerations such as whether PageB is accessible without PageA (can it be bookmarked, does it have it's own URL, should it be seen as a different URL in the browser?) will guide you.

It's hard to give you a "Best" solution without understanding this stuff.

As for using Server.Transfer or Response.Redirect, the difference of these two approaches has been covered here:

Server.Transfer Vs. Response.Redirect Response.Redirect and Server.Transfer When would I use Server.Transfer over PostBackURL?

Oh, and neither of these are appropriate for an ASP.NET MVC app where you should, instead, be routing to an Action on a Controller instead.

http://weblogs.asp.net/mikebosch/archive/2008/02/02/asp-net-mvc-tip-2-redirecting-to-another-action-and-passing-information-to-it.aspx Redirect to action in other controller

Community
  • 1
  • 1
Martin Peck
  • 11,440
  • 2
  • 42
  • 69
0

My general approach is that any page that displays data should be a get. Posts should accept data, but not return it, IMHO.

Therefore I (almost) always do a redirect after a post. It's a minor cost that prevents user error.

For one thing, it prevents multiple posts of the same data -- if the user reloads for whatever reason (or hits the back button), I don't want the data re-submitted.

The search engine issue is an important one, too. If PageB is a page you want indexed, it won't be found via javascript or a post.

Matt Sherman
  • 8,298
  • 4
  • 37
  • 57