Hacker News Reader

Comment by dmpatierno | Hacker News Reader

They're certainly doing the right thing here. JavaScript optimization is a constant battle between (1) reducing HTTP requests by grouping code together in a single file, and (2) reducing file sizes by splitting code into separate files.

You don't want to group too much because you risk downloading code you don't need, but you don't want to split too much because you need to keep HTTP requests low. Proper optimization requires intelligent grouping of related code to create a balance between these two ideals, allowing the browser to cache commonly used resources so subsequent page loads are fast.

Their blog page has 6 external JavaScript files and 4 external stylesheets. Those numbers are pretty reasonable given the scope of their site.

View on HN

There's no excuse for a blog to have 4 external stylesheets: these can easily be concatenated. Worse yet, they're not even minified.

You're right about them not being minified, but wrong about the need for 4 external stylesheets.

Look at their home page, for example. It uses just one stylesheet (v6core.css). That same file is also used on their blog, so my browser already has it cached. Perfect!

None of those stylesheets are less than 45K, so the savings they get from not needing to download them on every page outweighs the HTTP request hit they take by including them separately on more complex pages.

Even if the CSS is cached, your browser still needs to ask the server if the files has changed and receive back a "304 Not Modified," so you're still incurring the overhead of those connections.

Not if you set a proper far-future Expires header.

There's no excuse for a dedicated blog to have 4 stylesheets, sure. But this is a subpage of a big website. The stylesheets are based on logical separation, with more sheets getting added in as you go to more specialized pages. On the frontpage, which is really more of our focus, there's a single CSS file.

CSS doesn't get anywhere near as much benefit from being minified as JS does. There's much less scope for transformation of the code to make it smaller, so if you're serving your CSS gzipped (which we do) then the difference is minimal at best.

Good point on the redownloading part: I'd have to look into the actual numbers, if the homepage-primed connection count is still only 1 it's definitely worth it.

However, I disagree about the low benefit of minifying gzipped CSS. I thought the same thing too until I ran some tests. For example:

   34K v6core.css.gz
   27K v6core.min.css.gz

I ran your core CSS file through YUI compressor and then gzip. 7k of savings, over 20%, definitely seems worth it.

Interesting; that's a lot more than I had expected. It's only a few lines of code to change to make it happen, so we may well do it. (Need to do some quick checking to make sure that we don't have any old CSS hacks in there that might play poorly with being minified.)

Reply on news.ycombinator.com