I understand the article walks through the technical aspects. However, having seen a lot of non-savvy users use Internet, I am firmly with WWW. Probably because of association and all major "established" companies using www, people associate it with strength. I have learned it to be important in similar ways that a .com extension is.<p>If the site did not have www, most people assumed it is probably made by kids, who do not have www yet. See, most people do not understand that www is not a domain like .com which you have to buy. So for average joe consumer, it signals strength. For an enterprise customer, it probably does too. So unless your product is for savvy users or zen-like designers, I'd stick with www.<p>A lot of people think that naked domain is cleaner. It is actually not, since the average mind is conditioned to read www.x.com, and you have <a href="https://x.com" rel="nofollow">https://x.com</a>. It's cleaner in the sense that a face is cleaner without a nose.
After having tried both I'm very much in the WWW camp. Even though the naked domain looks nicer, it's just not worth the hassle.<p>> End users save an extra DNS lookup<p>Most intermediate resolvers will return both the CNAME and A record in one response anyways.<p>Another issue with naked domains is that all the cookies are automatically served on subdomains as well. It's just another hassle to worry about when trying to keep the cdn clean or wondering why a session works only in specific cases.
Reasons to use www:<p>* Cookies for the root domain get sent to all subdomains, so a subdomain for static content still gets flooded with cookies, slowing down requests. Now subdomains will get cookies you may not want them getting, complicating site design. You can end up sending dozens of kilobytes of cookies with each request due to the www-less cookies. The way around this is buying whole new domain names just for static content, and then duplicating SSL and all the other requirements for this new domain. Or hoping RFC 2965/6265 won't break anything using your site.<p>* There is a security boost by the same-origin not allowing a subdomain to hijack cookies for the root domain ("forums.foobar.com" could be made to set a cookie that "foobar.com" interprets, which can be used to hijack user sessions; this would not happen on www). This problem affected Github and they had to implement complicated workarounds.<p>* It is easier and more flexible to configure a round robin of frontend hosts with a CNAME (on www) than by A records on the root domain. If your cloud hosting provider's IP changes, they can change their hostname records without needing to modify <i>your</i> DNS records - less work for you and them. And if you think a single static anycast address could never have a routing problem, think again.<p>* Google will (or did in the past) ding you for duplicate content. The same content on foobar.com/ and www.foobar.com/ will appear as duplicate. Providing the content only on www separates it from other content and makes it easier to search subdomain-specific content. (This won't happen if one of them is 301 redirected to the other, however)<p>Reasons not to use www:<p>* "It looks cleaner."<p>People, you can 301 redirect your www-less site to www, gain all the advantages of using www, and the only "hassle" will be in how the address bar looks.
> <i>If you want to be able to receive email on your domain, you’ll need to set MX records at the apex domain. With a CNAME, no other records can be set.</i><p>> <i>Want to validate your domain for webmaster tools? Or for the DNS validation required for some domain validated SSL certificates? Now you have to add a TXT record to the apex domain. If you already have a CNAME, again, that’s not allowed.</i><p>It’s actually worse than that. <i>All</i> domains have, for technical DNS reasons, both a SOA record and at least one NS record in them at the “apex” domain. This would conflict with an apex CNAME record. Therefore, you can’t have a CNAME on an apex domain, even if it would otherwise be empty.<p>(There is a technical, and very theoretical, way around this limitation: The administrators of the top-level .com domain could, for example, add a CNAME record <i>directly into the top-level domain zone</i>. This would be valid, technically, but good luck convincing the various parties involved to do this.)
Don't make the mistake I made: host different content on www.gitlab.com (static site) than GitLab.com (application). People expect them to be the same. Ended up moving the static site to about.GitLab.com
The main problem is, in my opinion, that CNAME is broken for the root domain but something that can hardly be fixed on such an ancient protocol without some pain.<p>What Cloudflare and DNSimple are doing is the right thing. I hope that CNAME flattening or ALIAS records become some kind of standard.
This is why I wish that as part of HTTP 2 they had allowed the use of SRV records and gotten it built into the browsers / clients etc.<p>SRV records are far superior - its a priority and weighted list of hosts for a protocol, which could really cut down on load balancing complexity.
I'm surprised that the article doesn't mention anycast, which is more or less the "correct" way of using a CDN on an apex domain, since for the user's purposes it's just a static IP address.<p>I find anycast to be convenient even for subdomains, since it isn't affected by things like DNS caching, (although things like edns-client-subnet apparently help with that).<p>I'm actually currently looking for a CDN for my website. I don't like www (just personal preference) so anycast is pretty important to me, but there don't seem to be a lot of providers offering anycast for decent price. The closest I've seen is Google's Cloud CDN, which out of all the CDN's I've tried (a lot), is one of the best, but for a small site like mine I tend to get more cache misses than hits (simply due to eviction).<p>Maybe I'll write up a blog post about this issue :)
It's odd to hear a CDN complaining about this limitation when it has already been solved for well over a decade by other leading CDNs.<p>Akamai can serve your apex domain from their edge servers. They do it by giving different answers for the A record to different users, based on where each user is coming from. All that's required is that you use them as your NS.
At SunSed, we use Google HTTP(S) Load Balancer which allows us to load balance our entire infrastructure via a single IP.<p>Our users don't need to worry about CNAME vs A records they can do what ever they want with the IP, since we don't need to change this IP there is no benefit for using a CNAME.<p>On top of that SSL handshake for HTTPS happens at Google front ends which reduces the load on our servers. Also we can send traffic to different sets of VMs based on the URL! How cool is that?<p>I really think that Google's HTTP Load balancer is the hidden gem of Google Cloud.
This could be solved by a new record, of course, but how many years exactly would that take? So many companies would have to jump on board.<p>Thinking a record like `DELEGATE <comma delimited list of record types> <priority> <name server>` or _something_.
Adding www Doesn't make any sense for URL shorteners for example.
The same occurs on media like Twitter where chars are counted and "precious": using www. adds 4 chars to the message (in theory, since those url shorteners are in help).<p>Another detail I've noticed since wide adoption of browsers that include a single combined url/search entry field. Most people don't even care about the exact URL, they just enter the name they believe the website is, and let the search engine do the job if mistyped or inexistant. (That leads to phishing attacks).
this is slightly off topic, but is there anyone who can elaborate a little bit on why/where/how netlify differs from heroku? it's a little more expensive and you cant host your back end, so im a little confused of the value provided.
It very much depends on the age of your target market. I'd say there's a cutoff around age 30 where people simply omit the www. when talking about addresses and assume everything is just whatever.com.
A few months ago, we built <a href="https://www.forcewww.com/" rel="nofollow">https://www.forcewww.com/</a> to make our lives, and that of our customers, and everyone else, easier.