DNS and redirects - Website optimization [02]

Table of Contents

As I explained in the article about my website problems, analysis and measurement has shown problems with multiple landing page redirections in some situations. Here I’ll explain how I’ve solved those problems.

Table Of Contents (T.O.C.):

Introduction – what is a DNS and redirection?
Eliminating multiple redirects
2.1. Types of redirect setups
2.2. Redirect setup using php code
2.3. Redirect implementation by .htaccess file edits
…2.3.1. Website migration redirects
2.4. Redirect using Cloudflare service
2.5. HSTS setup
My results
Sources

1. Introduction – what is URL, DNS and redirection?

I’ll use an example for explanation. At the moment I’m writing this text, entering the following IP (v4) address in a browser: “172.217.10.14″ will take you to google.com. That part is not a problem – each “computer” on the Internet has some IP address (to put it simply and roughly). The problem is, when typing (like everyone does): “google.com”, how does a browser know where to “go”? This form of address, easier for humans to understand and memorize, is called URL (Uniform Resource Locator).

This is where DNS-s (Domain Name Server) come into play. When you type google.com, your computer asks the nearest DNS “do you know where this is?” For websites that have been on line for long, and often used, DNS-s usually have addresses stored. If not, DNS will ask it’s neighbour DNS-s: “do you know where I should send people asking for google.com?” This can go on for several “hops” until the address is resolved. Afterwards, the address stays written in DNS-s “address book”, so it doesn’t have to bother neighbours any more (roughly and simply put).

This solves the problem pretty well in practice. It’s not simpler to implement than it sounds here, quite the contrary, but it works!

When is there a problem? With the google.com example, several things need to be noted:

Google’s web address is not google.com, but www.google.com
Google uses SSL encryption and https protocol, so it’s actual address is: https://www.google.com.

What happens in that case when we type “google.com” and the computer asks the DNS for direction? Redirection! That looks something like this:

Computer: Do you know where google.com is?
DNS: Certainly, go to 172.217.10.14.
Computer: Knock, knock, 172.217.10.14. I’m looking for google.com.
Google-host: Sure, try at http://google.com.
Computer: Knocking on the second door, is google.com here?
Google-host: Got some extra SSL security, try https://google.com.
Computer: Is this FUN to you?!
Google host: It’s a job…
Computer: OK, WHERE IS https://google.com?!
Google host: https://www.google.com, why didn’t you say right away?

