To WWW or not to WWW

That is the technical question:

Whether ’tis nobler in the bare domain to suffer
The complications and slowdowns of cookies shared
Or to take simplicity against a sea of CNAMES
And with WWW end them.

Aside from what looks better (with WWW or without), are there other technical implications regarding which version you use?

Yes, but it’s not a big deal IMO…

Origin of WWW

Where did WWW come from?

It’s old networking technology. Back in the days, many computer networks were organized by domain (e.g. “domain.com”). And every computer on the network was called by its own sub-domain.

• mail server was “mail.domain.com”
• FTP server was “ftp.domain.com”
• print server was “print.domain.com”
• Johnny’s computer was “johnny.domain.com”
• main server was “server.domain.com”
• nameserver was “ns1.domain.com” and “ns2.domain.com”

Guess what the web server was called?

…yes…”www.domain.com” (the “www” stood for WORLD WIDE WEB)

Of course, we could have called it web.domain.com or site.domain.com or whatever else. But like with many things everybody used what was standard. And therefore everybody called their web server “www” because that’s what everybody else did.

What the bare domain (domain.com) was reserved for.

The naked domain “domain.com”, if I remember correctly, simply took you to a page that showed the different computers available on that network (www, mail, ftp, etc). It was used as a digital central point and didn’t redirect to any particular computer.

From a networking point of view, to use just a bare domain is technically inaccurate and ambiguous. It would be like if I gave you the incomplete address of a commercial building without giving you any unit/suite number. You wouldn’t assume any particular suite number from the address alone. And likewise, you wouldn’t assume the web server from the bare domain alone. And literally…people wouldn’t know whether an address like “domain.com” was supposed to be a website or not. (Hahaha, a lot’s changed since then. That nomenclature is virtually standard for websites now.)

How was webhosting sold?

When you bought a webhosting account, what you’re paying for is to use somebody else’s server so you don’t have to build your own network and web server from home. You simply register your domain so you have a dedicated name on the internet and then point it your webhost’s server.

The domain you registered was now “domain.com” and you were free to make as many subdomains you wanted on top of it.

• www.domain.com
• forum.domain.com
• help.domain.com
• shop.domain.com
• members.domain.com

Redirect to WWW

Of course, most people only needed “www” and that’s all that was used. The problem was that we had to create a redirect just in case someone only typed the bare domain into the address bar “domain.com” instead of the full “www.domain.com”

And for 30 years or so, the internet worked this way.

Today’s trend of without-WWW

People figured out they could go without the WWW.

I don’t know what started it. If some clever marketing agency started it. Or maybe the internet standards allowed for a change but somebody started redirecting their website domains the other way around.

• Instead of pointing “domain.com” to “www.domain.com”…
• they pointed “www.domain.com” to “domain.com”

I’m sure I don’t have to tell you how popular it’s become now. Many big companies and even small companies start going without the WWW. It’s so much cleaner, easier to remember. Displays better on unfurled/embedded links where you only see bits of the URL and not the entire thing. Even browsers now don’t show the “www” in the address bar. Whether or not “without-WWW” is officially the new standard, I can assure you that it soon will be.

SEO concerns regarding with or without WWW

There’s no concern today as far as I know. Both will rank well. If anything, many people will tell you not to switch and keep using what you have. Well, I dragged my feet for years and ultimately made the painful decision of switching one of my old (and very successful) websites over from with-WWW to without-WWW.

The end result was zero SEO impact whatsoever. If there was any pain, it’s that I had to reconfigure my social share count plugin to include my old domain share counts as well.

Most websites will tell you that there is zero issue at all and you can just use whichever domain spelling you like.

• Your Domain Name: Do You www or Not? – sitepoint

Other sites will say scary things and tell you to stick with “www”.

• www. is not deprecated – yes.www.org
• What’s the point in having “www” in a URL? – ServerFault

Technical complication #1 – CNAME records

Some people argue…(and I think more for technical “correctness” more than anything else)…that you shouldn’t use the bare domain because it can’t be a CNAME record.

• The Limitations of DNS A-Records – Heroku

