« High Performance Web Sites: Rule 10 – Minify JavaScript | Main | High Performance Web Sites: Rule 12 – Remove Duplicate Scripts »
July 23, 2007
Redirects are accomplished using the 301 and 302 status codes. Here’s an example of the HTTP headers in a 301 response.
HTTP/1.1 301 Moved Permanently
Location: http://example.com/newuri
Content-Type: text/html
The browser automatically takes the user to the URL specified in the Location field. All the information necessary for a redirect is in the headers. The body of the response is typically empty. Despite their names, neither a 301 nor a 302 response is cached in practice unless additional headers, such as Expires or Cache-Control, indicate it should be. The meta refresh tag and JavaScript are other ways to direct users to a different URL, but if you must do a redirect, the preferred technique is to use the standard 3xx HTTP status codes, primarily to ensure the back button works correctly.
The main thing to remember is that redirects slow down the user experience. Inserting a redirect between the user and the HTML document delays everything in the page since nothing in the page can be rendered and no components can start being downloaded until the HTML document has arrived.
One of the most wasteful redirects happens frequently and web developers are generally not aware of it. It occurs when a trailing slash (/) is missing from a URL that should otherwise have one. For example, going to http://astrology.yahoo.com/astrology results in a 301 response containing a redirect to http://astrology.yahoo.com/astrology/ (notice the added trailing slash). This is fixed in Apache by using Alias or mod_rewrite, or the DirectorySlash directive if you're using Apache handlers.
Connecting an old web site to a new one is another common use for redirects. Others include connecting different parts of a website and directing the user based on certain conditions (type of browser, type of user account, etc.). Using a redirect to connect two web sites is simple and requires little additional coding. Although using redirects in these situations reduces the complexity for developers, it degrades the user experience. Alternatives for this use of redirects include using Alias and mod_rewrite if the two code paths are hosted on the same server. If a domain name change is the cause of using redirects, an alternative is to create a CNAME (a DNS record that creates an alias pointing from one domain name to another) in combination with Alias or mod_rewrite.
Steve Souders
[Steve Souders is Yahoo!'s Chief Performance Yahoo!. This is one in a series of Best Practices for Speeding Up Your Web Site. This article is based on Steve's book High Performance Web Sites, published by O'Reilly.]
Posted at July 23, 2007 3:10 PM
There are many reasons to canonicalize a URL using redirects, among them being that spiders indexing your site may see content duplicates and either have that crowd out other unique content or think you are a spammer. Also, if spiders are indexing your site for context sensitive ads, you will get better indexing and better *revenue* if you use the exact same URL.
Posted by: Steven Roussey at July 25, 2007 4:33 PM
is it free
Posted by: bethany at July 27, 2007 7:54 AM
Another reason to use redirects: When a user POSTs a form, processing should almost always result in no output being produced except for a redirect to somewhere else. Neglecting to redirect-after-POST will result in the browser's back-button going back to the POSTed page (and double-posting the form), which is usually not what the user wants or expects. This is a case where redirects are actually the *best* solution for the user experience!
Posted by: Tom Barta at September 10, 2007 7:23 PM
I totally agree with Steven - from many points of view (except speed) it's desirable to have *one* URL for each page and redirect alternative names to this URL.
Posted by: Jan at September 13, 2007 12:02 AM
I have been unable to find any instructions anywhere on the net to add Cache-Control or Expires headers to 301s in Apache.
Anyone have any idea how to do that?
Posted by: Blake at October 26, 2007 2:24 PM
Tom, I disagree completely.
It's better NOT to use redirects after form POSTS: Faster response times and, IMO, better URLs.
I also get perfect back button + browser history behavior. I use a token system to avoid double-submit issues.
Posted by: Giesen at October 30, 2007 9:34 AM
"One of the most wasteful redirects ... occurs when a trailing slash (/) is missing from a URL that should otherwise have one. This is fixed in Apache by using Alias or mod_rewrite"
Is that definitely right? I understand mod_rewrite as working by sending a 301 which rewrites the URL in the browser request window and reissues the request.
Posted by: teddly at November 4, 2007 4:42 AM
You can use mod_rewrite to call a different code path without sending a 301.
Posted by: Steve Souders at November 4, 2007 6:25 PM
It seems to me that the redirect after post pattern is a good best practice. I agree with Tom. I have been wondering why I don't see it used more often. In my experience many web sites have an issue with the back button or refresh where I get the "this page contains POSTDATA..." message. From a user perspective this is simply bad manners.
I think that the number of POSTS is small compared with the number of other GETS so the extra redirect in this case is worth the extra round trip.
What do others think? Any insight as to why this pattern isn't used more? Perhaps Giesen can give more details on how to avoid the browser POSTDATA warning without using redirects. Also to keep the URL in sync with the page content the respons to the POST would have to contain the same resource but this is not always what you want.
Posted by: John Snyders at November 6, 2007 1:11 PM
Totally Agree with Tom Barta and John Snyders.
What I do whenever I POST something is process the data, save some information (e.g. status messages about the operation) on the session and then redirect to the same URL (as in my projects usually the same page shows information or process information if there is POST).
The developers I've met through my life didn't use this because they don't care, or it is incompatible with their way of working: usually they start outputting things until they arrive at some point where "hei! we've got some POST data here! Let's process it now!". bad, bad, bad...
Posted by: Carlos Campderrós at November 21, 2007 7:36 AM
Astroloji, günlük burçlar, burç uyumları, yükselen burçlar, aşk ölçer, haftalık burçlar, aylık burçlar, aşk falı testi, burç uyumu.
Posted by: burclar at December 31, 2007 1:55 PM
Quick question, do absolute paths have better response time then relative paths? BTW, LOVED THE BOOK!
Posted by: Dathan at January 30, 2008 12:18 PM
What do you think of the following strategy?
Every dynamic resource may have asociated several URLs with different caching policy each, like this:
http://www.example.com/resource (with some relatively short expiration, like 1 minute) which redirects temporarily (301) to a second URL like:
http://www.example.com/resource/[version] (for example: http://www.example.com/resource/555, with some relatively long expiration, like 1 year)
I think this may produce faster response times and low proccesing load because of caching, while conserving always-fresh content. However, two requests are involved. What do you think?
Posted by: Ignacio at February 20, 2008 9:33 PM
Comment Policy: We encourage comments and look forward to hearing from you. Please note that Yahoo! may, in our sole discretion, remove comments if they are off topic, inappropriate, or otherwise violate our Terms of Service.
Copyright © 2008 Yahoo! Inc. All rights reserved.
Privacy Policy - Terms of Service - Copyright Policy - Job Openings