Hacker News Reader

Comment by rtpg | Hacker News Reader

doesn't inlining the CSS make the page require more data in the long run? Especially if you're not changing it often

Browser caches solve a lot of things for us. Though you're still parsing a bunch of JS, google's front page is "only" fetching 56kb

Granted, this blog post is 13.5kb, but it doesn't have an entire search app embedded into it (with the whole search results automatically appearing thing, I imagine that inside that 56kb is pretty much all the code required for all of google's little widgets in the search results)

Anyways, always fun to see somebody go in and rip out as much cruft as possible

View on HN

For small datasets[1], latency may dominate bitrate. So it may be advantageous to receive everything with a single request and a single response.

Also, if your blog doesn't change often, it will also be seldom visited[2]. So the browser cache may not help here - either due to cache invalidation, or because you changed a tiny bit of your CSS in the meantime.

[1] And honestly, from that perspective all blogs are small.

[2] Ideally, all your readers use Atom/RSS.

There is a small penalty but it does not seem to weigh up against the advantage of having all the data in one shot even on first page view on that site. Total overhead of the CSS 'in flight' is about 6.6K, versus doing another request which would require another round-trip to the server.

Inlining the CSS was considerably faster in all my tests.

How much of that win was only on the first time a page from your site is requested?

I'd expect in-lining the css to be a slight net loss once the data is cached - my strategy would be a `style-<md5sum>.css` with a long max-age.

I wish browsers could cache page fragments!

> I'd expect in-lining the css to be a slight net loss once the data is cached

I expected that too but it didn't work out that way. I'm not sure why, possibly a cache lookup is still slower than reading the style info out of the same page. I don't know enough about the guts of a modern browser to make the call but the numbers aren't there.

In chrome, I'm getting extremely similar times for the two approaches without caching (I am in-network, so my roundtrips are ~1ms). With the style.css fully cached, I'm getting ~15ms faster on the sideband approach than with inline styles.

Can you expose your methodology, or are you using a common tool for testing these things?

Using FF development tools. Shift-ctrl-Q, reload.

It looks like inline performs better on firefox and not on chrome - I just made a bunch of attempts both ways, and I'm seeing cached sideband as significantly better on Chrome, and only roughly equal on firefox.

I was not expecting to see such a difference between the two browsers, but I'm not familiar enough with firefox to guess what's causing it :-\

Ah! Thank you for that datapoint, I don't use Chrome but I really should have tested that too.

if you care about bytes, you could minimise the css & html also

then the ultimate, which would be whether you use web components to minimize tag lengths/define structures to compress.

Though at that point gzip is probably the better solution.

gzip should already be enabled on any modern server/browser.

>doesn't inlining the CSS make the page require more data in the long run? Especially if you're not changing it often Browser caches solve a lot of things for us.

Apparently they don't. I remember reading 2-3 articles on the issue, and most things we'd expect to go there, don't even touch the browser cache.

Maybe for Google (a page we visit every day multiple times) that would be different, but for your average site the browser cache could as well be a forbidden zone with all the competition for the same limited resource.

As a data point: I skimmed the article once, clicked no links, and will likely never go to that site again in the next month. Browser caching won't help me.

Reply on news.ycombinator.com