3 ms·

I think the angle he's going for here is that if you have inline base64 blobs in your html/css code, and that's then served by a HTTP(S) server using gzip compr

I think the angle he's going for here is that if you have inline base64 blobs in your html/css code, and that's then served by a HTTP(S) server using gzip compression, are you wasting lots of space/bandwidth? and the answer is +5% to +2.5% overhead, which isn't much considering the larger advantage of a single round trip to the server as all the assets are embedded in the html document. Of course there's also the overhead of decoding all those base64 blobs in the browser, but I'm sure that's a topic for another blog post in the future :)

_petronius 8y ago
For the first load of the page, sure. But if you're embedding HTML and CSS, then you can't cache it separately, which means having to fetch it all on every request where anything has changed, in addition to the decoding etc on every request.
- masklinn 8y ago
  That can also be an advantage, if the connection has a high throughput but a high latency (e.g. cellular networks, still), you'd much rather fetch everything in a single request. There's a slight inefficiency in the inability to independently cache assets, but even that's not necessarily a big issue: you'd mostly inline small assets.
  - TheCycoONE 8y ago
    You can bump that scenario down a layer to http2 push and get the best of both worlds.
  - skohan 8y ago
    It still feels like a hack to work around a problem that should be solved at the protocol level. There's no technical reason that multiple assets couldn't be streamed over a single TCP connection. If it's a common use-case that a number of assets need to be loaded at once to display a web page, then this should be supported by HTTP.
    - jenscow 8y ago
      Great idea. Let's call it HTTP/2. https://en.wikipedia.org/wiki/HTTP/2 https://en.wikipedia.org/wiki/HTTP/2
danesparza 8y ago
Yes. I think it's a bit ironic the OP didn't mention the CPU overhead to essentially go from binary -> ASCII -> binary

_petronius 8y ago

For the first load of the page, sure. But if you're embedding HTML and CSS, then you can't cache it separately, which means having to fetch it all on every request where anything has changed, in addition to the decoding etc on every request.

masklinn 8y ago
That can also be an advantage, if the connection has a high throughput but a high latency (e.g. cellular networks, still), you'd much rather fetch everything in a single request. There's a slight inefficiency in the inability to independently cache assets, but even that's not necessarily a big issue: you'd mostly inline small assets.
- TheCycoONE 8y ago
  You can bump that scenario down a layer to http2 push and get the best of both worlds.
- skohan 8y ago
  It still feels like a hack to work around a problem that should be solved at the protocol level. There's no technical reason that multiple assets couldn't be streamed over a single TCP connection. If it's a common use-case that a number of assets need to be loaded at once to display a web page, then this should be supported by HTTP.
  - jenscow 8y ago
    Great idea. Let's call it HTTP/2. https://en.wikipedia.org/wiki/HTTP/2 https://en.wikipedia.org/wiki/HTTP/2

danesparza 8y ago

Yes. I think it's a bit ironic the OP didn't mention the CPU overhead to essentially go from binary -> ASCII -> binary