6 ms·

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 u

by rtpg 11y ago

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

coldtea 11y ago
>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.
vog 11y ago
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.
jacquesm 11y ago
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.
- 5h 11y ago
  if you care about bytes, you could minimise the css & html also
  - rtpg 11y ago
    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.
    - SomeCallMeTim 11y ago
      gzip should already be enabled on any modern server/browser.
- nevinera 11y ago
  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!
  - jacquesm 11y ago
    > 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.
    - nevinera 11y ago
      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?
collinmanderson 11y ago
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.

by rtpg 11y ago

coldtea 11y ago

>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.

vog 11y ago

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.

jacquesm 11y ago

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.

5h 11y ago
if you care about bytes, you could minimise the css & html also
- rtpg 11y ago
  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.
  - SomeCallMeTim 11y ago
    gzip should already be enabled on any modern server/browser.
nevinera 11y ago
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!
- jacquesm 11y ago
  > 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.
  - nevinera 11y ago
    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?

collinmanderson 11y ago

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.