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

21–30 of 139 posts

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

#21

Post by moot »

zachrose wrote: post #18
tomp wrote: post #14

> If you’ve been linked directly to a Facebook photo, you may have noticed the domain wasn’t facebook.com, but instead something like fbcdn-x-x.akamaihd.net. Large sites load static content from special domains for a few reasons, but primarily to reduce request overhead, and sometimes security. This works for 4chan, but in case of Facebook, it actually reduces security - since cookies cannot be checked for photos on…

I'm interested in learning more about _how_ secure random URL parts are, and what kinds of attacks are seen in practice. Presumably an IP would get blocked after enough 404s?

I'm pretty certain 4channers are good at tracking down profile URLs from just a Facebook image URL/filename. I don't think you can access the full album per se, but you can definitely locate the profile.

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

#23

Post by psykovsky »

moot wrote: post #8
jbverschoor wrote: post #6

Earlier quoted context omitted.

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),…

Kind of off-topic, but how do you feel about doing a conscious MITM to your users(by using Cloudflare), being 4chan home of Anonymous and all that?

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

#24

Post by Killswitch »

quchen wrote: post #16
moot wrote: post #12

Earlier quoted context omitted.

You're absolutely right -- it is negligible. When you're serving upwards of a petabyte per month, 23 GB isn't exactly a lot! > 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. Also spot on, but the point I was trying to make is I was given the choice of choosing a longer domain and a…

Right, if you use a short domain name "because why not" for something new that's alright. It was just the "it adds up" part that I was commenting on. Do you have (well, you're moot, so -- want to share) some more data of 4chan's current size? I'm sure lots of people would be interested in hearing about that. (This would probably make a great individual post.)

I'd be very interested in this... I used to visit 4chan all the time back in the day, not so much now, but I do enjoy reading statistics about the site.

Thanks for this article moot.

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

#25

Post by hnha »

moot wrote: post #21
zachrose wrote: post #18

Earlier quoted context omitted.

I'm interested in learning more about _how_ secure random URL parts are, and what kinds of attacks are seen in practice. Presumably an IP would get blocked after enough 404s?

I'm pretty certain 4channers are good at tracking down profile URLs from just a Facebook image URL/filename. I don't think you can access the full album per se, but you can definitely locate the profile.

that's because the image urls actually include the profile id.

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

#26

Post by willvarfar »

moot wrote: post #12
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…

You're absolutely right -- it is negligible. When you're serving upwards of a petabyte per month, 23 GB isn't exactly a lot! > 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. Also spot on, but the point I was trying to make is I was given the choice of choosing a longer domain and a…

What is your caching like, and do you use precompression? In fact, how do you serve that many pages full-stop? We (HN) need to know!

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

#28

Post by largehotcoffee »

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 helps with the page size).

Finally, instead of using the browser extensions (which are helpful), get actual PageSpeed installed on the servers!

Apache: https://developers.google.com/speed/pagespeed/module nginx: https://github.com/pagespeed/ngx_pagespeed

Regardless, awesome stuff. Big fan. Much love.

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

#29

Post by lnanek2 »

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…

Each page of the site isn't all that different from the rest. They could just load the page once and update the page content with a JS AJAX call and DOM manipulation, honestly. You wouldn't even need to send full URLs for the images that way, just the unique part of the URL such that JS could reconstruct it from a constant prefix.

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

#30

Post by [deleted] »

moot wrote: post #12
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…

You're absolutely right -- it is negligible. When you're serving upwards of a petabyte per month, 23 GB isn't exactly a lot! > 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. Also spot on, but the point I was trying to make is I was given the choice of choosing a longer domain and a…

[deleted]
Post reply on HN