Small things add up: 4chan's migration to a cookieless domain
chrishateswriting.com
Small things add up: 4chan's migration to a cookieless domain
1–10 of 139 posts
Re: Small things add up: 4chan's migration to a cookieless domain
#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 the other hand, if saving single bytes was significant, there would be a lot more potential in the source by shortening CSS class names etc. rather than picking a short domain name.
EDIT: According to http://www.4chan.org/advertise, there are a total of 575,000,000 monthly page impressions.
Re: Small things add up: 4chan's migration to a cookieless domain
#3> 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…
That's still 25GB/month of bandwidth they save. Who knows, maybe that nudges them out of a high-cost data tier.
Re: Small things add up: 4chan's migration to a cookieless domain
#4> 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…
You are looking at the traffic sent by the server to the client but cookies are sent by the client to the server. Upstream vs. downstream. Cookies are much larger proportion of the request. Also the response can't even be sent until the entire request is retrieved.
Re: Small things add up: 4chan's migration to a cookieless domain
#5> 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…
Sure, but that's just by pointing image URLs, etc., to a shorter domain vs. a longer one.
There's also savings in not sending cookies with every image request - which saves them a honkin' 46 terabytes.
Plus, he himself admits that this isn't the first place to start optimizing - it's just where he chose to.
Re: Small things add up: 4chan's migration to a cookieless domain
#6> 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…
They have around 100 images on a single page, and google analytics increases the 50 bytes with 1KB. This does indeed result in 100kb overhead
Re: Small things add up: 4chan's migration to a cookieless domain
#7> 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…
That's still 25GB/month of bandwidth they save. Who knows, maybe that nudges them out of a high-cost data tier.
My point was that "saving 25 GiB" is way below anything they can possibly care about. How much traffic does 4chan handle in a single hour? I think it's pretty safe to assume that 25 GiB is significantly lower than one standard deviation of their monthly traffic, so cutting costs with it is also not feasible.
Re: Small things add up: 4chan's migration to a cookieless domain
#8> 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…
They have around 100 images on a single page, and google analytics increases the 50 bytes with 1KB. This does indeed result in 100kb overhead
I think you're confusing the two benefits.
What the thread OP is talking about is the decrease in page size from the URLs included in the page source. Choosing a shorter URL for the static domain versus a longer one resulted in a rough savings of 50 bytes per page (size), compressed.
You're referring to request cookie size, which was also decreased significantly (CloudFlare still sets a single cookie, unfortunately), which results in the big savings of ~100 KB upstream per page load.
Re: Small things add up: 4chan's migration to a cookieless domain
#9I doubt domain length will really make any difference, gzip compression should take care of a longer domain name.
Re: Small things add up: 4chan's migration to a cookieless domain
#10I never even contemplated the size of cookies before seeing this. It never occurred to me that it could create such an overhead. It'd be incredibly handy if we could set a header like `x-send-cookies: NO` to stop the browser sending cookies along for static content. Great post, a real eye opener.