Hacker News Reader

Comment by feelix | Hacker News Reader

This reasoning is all based on valid, but technical issues for the hosting side. A general rule for any customer-facing business is to put the customer first. I could list 200 different reasons why you should make the customer register an account with their email address before they can purchase something for you. However, if you put the customer first, in many cases it is easier for them if they don't have to do that. Having the www before the domain name adds unnecessary visual clutter and from the customers point of view, an unnecessary redirect before they can get to your site. A lot of sites use minimalist style everywhere, and it's great. Having the www there for technical reasons is putting the user second in those cases.

View on HN

I think that www vs. no-www, as a matter of "putting the customer first" is so INCREDIBLY insignificant, compared to the thousands of other decisions that go into a product, that it's ridiculous we're even having this conversation. This is looking for optimization in the wrong places at its finest.

A redirect is also completely invisible to the user, and should only add a few microseconds to the page load. But you should always redirect www. if you are not using www. Many people instinctively type that into the address bar when you tell them a domain name.

A few microseconds, huh? I decided to do some experiments. Here's how long some 301s on common sites took:

    google.com:    529ms
    apple.com:     261ms
    microsoft.com: 142ms
    reddit.com:     61ms

Which is not only 100,000 times longer than a few microseconds but more importantly well above the perception threshold.

touche.

Where in the world are you that google.com's 301 takes over half a second ? It's under 100ms for me.

I don't get the parent's numbers either. I did:

    $ time (curl -L www.reddit.com > /dev/null 2>&1)
    real	0m0.410s
    user	0m0.040s
    sys	0m0.008s

    $ time (curl -L reddit.com > /dev/null 2>&1)
    real	0m0.389s
    user	0m0.036s
    sys	0m0.012s

So for Reddit, I'm going to make the cost of the redirect 21 milliseconds.

you're calculating load time the wrong way - you should not do time check outside the process as you do calling 'time' as another process from shell. consider using curl profiling option next time

With `time` you also calculated the process time curl needs to evaluate the 30x response and the reissued http request to www.

Which is valid since this processing time will be included in whatever application the user is using to access the website.

I'm aware I'm nitpicking and maybe too theoretical now, but the processing time would vary in whatever application the user is using.. I'm with negus here who basically means the same I guess. The generic danger here (regarding benchmarking) is that you're explicitly also benchmarking curl. In case curl/"the web client" would handle 30x redirects super inefficiently, these results could lead to wrong assumptions.

This is because reddit.com and www.reddit.com gets you the http-versions, which both are redirected to https

Try this: curl -sL https://{www.,}reddit.com -o\ /dev/null{,\ } -w "%{time_redirect}\n"

Can I ask you to explain that "-o\ /dev/null{,\ }" magic ?

It's not magic -- it's some form of crude error.

So first off what this does is, it expands to the expression:

    '-o /dev/null' '-o /dev/null '

Even if we remove the latter space by just using `{,}` instead of `{,\ }` curl still returns for me an error code 23 -- CURLE_WRITE_ERROR.

curl seems to interpret `'-o /wtf'` as a command to write to the file ` /wtf`, so this only makes sense if you have a directory called ` ` in the folder you're running from.

You can therefore do this correctly with:

    -o/dev/null{,}

and that correctly writes the contents to /dev/null without issuing a curl write error.

Thanks, it sure looks less ugly with -o/dev/null{,} I couldn't find any other way to get curl to stay silent and still output redirect times. Hence the crude hack. (Obviously my bash and curl versions had no problem with the spaces or I wouldn't have posted it)

Using the curl'ing tips up this branch of comments I programmed a highly sophisticated script and dropped it on github. :)

https://github.com/dougsimmons/301debate

Nice!

I would have gone for a simpler loop:

echo -e "sec\tmethod\turl";for url in {https,http}://{www.,}{en.wikipedia.org,{google,reddit,facebook,youtube,netflix,amazon,twitter,linkedin,msn}.com,google.co.in}; do curl -sL "$url" -w "%{time_redirect}\t${url%:}\t${url#//}\n" -o/dev/null; done|sort

