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)?
It could work for the smaller boards, though...
81–90 of 139 posts
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)?
It could work for the smaller boards, though...
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…
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'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.
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…
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?
Google Analytics has its shortcomings, but it's a great product and free.
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?
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...
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...