And I’m sure you’re wondering why would this ever be a problem for you… [Ughhhh…I’m frustrated at how simple this concept is but so technically verbose to explain.]

It has to do with the differences (and limitations) between an A record and a CNAME record:

• A record – is an absolute record. Points to an IP.
• CNAME record – is a pointer record. Points to a domain (which then points to an IP).

Another way of saying it is that an A record is like a definite phone number “123-123-1234” and a CNAME record is like a note to “check with Johnny” who will then give you the correct phone number.

There are 2 real-world instances where having a CNAME is more convenient for fault-resolution.

1. You want a full-site CDN using your same website domain (and not CDN sub-domain).

Usually how CDN’s work is that they give you a designated CDN zone using a subdomain off their domain (wpjohnny.maxcdn.com) which you redirect to from a subdomain on your domain (cdn.wpjohnny.com). This “redirect” is created using the CNAME record which looks like this in your DNS record:

• CNAME – cdn.wpjohnny.com > wpjohnny.maxcdn.com

And that’s how most sites use CDN (using a dedicated subdomain). And if you wanted to use “www.wpjohnny.com” to point to “wpjohnny.maxcdn.com”, you can as well. But what if for whatever reason, you wanted to use your bare domain? And have full CDN benefits on it? Well…this is difficult because you can’t point the root “wpjohnny.com” domain to another domain because…

• All CDN services only give you a subdomain to point to rather than IP record.
• Which means you can only redirect your domains to those CDN servers using a CNAME record.
• And the internet standard for DNS doesn’t (standardly) allow bare domains to have a CNAME record point to other domains! (It does however allow CNAME records for subdomains.)
• ….which then means the only way you can use the CDN is if your website is on a subdomain…like “www.domain.com”.

And WHY does it have to be like this? WHY WHY WHY?! Because of instance #2.

2. You need to constantly change IP’s for your domain.

This is only an issue for really big sites. The ones that grow so fast or get hacked, or suffer big outtages, that they need to re-route traffic to other servers ASAP. In cases like this, you need to be able to change your domain IP freely without affecting traffic or dependent services.

Going back to my old CNAME vs A RECORD comparison…it’s more convenient to have your domains pointed to a CNAME (which then points to an A record, pointing to an IP) because you only have to update the end IP one A record…and without any worry about affecting services pointing to your CNAME domains. Had you used A records initially in place of CNAME records, you would have had to go around updating all your A records everywhere!

Go back to my phone number analogy:

• If you gave everyone a number 123-123-1234 and it changed to 234-234-2345, now you have to update the number in all your DNS records.
• But if you gave everyone a “check with Johnny”, nothing changes. They can still use the same CNAME record and it will ultimately point to the updated IP.

Now here’s where we get to kick the person (behind this argument) who made me have to explain all this crap. None of this crap matters for 99.99% of sites out there for 3 reasons:

1. You don’t have a giant site with any of these scaling issues. You’re also just fine with loading CDN assets from a subdomain.
2. You’re using a DNS service that makes it easy to change DNS records on-the-fly. It’s not like you have to change nameservers and re-propagate anytime you need to point to a different IP. The ease of Cloudflare has made this concern completely irrelevant IMO!
3. Some DNS services now allow “ANAME records”, which is basically the ability to redirect your bare domain to another domain. Basically, the same function as your classic CNAME record but it’s called “ANAME record”.

Regarding #3, there are even some technical implications within that…your DNS nameserver might be far from your CDN mirror servers. The easiest non-fussy way to get around this is to use an integrated DNS and CDN service. Such as Cloudflare (which takes over your DNS and routes to nearby CDN mirror POP) or Amazon with their Route 53 DNS and Cloudfront CDN. Otherwise, you better make sure you’re in a region where the DNS server and CDN servers are very close to each other.

I feel stupid now because I wrote this guide to make it easier than other explanations I’ve seen but now feel they might have explained it better:

• Root domain on CDN and performance – CDNPlanet
• Introducing CNAME Flattening: RFC-Compliant CNAMEs at a Domain’s Root – Cloudflare
• CDN’s Love ANAME Records – DNS Made Easy
• ANAME Records – DNS Made Easy

