Hacker News Reader

Comment by AhtiK | Hacker News Reader

Performance penalty is no longer an issue with AWS: CloudFront support for root domain/zone apex has been there since June 2013 [1].

DNSMadeEasy has ANAME for somewhat similar purpose [2].

It's worth noting that AWS CloudFront works ONLY with AWS Route 53 for the proper latency-based routing with root domains. Yes, DNSMadeEasy ANAME works with CloudFront too but it's not smart about returning the closest edge to the user.

[1] http://aws.amazon.com/about-aws/whats-new/2013/06/11/announc...

[2] http://www.dnsmadeeasy.com/press-release/dns-made-easy-intro...

View on HN

The issue with cookies mentioned in the article is still valid, which also affect performance.

Yep, still valid, cookies are sent.

But performance-wise if the cookie is just a session id then maybe sending a few hundred bytes extra with each resource request doesn't even show up in profiling.

With cookies the number of connections opened remains the same, amount of bytes received remains the same.

Most of the network time with a pageload is wasted on opening a connection for each resource and streaming the output, if there's a need to optimize then instead of getting rid of cookies it's better to concat resources etc or move to SPDY.

OR, just buy that second domain for static content if client-side performance becomes that important and sending unneeded cookies feels like a waste :)

Odds are your client will send those cookies by some ethernet network, that'll pad every package into a minimum size much larger than the request anyway.

And if you get a client that isn't using ethernet (maybe GSM, what is its minimum package size?), they'll probably use large TCP packets too, and pad at that level.

your conjecture shows a clear lack of having spent any time optimizing websites to respond in less than one second.

Large websites maintained by many teams tend to accumulate cookies over time. When you have dozens of cookies for various one-off purposes, getting rid of a cookie means tracking down all the places where it might be used. It's easier if it's set on a subdomain.

… and security.

If there's anything that will make me reluctantly enforce a www subdomain, it would be security.

What is the concern with security?

If you let others host their content in a subdomain, like github.com did with Github Pages, they may get your main domain cookies.

That's a ridiculously specific use case, and unless you're making a web host service, you're not really going to be running into that security issue. It's good to think about, but unlikely to happen.

It's not that specific. I know lots of companies will use a third party service for something like a helpdesk and will setup support.theirdomain.com to point to the third party. The cookies for the root may then be leaked to the third party.

How many cookies do you have that it affects performance?

Enabling do not track adds about as much header info as a php session cookie, should we be advising people not to enable do not track as it will affect performance? That's just silly.

I mean either way were adding only a few bytes to the request.

If the issue is caching based on headers that is an awful naive CDN as there are going to be literally thousands of variations in the user agent and accept language headers.

I mean maybe a few bytes for headers made a difference in dial up days but I assure you they make no difference today.

Well, if we're talking about "millions (or more) of page views per day", as the article is, the cost of buying an extra domain for static content is insignificant. You could also serve your static content from your CDN provider's domain.

Yes you are right, there are always workarounds! But why not make your life easier by just accepting...the "www" as the default? It is a convention well understood by most people in the Interweb. Honestly, I cannot see any technical reason to support removing "www" except someone's personal preferences.

I would argue, IMO, when you need to expand you subdomains in the future, mixing naked domain and subdomains is even more uglier, and cause the inconsistencies, e.g.

example.com api.example.com admin.example.com

When we are talking about the default, it should be safe to use, and "www" is the safe choice here for people who NEVER heard about the CNAME and the cookie issues. Advertising something (like http://no-www.org) for the matter of taste without mentioning the potential drawbacks (even there are workarounds), is irresponsible IMO.

> example.com api.example.com admin.example.com

That seems perfectly normal to me. The first one is the main service, the second is the API for that service, the third the admin site for that service.

www. used to be convention, but it doesn't seem to be anymore. Listening to the way people talk casually, they'll say "go to [site].com, not [prefix].[site].com". www. seemed to be the standard back when people were confused about how slashes worked or what bit goes where. Now it's just [site], with a .com on the end to indicate it's a website (sometimes even if it's not a .com...)

There's also an extra DNS request on each page

How is it an extra DNS request?

Whether you use www or not wont it will still be two DNS requests?

  www.mysite.com  
  static.mysite.com

compared to

  mysite.com
  mysitestatic.com

> Performance penalty is no longer an issue with AWS: CloudFront support for root domain/zone apex has been there since June 2013 [1].

And it does it through an hardcoded alias and not a cname. How clever.

Reply on news.ycombinator.com