Redirection occurs any time your user attempts to load a page with a given URL but is instead sent to a site that uses a slightly different address. There are many reasons why you might consider redirection:
- The original site has moved, and you want to send the user to the most current location
- You want to track clicks and log pages that refer users to your site/sites
- You want to reserve multiple domains
- You want to secure the information you are sending and receiving by switching from HTTP to HTTPs
However, there may be cases where you have unnecessary redirection on your site, including:
- Using device-specific versions of your site so a mobile user is redirected from example.com to m.example.com/home
- Hyperlinking inconsistently on your site by mixing URLs with and without the www prefix
In the best-case scenario, redirection triggers one additional HTTP request-response cycle, which delays page rendering. In the worst-case scenario, redirection may result in multiple round-trip request-response cycles including, though not limited to, DNS lookup, TCP handshake, and TLS negotiation.
Either way, redirection increases the amount of time it takes for your site to render, and you should minimize its use to optimize page performance. If, however, your site requires redirection, you should take care to implement it so that your users see as little delay as possible.
[bctt tweet=”Redirection increases the amount of time it takes for your site to render. Minimize its use to optimize page performance. #webperf #perfmatters” username=”TeamRigor”]
Impact of HTTP Redirection
As an example, we see that the preferred address to access the online edition of the New York Times is http://www.nytimes.com (we received an HTTP response code of 200 when requesting the site). Rigor’s waterfall chart shows that our request took 365 ms to complete.
However, suppose we attempt to load the same site using a slightly different URL: http://nytimes.com (leaving off the www prefix). Rigor’s waterfall chart indicates that this address has been permanently moved (given that we received an HTTP response code of 301).
Our request for the initial HTML required two steps. The first call was for the resource that we thought was located at http://nytimes.com. This step required 156 ms. We are then redirected to http://www.nytimes.com, which took 365 ms. Because of the redirection, our total HTML request, download, and render time took an additional 156 ms – for a total of 521 ms.
Rigor is an all-in-one monitoring and optimization solution that delivers actionable insights about 40+ metrics. Reach out for additional information and a free trial.
Additionally, the waterfall chart shows that all of the site’s resources further down on the list are pushed to the right, indicating that the browser handled them later than it otherwise would have.
Lastly, suppose we tried to go to http://nytimes.com from a mobile device. We see, from rows one through four, three redirections that took a total of 266 ms.
Compare this to loading http://mobile.nytimes.com directly, which took a mere 29 ms. This is 11% of the time required when the multiple redirects are executed.
Reducing the Use of Redirection
Time spent on redirect is most noticeable on mobile devices, especially since they tend to use slower networks. As such, the following changes will impact mobile users the most, even though all users will benefit, regardless of device type.
Use Responsive Layouts
One common use of redirection is to send mobile users from a site’s desktop version to one optimized for users with smaller screens. In this case, the user has to wait through at least one additional HTTP request-response cycle to receive the appropriate HTML file. This results in additional rendering time because nothing can happen until the HTML is received and parsed by the mobile browser.
To eliminate the need for redirection, consider using a flexible layout for your site built around responsive page principles that works for any device, regardless of size.
For example, the homepage of Wired appears this way to someone using a desktop or laptop:
Users on an iPhone-sized device, however, see the site as follows:
Notice that the URLs for both sites are identical, indicating that no redirection has occurred.
Identify Redirects to Access Non-HTML Resources
HTML isn’t the only thing that’s required to load your page. If your site requires external files, such as images and CSS, ensure that your HTML calls these resources directly and that there aren’t any redirects occurring to download these files.
Check Your Use of Slashes
Conventionally, URLs with a trailing slash indicate a directory, while those without indicate a file:
Even so, many sites do not distinguish between the two, even though search engines do see the sites as distinct entities, because users may find it confusing when such similar URLs to lead to different content. However, for the URLs to direct users to the same content, some type of redirection must occur. To identify which URL is redirecting to which, check to see which is returning an HTTP response code of 200 and which is return an HTTP response code of 30X.
While you generally do not want to tamper with such redirection, when configuring links on your webpage, you will want to know which site is the primary and which one causes a redirection. By linking directly to the site, you can reduce the use of redirection on your webpages.
Optimizing the Use of Redirection
When implementing site redirection, you can do so using one of two implementations:
- HTTP redirects
Using HTTP Redirection
HTTP redirection is typically used to send users to device-specific sites. This is done by setting the user-agent in the HTTP request headers. The response code for this redirection is either 301 (indicating the redirection is permanent, as when moving users from the address prefixed with “www” to the one that isn’t) or 302 (indicating the redirection is temporary), though you should generally use the latter if at all possible.
In addition to the “m dot” redirects (as mentioned above), you should identify any other uses of URL redirection on your pages. For example, one type of redirect sends users from the “www” version of the URL to the one without (that is, http://www.example.com redirects to http://example.com). This is similar to the type of redirect used if you’ve registered multiple domains and you want to direct all of your traffic to your primary URL.
In all of these instances, you should identify which URL garners the most traffic and then configure an HTTP 301-type redirect for all of the lesser-used URLs to the most-trafficked. Implementing this requires access to your server’s .htaccess file. You can find more information about modifying this file within your server’s documentation.
Notes and Caveats
- When setting up server-side redirection, be sure to keep the redirect URL consistent with the alternate URL specified in the page’s link rel=”alternate” tag or in the sitemap.
- Because HTTP redirection is handled server-side, it is typically faster than client-side redirection, especially if the browser can cache the new location of the requested file.
For an in-depth look at your site’s performance, reach out for a free trial of the Rigor monitoring and optimization platform. Rigor can help find, fix, and prevent performance concerns and deliver actionable insights to help you get fast and stay fast.