Wow. Thanks for teaching me that. Yeah, yours is better, I'll lay it on github with a thank you and maybe "embrace and extend" it.

Or learn python and port it to python, I could swing it that way.. Cheers.

I cleared Firefox's cache, opened the waterfall diagram, and looked at the time between when I hit enter (assuming that's 0ms) and the time when the request for the www.* address went out. I was planning to subtract off DNS time if necessary but in all cases it hit the cache and contributed 0ms.

I didn't have wireshark open so I don't really know what happened with google. It surprised me too. Maybe something had to be re-transmitted? Now it seems to take 90-100ms. Perhaps I should have done best-of-three, but my point wasn't about precise numbers, it was about orders of magnitude, and "tens to hundreds of ms" is definitely more in line with what I expected than "a few us".

In most cases it should stay low too: your browser should retain a keep-alive to the web server, so you're not throwing away the connection.

Future requests will auto-resolve due to caching of the 301.

There are plenty of places in the world where internet latency is a big issue, not to mention mobile networks everywhere. There's no reason to add a roundtrip unless absolutely necessary.

Mediocre Wifi can easily add seconds of latency.

And this is EXACTLY why you should use www.

HTTP/301 redirects are "permanent" per the RFC, and therefore cacheable. Subsequent requests for the apex zone by the user should cause the browser to skip the first request entirely.

microseconds? That's definitely not the case. It takes 10s of milliseconds just to leave your internet router on busy wifi home networks. A 301 redirect is an extra network roundtrip for no gain and much more (perceived) latency.

that is actually false. The majority of people no longer type in www. For example, in the last 10 years branding has completely remove the www and so likewise user reaction has followed suit. Unless you are targeting an older crowd, the vast majority ignore www on a search. With chrome being the major browser now and with browsers allowing search from the address bar, lookup without www is pretty much standard - again assuming your users are in a class of under 35 years of age.

"many people" != "the majority". Having the site not work with www. would be very stupid.

I was going to write the exact same thing as you. But then I thought about Chrome removing "http://" to avoid displaying useless and dense information to the user. What about www?

That would be misleading as example.com and www.example.com are not guaranteed to be the same site.

Technically I guess you could make it a subdomain but no one would actually do that in a production site and in my 14 years have never seen it used, not to mention that major search engine bots will lookup both. The general user will simply type in the domain name more times than not without the www

