Top Mistakes of Massive CSS | Hacker News Reader

Top Mistakes of Massive CSS

stevesouders.com

15 pointsjackowayed14 comments

Aren't most of these 'rules' applicable to just about everything you serve from your domain, not just CSS?

Yes but everything else except the document is supposedly optional and tend to scale up rather quickly. So these rules have a little more weight when applied to your CSSes and JSes.

One small question: why wasn't the link to the original posting at Stubbornella rather than to a reblog? Did I miss the meeting where we decided there were no girls allowed?

If you're serving your css / javascript gzipped is there any additional value to minifying it?

Yes. While combining minification and gzip doesn't produce as dramatic an improvement as either does above plain text, combining them does usually yield some additional improvement (especially if minification handles things like variable renaming in JS or property folding in CSS).

From experimentation using various "typical size" CSS, you can get a few more kb, which works out to about 3-7% extra savings for these file sizes.

Definitely worth it, particularly for high traffic sites.

56% Serving CSS with Cookies? Wow. I must have missed this wave of innovation. I honestly have never heard of this before.

Cookies are usually served by default with any http communication, including serving CSS files.

Well no. I think you must have confused HTTP headers with Cookies. Cookies are "set" by the server, usually only once per value, and then "sent" back from the client on every request. Cookies are an extension of HTTP, it's not served, whether by the client or the server, on any HTTP communication. It's only sent back by the client when it needs to tell the server it is maintaining a certain state. In the case of CSS, there's no state to maintain, so Cookies are certainly supposedly useless. For details, I refer you to RFC 2965.

I'm not sure what exactly what Steve Souders means when he wrote "serve CSS with Cookies". It sounds like 56% of the population piggyback CSS in the Cookie values...

If you're serving static media on a domain that also serves cookies then each request to the static media will include the cookie request.

Generally you can serve cookies on www.example.com and not have request to example.com include cookies.

Right, but how is this a problem that you can control? It's the client that sends back the cookies, not the server, and you can't control your clients. When you need to set a cookie, you just do.

I think this number needs some sort of clarifications from Steve Souders as to what he means.

Yes, this is a problem you can (and should) control.

It's as simple as registering mysitecdn.com (assuming your main domain is mysite.com) and serving all static content from there. Never set cookies against your CDN domain and they will never be in your users browser, thus ensuring he won't send them back to you with every request.

Ah ha this makes more sense. So if I don't want to use a real CDN, I can just set my cookies with a domain www.mysite.com, serve all my static content from cdn.mysite.com and I'm all set?

100% correct.

Just some clarification for those that don't get it. Setting cookies on mysite.com; means that the cookies will be pushed by the client for all subdomains for mysite.com (*.mysite.com);

-- But if you're setting cookies from www.mysite.com you can serve media from cdn.mysite.com and the requests from cdn.mysite.com will not push cookies to your server.

Reply on news.ycombinator.com