Page Speed: Minimize redirects

Page Speed recommends:

Eliminate unnecessary redirects

Here are some strategies for simply eliminating unnecessary redirects:

• Never reference URLs in your pages that are known to redirect to other URLs. Your application needs to have a way of updating URL references whenever resources change their location.
• Never require more than one redirect to get to a given resource. For instance, if C is the target page, and there are two different start points, A and B, both A and B should redirect directly to C; A should never redirect intermediately to B.
• Minimize the number of extra domains that issue redirects but don't actually serve content. Sometimes there is a temptation to redirect from multiple domains in order to reserve name space and catch incorrect user input (misspelled/mistyped URLs). However, if you train users into thinking they can reach your site from multiple URLs, you can wind up in a costly cycle of buying up new domains just to stop cybersquatters from taking over every variant of your name.

Use server rewrites for user-typed URLs.

Many web servers support internal "rewrites". These allow you to configure mappings from one URL to another; when a client requests an invalid URL, the server automatically remaps it to the correct one and serves the resource, without issuing a redirect. Be sure to use them to catch URLs you can't control. Never use them as a means of easily updating URL references in your pages; you should always refer to one resource with a single URL. Also avoid using them for cacheable resources if possible. The automatic addition of the required trailing slash at the end of directory names is an example of a user-typed URL that would make a good candidate for the rewrite mechanism.

Track web traffic in the background

To track traffic into and between their various properties, some websites use intermediate redirects to a page that does logging for all properties on a central standalone server. However, because such redirects always add latency between page transitions, it's good to avoid them and to find other ways of logging page views in the background.

One popular way of recording page views in an asynchronous fashion is to include a JavaScript snippet at the bottom of the target page (or as an onload event handler), that notifies a logging server when a user loads the page. The most common way of doing this is to construct a request to the server for a "beacon", and encode all the data of interest as parameters in the URL for the beacon resource. To keep the HTTP response very small, a transparent 1x1-pixel image is a good candidate for a beacon request. A slightly more optimal beacon would use an HTTP 204 response ("no content") which is marginally smaller than a 1x1 GIF.

Click "Read more" for an example.

Prefer HTTP over JavaScript or meta redirects

There are several ways to issue a redirect:

• Server-side: You configure your web server to issue a 300 HTTP response code (most commonly 301 ("moved permanently") or 302 ("found"/"moved temporarily")), with a Location header set to the new URL.
• Client-side: You include the http-equiv="refresh" attribute in the meta tag or set the JavaScript window.location object (with or without the replace() method) in the head of the HTML document.

If you must use a redirect mechanism, prefer the server-side method over client-side methods. Browsers are able to handle HTTP redirects more efficiently than meta and JavaScript redirects. For example, JS redirects can add parse latency in the browser, while 301 or 302 redirects can be processed immediately, before the browser parses the HTML document.

In addition, according to the HTTP/1.1 specification, 301 and 302 responses can be cached by the browser. This means that even if the resource itself is not cacheable, the browser can at least look up the correct URL in its local cache. 301 responses are cacheable by default unless otherwise specified. To make a 302 response cacheable, you need to configure your web server to add an Expires or Cache-Control max-age header (see Leverage browser caching for details). The caveat here is that many browsers don't actually honor the spec, and won't cache either 301 or 302 responses; see Browserscope for a list of conforming and non-conforming browsers.

Read More