PageSpeed: Avoid landing page redirects


PageSpeed (Legacy)
YSlow (Legacy)


Redirections on landing pages add delays to the page load and while the redirections are occurring, nothing is shown to the client. In many cases, redirections can be eliminated without changing the function of a page.

How does your site score on this recommendation?

What can I do?

If your service requires redirects, perform the redirection server-side rather than client side, in order to reduce client-side round trip requests. Minimizing HTTP redirects from one URL to another cuts out additional RTTs and wait time for users.

Details from Google

Round-trip time (RTT) is the time it takes for a client to send a request and the server to send a response over the network, not including the time required for data transfer. That is, it includes the back-and-forth time on the wire, but excludes the time to fully download the transferred bytes (and is therefore unrelated to bandwidth).

RTTs vary from less than one millisecond on a LAN to over one second in the worst cases, e.g. a modem connection to a service hosted on a different continent from the user. For small download file sizes, such as a search results page, RTT is the major contributing factor to latency on "fast" (broadband) connections. Therefore, an important strategy for speeding up web page performance is to minimize the number of round trips that need to be made. Since the majority of those round trips consist of HTTP requests and responses, it's especially important to minimize the number of requests that the client needs to make and to parallelize them as much as possible.

Sometimes it's necessary for your application to redirect the browser from one URL to another. There are several reasons web applications issue redirects:

  • To indicate the new location of a resource that has moved.
  • To track clicks and impressions and log referring pages.
  • To reserve multiple domains, allow for "user-friendly" or "vanity" domains and URLs, and catch misspelled/mistyped URLs.
  • To connect between different parts of a site or application, different country-code top-level domains, different protocols (HTTP to HTTPS), different security policies (e.g. unauthenticated and authenticated pages) etc.
  • To add a trailing slash to URL directory names to make their contents accessible to the browser.

Whatever the reason, redirects trigger an additional HTTP request-response cycle and add round-trip-time latency. It's important to minimize the number of redirects issued by your application - especially for resources needed for starting up your homepage. The best way to do this is to restrict your use of redirects to only those cases where it's absolutely technically necessary, and to find other solutions where it's not.

Read our Lighthouse documentation to learn more on avoiding redirects.



PageSpeed recommends:

Eliminate 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.

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.

Read More

Cookie Policy

By clicking "Allow All" you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View cookie details

Deny Allow All