OK, unlike administrators, computers and servers can’t be provoked… can they? 🙂 But these numerous redirections do take a lot of time. Is there a way to tell the server to stop “fooling” the visitors and give them the correct address regardless of the way they form the request (google.com, www.google.com, or https://www.google.com)? The answer is YES. Explained in the next chapter.

Another “catch” is that websites using shared hosting (sharing server with other websites), without their unique IP address, can not be accessed by typing an IP address, they must be accessed using an URL, so that host server knows which of the hosted websites to “show” to the visitor.

Explanation of DNS and its setup.

– T.O.C. –

2. Eliminating multiple redirects

NOTE: use only one redirect method (as explained below – php, .htaccess, or Cloudflare), having more rules doing the same thing can cause problems (“too many redirects” error).

For dealing with multiple redirects, there are several different ways. Each has their own upsides and downsides. I’ve read numerous expert (and “expert”) articles explaining how each is implemented and which one is “the best”. From my previous experience I am convinced there is no “best” solution, only “optimal” solution (“optimal” = “the best”, or “the least bad” for given use, available resources, and user priorities). In the “Sources” chapter, at the end of this article, I’ve listed links explaining various implementations. Here, I’ll only give a short overview, followed by a more detailed explanation of the implementation that I’ve used, and that gave good results for my website.

With a well optimized website and hosting server, redirects don’t waste too much time, but that time is needlessly wasted and “excessive” redirects can be eliminated – they don’t do any good.

Test whether a website uses multiple redirects can be quickly done using GTmetrix tool.

Multiple redirections warning and low score with GTmetrix test. Picture 1 — Multiple redirections warning and low score with GTmetrix test.
Picture 1

– T.O.C. –

2.1. Types of redirect setups

There are two basic types of redirect setups: temporary and “permanent“.

Temporary redirect, implemented using “302” code (explained later) tells a web-browser: use this redirection this time.
Permanent redirect, set using “301” code” tells a web browser: use this redirect from now on.

This is an important difference. Permanent redirection remains applied until browser’s cache is cleared (deleted), that is as long as the browser “remembers” the 301 redirect it got when visiting the site. Temporary redirect is what it’s name says – browser will use the redirect, but not keep it for future use, so will read (changed?) redirect data next time it tries to visit the web-site.

When implementing and testing redirect, it is best to use temporary redirect to test and see if it works, and once it’s all set up change the redirect to 301 code and set it “permanently” (until visitor browser cache deletion, which can be over a year). It is important to set permanent redirections in the end, since they are memorised by web-browsers and only they eliminate multiple redirections.

A special case is using HSTS (HTTP Strict Transport Security), if SSL/TLS encryption is used. Use CAUTION – explained in chapter 2.5.

– T.O.C. –

2.2. Redirect setup using php code

Php code is added to every website page with the definition of the desired redirect. Example of redirection to https protocol, using a php function called “redirect_http_to_https”:

< ?php function redirect_http_to_https() { if($_SERVER[‘HTTPS’]!=”on”) { $redirect_url= “https://”.$_SERVER[‘HTTP_HOST’].$_SERVER[‘REQUEST_URI’];header(“Location:$redirect_url”); } } ?>

The function checks if https is not used ( if($_SERVER[‘HTTPS’]!=”on”) ) and if it’s not, it uses redirect defined by variable “redirect_url”.

The downside of this approach is that it’s executed at each page, for each page. This is also it’s biggest upside – if many different redirects need to be made, depending on the page visited, redirects code is executed only when needed (when the page is visited).

– T.O.C. –

2.3. Redirect implementation by .htaccess file edits

.htaccess file is located in the website root directory. It is usually set to be “invisible”, so make sure you set the ftp program to show invisible files as well. It contains instructions for Apache server configuration.

a) An example of a http to https redirection, with addition of www. if it is not entered:

# GREMLIN CHANGES BEGIN
RewriteEngine on
RewriteCond %{HTTPS} !on [OR]
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule (.*) https://www.example.com%{REQUEST_URI} [L,R=301]
# GREMLIN CHANGES END

This code redirects:

http://example.com
http://www.example.com
https://example.com

to: https://www.example.com

Change “example.com” to your domain, of course.

b) Removing www with https redirection:

# GREMLIN CHANGES BEGIN
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www. [NC]
RewriteRule ^ https://sub.example.com%{REQUEST_URI} [L,NE,R=302]
# GREMLIN CHANGES END

This code redirects:

http://example.com
http://www.example.com
https://www.example.com

to: https://sub.example.com
“sub.” can be removed from the code for redirection to the “naked” domain.

It also works for subdomains. So http://www.sub.example.com will be redirected to https://sub.example.com
But mind the SSL/TLS certificates. Most free (like LetsEncrypt) will only cover *.example.com, but not *.*.example.com, so redirection to https://www.sub.example.com won’t work. So it has to be either: sub.example.com, or www.example.com for https to work.

NOTE: example a) uses permanent redirection (301), while b) uses temporary (302). Temporary (302) is better used until all the testing is done and it is certain it all works correctly.

c) Redirect to https, without any www alteration:

# GREMLIN CHANGES BEGIN
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
# GREMLIN CHANGES END

d) Redirecting particular posts:

If changing path structure (with, or without changing a domain), it might be necessary to create redirects for particular links. Here’s an example how it’s done for two separate WordPress posts being redirected – with a new domain and different path:

Redirect 301 /8365/transfer-domena/ https://io.bikegremlin.com/8365/transfer-domena/
Redirect 301 /8433/hosting-cake/ https://io.bikegremlin.com/8433/hosting-cake/

– T.O.C. –

2.3.1. Website migration redirects

If you are moving your website to a new domain, add this code to the .htaccess file of your old domain:

RewriteEngine On
RewriteRule ^(.*)$ https://www.yournewdomain.com/$1 [L,R=302]

Test, confirm that your pages are properly redirected. Then, replace the “302” redirect (temporary redirect) in the code above with the permanent “301” redirect (temporary vs permanent redirects).

– T.O.C. –

2.4. Redirect using Cloudflare service

Cloudflare service has its advantages and disadvantages (about that perhaps some other time), but among other things, it enables the users to set up redirections on their servers (through which the website host is visited). How to set up redirects using Cloudflare?

Firstly, A and CNAME records need to be put into Cloudflare DNS list:

Setting up of bike.bikegremlin.com, as a subdomain of bikegremlin.com, pointing to the same IP address (address is chosen as an example here, it’s not the “real” one).
Picture 2

