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

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.

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.

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.

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.

There are valid use cases.

http://davidbcalhoun.com/2011/when-to-base64-encode-images-a...

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.

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.

base64 encoding increases the size of the file.

For that image I would prefer to use inline SVG...

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.

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.

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.

You can do it with fonts too.

Bad why?