Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

chrishateswriting.com

Post reply on HN
Print view View original

101–110 of 139 posts

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

#101

Post by coldtea »

metafunctor wrote: post #80
nl wrote: 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…

No need, because you can gzip compress, which will make even better savings than that (because it can also compress and save space taken by tags etc, not just class names).

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

#102

Post by antihero »

largehotcoffee wrote: post #28

A quick look shows that you could minify the Javascript quite a bit more (which is relatively easy, and would save a lot more than 50 bytes). You might also look at inlining all of the Javascript into the HTML directly (this is what Google does), which saves the extra HTTP requests. You could also do this with some of the persistent images on the page (logo) and inline them with base64 (but I don't think it actually…

Wouldn't inlining the js mean that it's downloaded for every page request instead of being downloaded once and cached?

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

#103

Post by jhgg »

moot wrote: post #50
dangayle wrote: post #47

Earlier quoted context omitted.

Flat files on a disk == awesome

We've had a surprising amount of difficulty maintaining this over the years, since FreeBSD's NFSv4 implementation kind of sucked for a while, and it doesn't support mounting a memory partition (tmpfs). But you can trick it by mounting the memory partition using nullfs, and then nfsmount-ing that. We used that memory-partition-over-network thing for a while, but actually switched to SSD-over-network because it was fas…

Have you considered memcached with nginx HttpMemcachedModule? If so, why didn't you decide to use that instead? Seems like all of 4chan's active posts could easily fit in memory of server with a moderate amount of ram (especially if compressed).

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

#104

Post by parallelist »

quchen wrote: post #2

> 50 bytes may not seem like a lot, but when you’re serving 500 million pageviews per month, it adds up. That's a void argument in the article. If they were serving pages with 500 bytes each this would indeed be a huge improvement, but no page is 500 bytes. I just opened 4chan.org, and the markup before is already 1,836 bytes. The entire frontpage of /b/ is 114,428 bytes, and saving 50 is absolutely negligible. On th…

If the few bytes saved by this new domain seems worth commenting on what about the very large number of unnecessary whitespace characters they are serving?

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

#105

Post by jhgg »

doctorfoo wrote: post #63

Hey moot, why don't you let pass users bypass individual IP blocks? I refuse to disable my VPN, so it means I can't post any more. A shame 4chan has no way for privacy conscious users to post, especially given your support of StopWatching.us and such.

You can... you just have to shell out money for a 4chan pass :\

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

#108

Post by spydum »

gambler wrote: post #32

Maybe it's just me, but I hate how current web technologies force people to register separate domains for static content. This is not how domains are supposed to work.

Could always use cookie paths and require all secured or stateful actions to hit some path (domain.tld/a). As long as no cookies are set at root, same benefit.

However, having static assets spread across multiple host names also helps browsers which can spawn multiple threads to pull assets from a page. I think most browsers allow 4 concurrent threads per HOST. In this case, it's just one additional host.

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

#109

Post by dirkgently »

maxk42 wrote: post #75
moot wrote: 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...

Looks like you just assumed that iOS drives all the traffic on every website?

Having some idea of 4chan user base, I won't be surprized if android is more popular then iPhone.

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

#110

Post by jamesjporter »

cheald wrote: post #99
kibibu wrote: post #97

Earlier quoted context omitted.

We use wildcard cookies to let users login to www.domain and peek at beta.domain without logging in again. This isn't incompetence so much as reducing user drag. Perhaps I should have set it up to use www.domain/beta/ instead. Unfortunately, this means our cookies are sent to static.domain. Worse, once we get rid of beta.domain there's no going back on wildcard cookies - there's no way to force clients to expunge coo…

You could use beta.www.domain.com.

This makes a ton of sense, but it might be unorthodox enough to scare off some users thinking it was a scam of some sort.
Post reply on HN