Live data from Hacker News

Small things add up: 4chan's migration to a cookieless domain

chrishateswriting.com

81–90 of 139 posts

Re: Small things add up: 4chan's migration to a cookieless domain

#81
post #27

moot, given that your site seems like an ideal candidate for WebP, why not use it with pagespeed (and/or let users opt to use the format when posting)?

In order to stay compatible with non-WebP-supporting browsers, moot would have to keep two versions of image files on the disk, causing a lot of pain and HDD waste.

It could work for the smaller boards, though...

Re: Small things add up: 4chan's migration to a cookieless domain

#82
post #79

Earlier quoted context omitted.

the markup before is already 1,836 bytes All those bytes are justified because they are rendered on the screen provide direct utility to the user. The extra 50 bytes does nothing but slow the page down. there would be a lot more potential in the source by shortening CSS class names etc There is no either/or here: this can and should be done as well.

Is there a good CSS minifier which looks at the CSS as well as the HTML, and shortens class names automatically? In most cases I don't really care what the class names are in the final HTML, as long as they match up with the CSS. I realize there are a lot of things that could go wrong, such as * correlating the HTML and CSS for an entire site instead of just one page * dealing with third party dependencies that requi…

I don't think there's anything that will change the class names, but there are minifiers

http://yui.github.io/yuicompressor/css.html

Changing the class names would be difficult as it wouldn't pick up any dynamic class names, like

    var className = 'user_' + user.getState(); //'user_deleted' or 'user_active'

Re: Small things add up: 4chan's migration to a cookieless domain

#85
post #15
post #9

I doubt domain length will really make any difference, gzip compression should take care of a longer domain name.

The 50 bytes figure represents a compressed response. (We actually write all of our pages compressed to disk before serving them -- nothing is served dynamically. But that's for another post...) The example below isn't the most scientific, but should give you a rough idea. Test index page with different static URLs: URLs as 4cdn.org -- 23261 bytes compressed URLs as 4chan-cdn.org -- 23311 bytes compressed URLs as 4ch…

So 4ch.io would have knocked-off another 30 bytes or so?

Re: Small things add up: 4chan's migration to a cookieless domain

#86
post #74
post #52

Earlier quoted context omitted.

Well it's a single kilobyte, but 100 KB in aggregate. It's almost entirely Google Analytics, unfortunately. Our ads are served from a different domain (4chan-ads.org) for specifically this reason (user privacy and cookie bloat).

Have you ever thought of running server-side analytics?

Yes, but every time I've investigated it, the tl;dr was "not worth it" given our requirements/constraints.

Google Analytics has its shortcomings, but it's a great product and free.

Re: Small things add up: 4chan's migration to a cookieless domain

#87
post #51

Now, what about the extra DNS lookups? That adds 1x roundtrip time for the user, plus 20-40 bytes of IP header (v4/v6), plus 8 bytes UDP header, plus ~25 bytes for the query and ~100 bytes for the reply.

Wouldn't that be cached after the first load?

Yes it would be.

Re: Small things add up: 4chan's migration to a cookieless domain

#88
post #15

Earlier quoted context omitted.

The 50 bytes figure represents a compressed response. (We actually write all of our pages compressed to disk before serving them -- nothing is served dynamically. But that's for another post...) The example below isn't the most scientific, but should give you a rough idea. Test index page with different static URLs: URLs as 4cdn.org -- 23261 bytes compressed URLs as 4chan-cdn.org -- 23311 bytes compressed URLs as 4ch…

So 4ch.io would have knocked-off another 30 bytes or so?

BRB, switching everything now!

Re: Small things add up: 4chan's migration to a cookieless domain

#89
post #75
post #58

Earlier quoted context omitted.

Actually 78.75% of our users are on Chrome/Firefox! SSL is forced on our domain you post to (sys.4chan.org) with redirects and HSTS, and we set cookies with proper Secure and HTTP-Only flags. Maybe some day we'll force SSL site-wide, but I don't think that's the right decision for now. I definitely encourage people use the EFF's wonderful HTTPS Everywhere extension though: https://www.eff.org/https-everywhere

78.75%? That's great news! I imagined a lot of people would be using mobile and I know that Safari iOS doesn't support SPDY. Does this mean that > 80% of users are browsing on desktops, or is it possible there's a mobile app that's reporting a false user agent? Or maybe all the iOS users fell victim to waterproof tests...

We get surprisingly little mobile web traffic -- only 16% in November.

Re: Small things add up: 4chan's migration to a cookieless domain

#90
post #77
post #52

Earlier quoted context omitted.

Well it's a single kilobyte, but 100 KB in aggregate. It's almost entirely Google Analytics, unfortunately. Our ads are served from a different domain (4chan-ads.org) for specifically this reason (user privacy and cookie bloat).

The newest version of Google Analytics eliminates most of the cookie bloat. There's now just a single id cookie that's around 30 bytes or so. https://developers.google.com/analytics/devguides/collection...

Wasn't aware of this (but was hoping it was in the works) -- thanks a bunch!
Post reply on HN