`www` used to literally be a different host in a network (and in some cases, I'm sure still is) specifically designated for WWW traffic. Think of universities in the 90s which had their existing infrastructure and an Internet facing host on their primary domain and they want to add a web server. They may have had a firewall, probably no load balances, so routing port 80 around their primary host was much more complicated than just throwing up a new host and DNS entry.

I regularly come across sites that only work with "www.". Common with university sites that use the subdomain hierarchy a lot. For extra fun, make the behavior reversed depending on if you are inside or outside their network.

My uni makes this extra fun with different sites on http and https.

Oh yeah. And then someone enables HSTS and a subdomain doesn't support HTTPS, so now you have to keep a browser around that never ever is allowed to contact the parent site...

Same with my uni. And then you have sites that only work with, and others that only work without the www.

But it makes sense. the first subdomain before the uni domain specifies the faculty, many of which have their own datacenters. Then many of those have yet their own servers in their network, and often www. is one added later on.

You could say the same for http:// and https://.

I don't think chrome (or any browser) removes https:// from url bars. They only remove http://.

Doesn’t safari mobile do that?

Safari desktop as well.

Ah you're right! For some reason I had it in my head that Chrome was hiding that. I really just hate that it hides any part of the full URL.

No you couldn't, with http vs https you are accessing the exact same resource, just through a different protocol.

Not necessarily. I've written my share of rewrite rules that change behavior based on https vs http.

Imagining that were true, you would never be redirected to an https version of a page.

Well, if the org hosting the content is being nice and following convention, sure.

But, there's nothing stopping me from running a webserver listening on port 80 (so, accessed in the browser at http://example.com) that serves a picture of a baseball. I can also run a webserver listening on port 443 only (with SSL/TLS set up, so accessed in a browser at https://example.com), on the same machine, that serves a picture of a dog instead.

This sort of breaks the rules/conventions though because you expect the resource to be the same by nature of the URL you're using to access it. But nobody has to follow that rule

That's one way to set it up, but there's no guarantee of that. Servers may switch anything based on TLS status or really any other property of a client request.

The protocol name is part of the URL, so it is possible and technically valid that the https version leads to different content than the http version. Some things are certainly different, for example if there are ads and other linked resources on the https page, they all need to go through https, while on http page, there is no such requirement.

I agree with this. The people saying it's technically possible to get a different webpage at that resource address are missing the point - it's trivial to do A/B with the same site, same port, same protocol, based on user IP, time of day or a RNG.

The point of URL is to identify a single address owned by one guy. Removing the www subdomain means you have two addresses, possibly owned by two guys.

Apple actually does this on the iPhone.

I know IE used to do this too.

> www vs. no-www, as a matter of "putting the customer first" is so INCREDIBLY insignificant

I don't know, I've always been fascinated by the premium of domains that are just one character shorter, and all of the startups that exclude a vowel to get a compressed (or maybe just available) name. That could reflect actual user preferences.

UX theorists convinced me over the last decade that user behavior is shaped by tiny moments and irritations that we think are insignificant at first glance. A few 100 ms extra in delays may seem barely perceptible, but they can kill a site. It's not implausible that a few extra keystrokes could do the same.[0]

On the other hand, redirects seem like a happy medium, so long as they're fast enough. nasa.gov uses a redirect, that seems fine. Note that they were driven to that (from 'www'-only) after confused fans kept writing in to complain that "http://nasa.gov" was a dead end and that they didn't "even know the basics of running a website."[1]

[0] https://www.nngroup.com/articles/response-times-3-important-... N.B.: In that link, Jakob Nielsen recommended making "www" optional through redirects. It's been a while, so not sure his current thoughts, but the same reasons would apply today. https://www.nngroup.com/articles/compound-domain-names/

[1] https://blogs.nasa.gov/nasadotgov/2011/05/31/post_1306860816... NASA's case provides a real example of something Jakob Nielsen pointed out in the first link: usability is a slave to expectations. So if enough popular sites are using naked domains, and your naked domain just 404s, some users will dismiss your site as unreliable.

Do you a think a user should have to write:

http://www.apple.com:80/

or:

http://www.apple.com/

Ever since the first web browsers, way back in the early 1990s, it has been commonplace to leave out the port number. The web browser adds it automatically.

Similar logic would lead us to leave off the "http". And similar logic would lead us to leave off the "www". The trend has been to simplify the URL as much as possible.

Nobody is suggesting the user should be forced to type in the protocol, the subdomain, or the port number. If the user types in:

apple.com

It should lead to where the user wants to go.

However, there are good reasons for using the www subdomain as the canonical URL, and it is also worth noting that some users will habitually type in www anyway.

If you don't want to include the subdomain in marketing material, then there's nothing stopping you from leaving it out, just as there's nothing stopping you from leaving out the protocol.

And even just typing:

apple

Should lead to where they want to go.

Which leads to 127.0.53.53 on Iceweasel 38.5.0 https://www.icann.org/namecollision

From the article:

Should I redirect no-www to www?

Yes.

Redirection ensures that visitors who type in your URL reach you regardless of which form they use, and also ensures that search engines index your canonical URLs properly.

So I don't think you're advocating anything they don't.

Annoyingly, this can be difficult to do if the A record for your domain doesn't point to a webserver. There are other legitimate things it could point to, like an authentication domain controller or a session border controller. Do you really want to be running a webserver there, even if it's only redirecting?

I'm not familiar with session border controllers, but DCs can be and usually are placed somewhere at the apex of the domain, via SRV records.

If you really have trouble, you can tell your firewall to route ports 80 and 443 to another machine and everything else to the device you need. (I've run a hackier version of this that used netcat inside inetd: we didn't want a web server on the machine that owned the domain name, but there was another nearby web server cluster that we added a virtual host to. And we were fine running inetd and netcat on the machine.)

I've done something similar but using iptables and dnsmasq to route DNS differently depending on where the requests were coming from and what domain they were asking about.

Your argument that eliding the www is better for users is logical, but you failed to make any argument whatsoever that it is significant. Given that you were responding to a statement that the difference isn't significant, you're basically attacking a straw man.

The www serves as a clue that it's a URL. Most people would recognize example.com as a domain even if given no other context. Contrast that with example.design. I think to most, www.example.design would be more recognizable.

I think few people look at URLs. They click on whatever is underlined or looks like a button.

There are a lot of offline ads (billboards, magazines, TV spots) that give out a URL.

More likely a QR code these days

http://picturesofpeoplescanningqrcodes.tumblr.com/

Thanks for sharing. I was a bit dense for a few minutes.

Haha, yeah I get it. But I scan QR codes all the time, maybe I'll take a photo and submit it.

Is there a good (or even native) app to scan these on iPhone?

Everything I have tried is lackluster. I'm to the point where if something is qr only I just don't care enough and move on

RedLaser works well. Really well, actually. I'm not a QR fan, but hey every now and again I do scan one (usually out of some weird curiosity) and RedLaser is the best app for the job.

Opera mini does its job, and approaches QR codes the right way, being an input alternative to the keyboard reachable from the omnibox

Scanbot. Great app for scanning documents, but when you scan a QR code, it handles it.

People still use QR codes?

They ever did?

Well I think people did, once, but then immediately discovered it wasn't worth the effort.

I do for any printed media. It makes it easier for people to look up the corresponding electronic version of a document. QR code has its uses, but tends fail when misused. QR code is best when interacting with it is strictly optional.

For loading two-factor authentication secrets. Or anything else you can think of that has too much information to convey with a short link. If you are directing people to a web site using QR codes then you're doing it wrong. Well, wrong now that everyone has realized just how limited QR codes are.

I use them at bus stops to pull up live tracking

They're great for managing parts in a manufacturer's storeroom. A QR code is more information-dense than a barcode.

Right. By the time most people remember how to scan a QR code, they could've typed in the URL.

Even as a technical person, I hardly use URLs apart from sites I know well.

I've noticed more and more recently a trend of billboards and things that just say 'Search [name]' instead of putting their URL there.

I've seen it too. That's a lot of confidence in their SEO.

Not really, if I were doing this, I'd buy ads for the search term so I can guarantee (within reason) I'm at the top.

I bet the sign itself serves as search engine optimization. If everybody starts searching for "foo" and clicks on my site in the result set then a reasonable search engine might bump my site up higher for searches for "foo."

That's an interesting hypothesis. It makes sense for the company both as optimization of their web pages for search engines and as making good impression on customers.

If people don't look at the URL there's no usability issue either way, so you might as well use the www version for technical reasons. This (sub-)discussion pertains to people who do look at the url. (And personally I agree that the www helps to denote a url, and so it's a net positive for users, or at least not a net negative.)

I saw a poster on a bus with domain.sydney sitting on its own line with no other context. I'd expect the majority of people had no idea it was a web address.

This would really depend on the demographic. Someone that is more technologically inclined would understand. However, appealing to the broad spectrum the general public would not. However, that example has to do more with the domain extension rather than www. Another example would be the .co domain extension example. In the western part of the country it could be easily recognize, but in the Midwest the demographic is much different and the general public may feel that a .co domain is merely a spelling error. It's all about your user demographic and their perception. Go with non www and then a redirect. Unless your demographic runs on 2G, either way isn't going to drastically affect your users. I would be more concerned about your file and images sizes than 100ms of a redirect.

Yea, there should be an http:// before it on print media. Otherwise no one is going to type it into their phone. I've done that for a couple of projects that use non-standard domains

In my experience from my wedding site, which used the .dance tld no matter how hard you try people will add .com to the end.

I had mine on http://[subdomain].rya.nc/wedding/ and had it printed that way with the wedding invitations and even my less technical relatives didn't seem to have problems with it. Did you have a bare domain or did you include http:// and the trailing slash?

I had http://supermarried.dance/ on our invitations. That really apparently confused our older relatives.

Maybe having a subdirectory helped.

When we did some research for RBI (part of Reed Elsevier) w found that about 8 - 10% of our inbound links linked to the wrong version of the home page.

So correctly handling all standard HP synonyms is a good start for all sites.

HP synonyms?

Apparently it's too hard to type "Home Page".

Why not http://? To me it looks more obviously like a web address. www just looks weird

My domain is not immediately obvious as an URL: hisham.hm (also my username in many places, or variants of it, like @hisham_hm). Sometimes I do need to make it more obvious that it's an URL (e.g. when printed, or on presentation slides). In those cases I write it as http://hisham.hm

What looks less technical and more user friendly on a business card?

http://hisham.hm or www.hisham.hm

Personally, I think www is. And it's shorter.

How about @hisham.hm? People are used to seeing it as part of email but it conveys that it's an internet address.

I would think that's a twitter handle and I don't even use twitter.

> This reasoning is all based on valid, but technical issues for the hosting side. A general rule for any customer-facing business is to put the customer first.

The article says:

"Should I redirect no-www to www?

Yes.

Redirection ensures that visitors who type in your URL reach you regardless of which form they use, and also ensures that search engines index your canonical URLs properly."

What is your point? I mean, everything the parent wrote still applies.

For very little effort you can simply redirect your main domain, and gain the technical benefits/simplicity of having a www subdomain, all while not inconveniencing your users. This pretty much makes the parent's point of hosting actual content on the main domain for customer convenience moot.

Where is the best place to do that? A redirect at the domain registrar, in my webserver (e.g. Apache), or in my app?

There's a slight advantage to doing it at the registrar because it keeps the hit off your servers. This is assuming of course that http://foo.com/bar will get redirected to http://www.foo.com/bar rather than just having everything redirected to the http://www.foo.com.

Edit: I'm wrong. See tadfisher's comment below.

Note that the usual method for doing so (a CNAME on the bare domain) prevents you from adding other resource records (such as MX) on the domain.

1. http://joshstrange.com/why-its-a-bad-idea-to-put-a-cname-rec...

Great point. And candidly I never actually do this myself (CNAME on the bare domain), I just point it at the server and let apache/nginx handle the redirect.

That's interesting. Currently I have 2 different domains at 2 different registrars. In each case I have the bare name, www and other subdomains as "A" records, not CNAME.

So it doesn't matter if people use the www prefix or not, since both point to the same IP. And with this configuration I've had no trouble with MX records.

If the goal is www/no-www transparency, there are other ways to do it, but using a simple DNS setup seems like the least hassle.

The main reason to redirect to one or the other is to have a canonical URL scheme for search engines.

Yes, this is the problem at my registrar if I setup a redirect there. Everything gets redirected to www.foo.com instead of www.foo.com/bar.

You will want the naked and www subdomains to point to the same address in your DNS configuration, and you will want to configure your webserver to issue a 301 redirect to the canonical subdomain at the HTTP layer. There are several reasons for this, but the most pressing is that it does not make sense to use a CNAME record for the naked domain.

If you have a larger setup, you’d want to already serve the 301 on your load balancer.

Find me this customer cohort that gives even a moment's hesitation about whether they're at a naked domain or not.

It could add to the overall experience, just like tiny details in a logo or a well-considered font choice could.

Further, most lay users are familiar with large web properties (amazon, google, apple), and most of those large properties redirect to www (due to aforementioned technical reasons). So if such a user even happens to notice, if anything, they may find it odd to not see a www prefix.

I think that this is exactly right. I have personally observed users become confused over a URL not starting with www. Occasionally I have even seen them add it, just because it was assumed that all addresses should have it at the beginning.

This might change eventually, but it will change slowly if so.

Aesthetics aside, one benefit of naked domains is that shorter URLs are better for sharing in chat programs. 'www.' takes up a nontrivial amount of space in certain environments (e.g., a gchat window within gmail).

I'm not sure I understand why this creates any real issues.

I personally dislike it. It's annoying. Links can be long as it already.

Hence the purpose of the redirect so links to the naked domain work just as well.

But most users will copy/paste whatever's in their URL bar, which will include www. if the site redirected them to it.

When computers was relatively new to me, I used to suspect naked domains of phishing. So there's that.

It sucks that this is the state of things, because of the technical infrastructure that's supporting these systems. But it's absolutely not being advocated because it's technically more efficient, because it's cute for branding, because it helps the marketing team collect customer data. It's entirely based on being able to provide the highest level of consistent service to a customer.

Doing it any other way is prioritizing brand over customer.

It doesn't just suck, it's bad for almost everyone.

> Should I redirect no-www to www?

My guy reaction is still no, fix the technology that was never designed for this mass consumer use. DNS could support cnames for naked domains, but the standard groups only care about backward compatibility and 0-risk, while consumers still don't understand how DNS works at all, and now we have developers who apparently need articles spoon feeding them why it's bad one way and not another.

I think most people are used to having www. in front of a url. If they even notice it, I think it will confuse them not having that.

You're describing a world where everybody expected a website to end in .com, and if not that, then maybe a handful of others. That world is changing; what will people's expectations be in the future?

My blog has the URL http://boston.conman.org/ (leaving http://www.conman.org/ for other stuff on my website). I had to add a redirect for http://www.boston.conman.org/ because I had a non-zero number of requests.

This is a good point. Any subdomain that you host web pages on should itself have a www sub that redirects, for this reason.

I've seen some sites that redirect to m.example.com if you're accessing them from a phone. Do you think people are getting confused by that?

Uptime and performance is typically some of the most important things for customers. Definitively way more important in general than whether there's a www prefix or not...

I agree. Microsoft, Apple, and Google have the ability to modify user behavior without much downside. The rest of us are better off making the user experience as fast, efficient, and simple as possible.

By coincidence, I just put a 301 redirect on my personal site to go from www.xpda.com to xpda.com two days ago. If I could only get ctrl-enter to submit https://domain.com instead of http://www.domain.com in Firefox, I'd be happy. (There was a bug that prevented this last time I checked.)

Using www puts the customer first.

Being able to serve your website from a CDN helps the customer: it means the website is up when they want to visit it, and it usually means it's faster for them.

Having static content not get cookies helps the customer: it keeps HTTP traffic down, which means that pages load faster.

Separating cookies between different websites helps the customer: it means that when, inevitably, blog.example.com gets broken into, the customer's account info at www.example.com is not compromised. (Of course, this assumes that you're doing least-privilege between your various websites, but you're already doing that because you care about your customer and don't want to send them a letter about how you lost their personal information.)

Not using a separate top-level domain for static content helps the customer: they know that www.example.com and static.example.com are from the same company they trust, Example Industries, Inc. If you caused their browser to show that it's loading files from "static.excdn.com" or something, they might worry.

The customer isn't personally following the redirect; their browser does, so I'm not sure I understand how the redirect deprioritizes the user. As far as visual clutter goes, get an EV cert, which either supplants or replaces the address bar with something much more useful than a URL:

https://www.expeditedssl.com/assets/browser-ssl/extended-val...

What!? You saying we can't make absolute rules? We have to consider the context? Horrible person!

On that note.. those minimalist designs are quite hard for older or less tech savvy to understand at times. Not the www part of course but the designs in general. Something to consider when putting the customer first maybe..

Reply on news.ycombinator.com