After this, DNS list on the page will have a new line:

New row in the DNS table. Where do you point when asked about bike.bikegremlin.com.
Picture 3

Next are the fields for “understanding” www addresses – if they are typed in a browser. That is done using CNAME parameter, for alias definitions. We’ll “explain” to the DNS that www.bikegremlin.com is the same as bikegremlin.com and that www.bike.bikegremlin.com is the same as bike.bikegremlin.com, making the following entries:

CNAME record for domain
Picture 4a

Sub-domain CNAME entry. Picture 4b

This will give the following fields in the DNS table:

New CNAME fields in the DNS table. Picture 5 — New CNAME fields in the DNS table.
Picture 5

Next step is redirection setup, done in the “Page Rules” section. When defining the page rules, it is important to have two things in mind:

Several rules can be set up.
Rules are executed in order, from the one on the top, to the last one – respecting the order by which they were sorted (set up).
Only one rule is executed per address request.

The last point means the first rule that matches a query is run and no other after that is even checked. It will be clearer after the examples:

Subdomain Page Rule. Picture 6 — Subdomain Page Rule.
Picture 6

Page rule for sub-domain.

Asterisk ( * ) replaces any text of any length.
Dollar sign and number insert the text “covered” by the asterisk sign, in order of asterisk signs 1st ($1) for the first *, 2nd (2$) for the second * and so on.

This rule redirects all of the following to a naked subdomain of bikegremlin.com. Such as:

www.bike.bikegremlin.com -> https://bike.bikegremlin.com
www.test.bikegremlin.com -> https://test.bikegremlin.com
www.bikegremlin.com does not fit the rule “key”, because it has only one dot after www, no other text.
bike.bikegremlin.com does not fit the key either (no www), so the rule will not be executed.

This rule “catches” all the sub-domains of bikegremlin.com, entered using www (and they shouldn’t, they are “naked”, without www). Next rule deals with the main domain www.bikegremlin.com if it is used without the www:

Page rule list. Picture 7 — Page rule list.
Picture 7

The second rule redirects bikegremlin.com to https://www.bikegremlin.com. First rule will not “catch” this because there is no www.

These first two rules deal with “incorrectly” entered URL-s. A good additional rule, put below (after) the previous two woul be permanent redirect of all the URL-s to https. That would deal with all the correctly used URL-s, since they don’t match the key of the above placed rules. Example:

*bikegremlin.com/*
Always use HTTPS (option in the page rule menu, chosen instead of redirect)

Placing this rule on top would (wrongly) redirect bikegremlin.com to https://bikegremlin.com, in stead of https://www.bikegremlin.com!

– T.O.C. –

2.5. HSTS setup

Setting up a website with HSTS is a way to tell browsers to go directly to https, eliminating one redirect.

Still, caution – once fully implemented, the change is permanent (browsers usually remember the setting for about one year). So it should be tested if https works before implementation and even then, HSTS should be set up only if it is planned to use SSL permanently from then on.

This can be done manually, configuring server and defining a shorter validity period, more appropriate for testing – once it’s fully implemented, you’re set for a year, or two, whether you like it or not. Further explaining HSTS is beyond the scope of this article. It suffices to say that it is used for websites with a high risk of hacking and/or traffic interception (on-line sales, or sites “interesting” to hackers etc). HSTS should be implemented by professionals, along with other web-site security measures. For “ordinary” web-sites, it can create some headache (and need for professional help).

More details about HSTS are given in the post about WordPress website security.

Note: redirection rules explained in this article would need some alterations if going for HSTS. That is, for technical/security reasons, HSTS doesn’t “like” “direct” redirections. Best explained using picture 8.

HSTS compliant redirections. Picture 8 — HSTS compliant redirections.
Picture 8

– T.O.C. –

3. My results

I have decided to implement redirects using .htaccess rules. Quick GTmetrix test shows everything is fine now – picture 9.

GTmetrix says no redirection problems. Picture 9 — GTmetrix says no redirection problems.
Picture 9

Average redirect times in a two week period before and after redirect setup are shown in picture 10.

Average redirection time statistics from Google Analytics. Picture 10 — Average redirection time statistics from Google Analytics.
Picture 10

These times are relatively short compared to full page load times that take several seconds. Still, it’s better not to waste time and load the server with extra redirections if they are needless and can be eliminated.

The following articles explain things that have more effect on website speed and loading time, starting with caching.

– Relja Switchman Novović

– T.O.C. –

4. Sources

– T.O.C. –