Technical complication #2 -cookies

Managing cookies between domains and subdomains can be tricky.

If you only have one website on your domain, you can just leave now. Ain’t no point in reading this guide anymore. Nothing to worry about. Just set your bare domain (domain.com) and go play outside.

For the rest of you with multiple websites (like domain.com, forum.domain.com, spanish.domain.com)…you may have some cookie problems IF you host websites on your bare domain and subdomains. This is because of the many scenarios where you may (or may not) want cookies shared between your domains and subdomains, and the ways that cookies are shared between domains/subdomains.

When cookies SHOULD be shared between between domains.

• Your site has many sub-sites and services and you don’t want users to have to keep logging in.
• domain.com, shop.domain.com, help.domain.com

A good example of this is Google. You login just once and you can access your Gmail, Google Docs, Youtube. This is because a cookie is tracking your session so you don’t have to keep establishing a new one. Another example might be a pop-up cookie so you don’t harass them with the same advertisements (newsletter) or information (GDPR).

When cookies SHOULD NOT be shared between domains.

• You have cookie info that shouldn’t be passed on between your different sites/domains. This generally the default logic!
• Main site on bare domain (domain.com), CDN site on subdomain (cdn.domain.com).
• Your different sites don’t need to be integrated. (directory.com, car.directory.com, furniture.directory.com)

Sometimes there’s no info that needs to be shared. And so it’s important not to have unnecessary cookies as this would slow down the site and waste a tiny bit of bandwidth.

The problem with setting cookies.

By internet standard, cookies are typically set by a fully qualified domain name (FQDN)….which is this structure SUBDOMAIN > DOMAIN > TOP-LEVEL DOMAIN…and should look like something.domain.com.

And had you given your main website a fully-qualified domain name, it’s really easy to configure whether or not to share cookies across all your FQDN’s.

• Suppose you had 3 FQDNS. (www.domain.com, sub1.domain.com, sub2.domain.com)
• It’s easy to share a cookie only between WWW and SUB1.
• It’s easy to make a cookie only for WWW that’s not shared with others.
• Basically…easy to share or not to share.

The problem happens when you throw a bare domain (domain.com) into the mix because…

• Sometimes cookies intended for only the bare domain are (unexpectedly) applied to all your subdomains.
• It’s supposedly difficult to apply cookies from subdomain to bare domain.
• Also supposedly difficult to apply cookies from bare domain to subdomain.
• The discrepancy is due to how different browsers behave (modern vs old). And that if you set your cookies with a proper dot in front of the domain “.domain.com” it applies to all subdomains but if you set without the dot “domain.com”, it is incorrect by RFC 2965 standards and will therefore be treated (by some browsers) as if you did put the dot.

More reading if you like to hear tech arguments going back and forth:

• Caveats and pitfalls of cookie domains – Xebia
• The definitive guide to cookie domains and why a www-prefix makes your website safer – Sasha Romijn
• Can subdomain.example.com set a cookie that can be read by example.com? – ServerFault
• Canonical bare domains and cookies – Section.io
• Share cookie between subdomain and domain – ServerFault
• Setting cookies only on the naked domain – ProWebmasters
• How do browser cookie domains work? – ServerFault (read the recent answers)

But here’s why you don’t gotta worry about any of these cookie domain stuff.

• Modern browsers allow you to set cookies specifically for bare domain.
• Most people don’t share cookies between sites anyway.

End of story. It’s a non-issue. This whole guide was a total waste of time.

My verdict – stick without the WWW

Use the bare domain!

• Looks better.
• No speed issues.
• No DNS hassles.
• No weird cookie issues between bare domain and subdomains.

Any technical inconveniences that you might have had from a bare domain are either A) no longer relevant in today’s evolving services and B) not so big that you should be scared from using a bare domain. If anything, I think bare domains will be the new standard soon and will be reflected in future internet standards and protocols.

That cookie issue is getting so old some newer developers don’t even know it was ever a thing. I’ve never had a problem with it and neither will you. The only legit remaining reason for using “www” IMO is that you like how it looks.

• Special un-thanks to jujuwiwi for taking me down this rabbit hole. 😉