5 ms·

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

by tszming 12y ago

AhtiK 12y ago
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 :)
- marcosdumay 12y ago
  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.
  - justizin 12y ago
    your conjecture shows a clear lack of having spent any time optimizing websites to respond in less than one second.
- skybrian 12y ago
  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.
mikegirouard 12y ago
… and security. If there's anything that will make me reluctantly enforce a www subdomain, it would be security.
- AhtiK 12y ago
  What is the concern with security?
  - pritambaral 12y ago
    If you let others host their content in a subdomain, like github.com did with Github Pages, they may get your main domain cookies.
    - mynameisvlad 12y ago
      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.
      - hueving 12y ago
        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.
donatj 12y ago
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.
jonatanheyman 12y ago
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.
- tszming 12y ago
  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 http://no-www.org) for the matter of taste without mentioning the potential drawbacks (even there are workarounds), is irresponsible IMO.
  - mynameisvlad 12y ago
    > 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.
  - vacri 12y ago
    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...)
- nilved 12y ago
  There's also an extra DNS request on each page

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

by tszming 12y ago

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

AhtiK 12y ago

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 :)

marcosdumay 12y ago
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.
- justizin 12y ago
  your conjecture shows a clear lack of having spent any time optimizing websites to respond in less than one second.
skybrian 12y ago
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.

mikegirouard 12y ago

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

AhtiK 12y ago
What is the concern with security?
- pritambaral 12y ago
  If you let others host their content in a subdomain, like github.com did with Github Pages, they may get your main domain cookies.
  - mynameisvlad 12y ago
    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.
    - hueving 12y ago
      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.

donatj 12y ago

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.

jonatanheyman 12y ago

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.

tszming 12y ago
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 http://no-www.org) for the matter of taste without mentioning the potential drawbacks (even there are workarounds), is irresponsible IMO.
- mynameisvlad 12y ago
  > 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.
- vacri 12y ago
  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...)
nilved 12y ago
There's also an extra DNS request on each page