Redirects slow down your page load speed. When a browser requests wa resource that has been redirected, the server usually returns an HTTP response like this:
HTTP/1.1 301 Moved Permanently <Location: /path/to/new/location
The browser must then make another HTTP request at the new location to retrieve the resource. This additional trip across the network can delay the loading of the resource by hundreds of milliseconds.
The best case scenario with redirection is that it triggers an extra HTTP request-response cycle, which slows down page rendering. The worst outcome would be that the redirection could bring about multiple round trip request-response cycles, including DNS lookup, TCP handshake, and TLS negotiation, which would add on seconds to your page loading time.
A page fails this audit when it has two or more redirects. If failed, it’ll display this Performance Opportunity section.
The reasons that your page may have redirects varies, but there are a couple common causes:
It depends on the cause of your redirects.
The first thing you need to do is identify the redirect. Then you need to figure out why it’s being called. Then you need to figure out how to fix it.
Identifying your redirect is pretty easy. We like using Pingdom Tools, a page load test service, but you can use Chrome Dev Tools as well. With Pingdom, just enter the site and run the test. Scroll to the “Response Codes” section -- anything labeled with a 301 or 302 is a redirect. You’ll probably want to focus your efforts on the 301 redirects (which are permanent) as 302 is a temporary redirect.
Now we need to identify what the redirect is doing and why it’s being called. If you scroll down, you’ll find a section called “File requests”. If you sort by Status Code, then deselect “Rising”, you’ll see all of your 301 and 302 redirects.
In this example, NYTimes is calling a script from Google that redirects. The resulting request-response cycle adds a total of 114ms to the loading time.
Malicious redirects should be remedied by hiring a remediation service like WordFence, then securing your website with a security plugin. We really like both Securi and WordFence, and in most cases, the free versions of their plugins work well.
If you’re having redirects due to multiple versions of your domain, like “www., http:// and https://”, this can be fixed pretty easily. Make your A record the naked domain pointing to your server IP address. Make the www subdomain a CNAME alias of the naked domain. This way all your traffic is directed to your naked domain, regardless of how they type in your site URL. There are no redirects and your site loads faster.
Here’s an example (we use Cloudflare to manage our DNS):
isotropic.co points to our server IP address.
www.isotropic.co is an alias of isotropic.co and has its traffic proxied through Cloudflare.
Then go and change the WordPress Address and Site Address in WP Admin Dashboard from www to naked domain and make sure there is no 301 redirect in your .htaccess.
It's especially important to avoid redirects in resources required for your Critical Rendering Path. That’s because redirects add loading time which impacts your critical chain (discussed in the section above this one).
If you’re redirecting to a mobile version of your site, you should consider redoing your site to be mobile responsive, meaning there’s one version of your site that adapts its design (through conditional CSS classes) to match the screen size, instead of multiple versions of the site. Not only does this help fix your redirects issue, but it also boosts SEO and user experience.