8 ms·

Is this image inlining thing something new? Am I reading it correctly that the images are encoded in base64 and delivered as html? Surely this is a bad idea...

Is this image inlining thing something new? Am I reading it correctly that the images are encoded in base64 and delivered as html? Surely this is a bad idea... no?

Sirikon 10y ago
base64 encoding increases the size of the file. For that image I would prefer to use inline SVG...
- dahart 10y ago
  Indeed, this particular image is 3.5k of PNG, I'm certain it could easily be well under 1k as SVG.
  - Eric_WVGG 10y ago
    not to mention retina-smoove
chriswarbo 10y ago
Other reasons to embed images using base64 are to have pages work standalone, to reduce complexity (no need to keep pages and associated resources in sync) and increase locality (things are defined where they're used). These probably aren't particularly important for most sites, but it's something I do on my personal site ( chriswarbo.net ) since I care more about ease of maintenance than load times.
draw_down 10y ago
Bad why?
- pmarreck 10y ago
  because base64 encoding expands the size of a binary, presumably
creshal 10y ago
> Is this image inlining thing something new? No, it's been around since forever. Just not used terribly often. > Am I reading it correctly that the images are encoded in base64 and delivered as html? Surely this is a bad idea... no? It depends. Making a new request to fetch the image always has overhead. Whether that overhead is bigger or smaller than the overhead of base64-encoding the image depends on: • file size (naturally) • file compressibility: The difference isn't as pronounced after gzipping everything, especially if the source data is somewhat compressible • protocol: http2 allows a correctly configured server to push attached data with the original request, so no second request is needed. Even without server push, http2's multiplexing will reduce the overhead drastically compared to plain HTTP1.1 or the worst case, HTTPS1.1 to a different domain. The latter requires a full TLS handshake, and that's what, >30kb data exchanged if you have more than one CA certificate in the chain? That's a lot of image data.
- sillysaurus3 10y ago
  Completely offtopic, but how do you type •? I like it.
  - hkmurakami 10y ago
    I personally type it with a unicode keyboard input (ex: Japanese in my case)　 ex: "・"
  - maxerickson 10y ago
    It's system dependent. On windows you can do alt+numpad 2022 On whatever is handling input for this XFCE system, control+shift+U 2022+Enter types it.
    - creshal 10y ago
      And since I'm lazy, I put it on AltGr+, with xmodmap.
  - erichocean 10y ago
    • is Option-8 on a Mac.
oneloop 10y ago
Depends. If you consider that in each request a big chunk of time is spent one opening the connection, and that you can even start opening the connection to download the linked picture after you have received the response from the first hit, then maybe it's not a bad idea. It's one round trip worth of time that you shame off the total loading time. However, if the image is very large, it will make the initial request large as well. I would only use this for images that are small and above the fold.
nfriedly 10y ago
I think it depends on the image size and use case. For small images where the round trip time of an extra request would make a bigger impact than the file size, inlining them might make sense. Especially on mobile where latency tends to be higher.
ralusek 10y ago
There is an increase in size to base64 encode, in addition to what I assume is the lost capability to cache images, as well as load them intelligently.
Confiks 10y ago
No, image inlining is quite old, and base64 is not a very efficient encoding, although gzip might make up for the ~1/3 increase in size. You'd think HTTP/2 server push would stand for this, but I can imagine inlining is still a bit faster.
Numberwang 10y ago
You can do it with fonts too.
- cousin_it 10y ago
  Sounds too. <audio src="data:audio/mp3;base64,..." /> Probably videos as well, but I haven't tried it.
silverwind 10y ago
Base64-encoding induces a factor 1.333 size increase of the byte stream, so it's likely not worth it if the site is served on HTTP2. To get exact figures, one would of course have to calculate the size of the additional TCP packet(s) and HTTP headers.
h4nkoslo 10y ago
There are valid use cases. http://davidbcalhoun.com/2011/when-to-base64-encode-images-and-when-not-to/ http://davidbcalhoun.com/2011/when-to-base64-encode-images-a...
pmarreck 10y ago
I think it depends on how much of an image we're talking about. If it's small, the overhead from base64'ing it (if the page is gzipped) is lower than the overhead of opening a new HTTP connection just to retrieve that one image.
dredmorbius 10y ago
Keep in mind that you can inline images as SVG as well, which often results in smaller images, included with your HTML or CSS requests. Not all browsers support SVG, and not all support all properties, but those that do give some pretty good results.
- kensign 10y ago
  pretty much every standard browser that is in use supports SVG. I've been using it for years.
HugoDaniel 10y ago
The biggest problem with inlining images (imo bigger than the base64 size increase) is that when you change something (like a word in the text of the page) you are forcing your users a full reload of the page (images included). Most of these performance tips assume things won't change. We know life doesn't work that way.

Is this image inlining thing something new? Am I reading it correctly that the images are encoded in base64 and delivered as html? Surely this is a bad idea... no?

Sirikon 10y ago

base64 encoding increases the size of the file. For that image I would prefer to use inline SVG...

dahart 10y ago
Indeed, this particular image is 3.5k of PNG, I'm certain it could easily be well under 1k as SVG.
- Eric_WVGG 10y ago
  not to mention retina-smoove

chriswarbo 10y ago

Other reasons to embed images using base64 are to have pages work standalone, to reduce complexity (no need to keep pages and associated resources in sync) and increase locality (things are defined where they're used). These probably aren't particularly important for most sites, but it's something I do on my personal site ( chriswarbo.net ) since I care more about ease of maintenance than load times.

draw_down 10y ago

Bad why?

pmarreck 10y ago
because base64 encoding expands the size of a binary, presumably

creshal 10y ago

> Is this image inlining thing something new? No, it's been around since forever. Just not used terribly often. > Am I reading it correctly that the images are encoded in base64 and delivered as html? Surely this is a bad idea... no? It depends. Making a new request to fetch the image always has overhead. Whether that overhead is bigger or smaller than the overhead of base64-encoding the image depends on: • file size (naturally) • file compressibility: The difference isn't as pronounced after gzipping everything, especially if the source data is somewhat compressible • protocol: http2 allows a correctly configured server to push attached data with the original request, so no second request is needed. Even without server push, http2's multiplexing will reduce the overhead drastically compared to plain HTTP1.1 or the worst case, HTTPS1.1 to a different domain. The latter requires a full TLS handshake, and that's what, >30kb data exchanged if you have more than one CA certificate in the chain? That's a lot of image data.

sillysaurus3 10y ago
Completely offtopic, but how do you type •? I like it.
- hkmurakami 10y ago
  I personally type it with a unicode keyboard input (ex: Japanese in my case)　 ex: "・"
- maxerickson 10y ago
  It's system dependent. On windows you can do alt+numpad 2022 On whatever is handling input for this XFCE system, control+shift+U 2022+Enter types it.
  - creshal 10y ago
    And since I'm lazy, I put it on AltGr+, with xmodmap.
- erichocean 10y ago
  • is Option-8 on a Mac.

oneloop 10y ago

Depends. If you consider that in each request a big chunk of time is spent one opening the connection, and that you can even start opening the connection to download the linked picture after you have received the response from the first hit, then maybe it's not a bad idea. It's one round trip worth of time that you shame off the total loading time. However, if the image is very large, it will make the initial request large as well. I would only use this for images that are small and above the fold.

nfriedly 10y ago

I think it depends on the image size and use case. For small images where the round trip time of an extra request would make a bigger impact than the file size, inlining them might make sense. Especially on mobile where latency tends to be higher.

ralusek 10y ago

There is an increase in size to base64 encode, in addition to what I assume is the lost capability to cache images, as well as load them intelligently.

Confiks 10y ago

No, image inlining is quite old, and base64 is not a very efficient encoding, although gzip might make up for the ~1/3 increase in size. You'd think HTTP/2 server push would stand for this, but I can imagine inlining is still a bit faster.

Numberwang 10y ago

You can do it with fonts too.

cousin_it 10y ago
Sounds too. <audio src="data:audio/mp3;base64,..." /> Probably videos as well, but I haven't tried it.

silverwind 10y ago

Base64-encoding induces a factor 1.333 size increase of the byte stream, so it's likely not worth it if the site is served on HTTP2. To get exact figures, one would of course have to calculate the size of the additional TCP packet(s) and HTTP headers.

h4nkoslo 10y ago

There are valid use cases. http://davidbcalhoun.com/2011/when-to-base64-encode-images-and-when-not-to/ http://davidbcalhoun.com/2011/when-to-base64-encode-images-a...

pmarreck 10y ago

I think it depends on how much of an image we're talking about. If it's small, the overhead from base64'ing it (if the page is gzipped) is lower than the overhead of opening a new HTTP connection just to retrieve that one image.

dredmorbius 10y ago

Keep in mind that you can inline images as SVG as well, which often results in smaller images, included with your HTML or CSS requests. Not all browsers support SVG, and not all support all properties, but those that do give some pretty good results.

kensign 10y ago
pretty much every standard browser that is in use supports SVG. I've been using it for years.

HugoDaniel 10y ago

The biggest problem with inlining images (imo bigger than the base64 size increase) is that when you change something (like a word in the text of the page) you are forcing your users a full reload of the page (images included). Most of these performance tips assume things won't change. We know life doesn't work that way.