The holy grail of image formats: SVG cross-codec-compilation & AVIF

Last modified at:
The holy grail of image formats: SVG cross-codec-compilation & AVIF

Photos and text or diagrams in the same image file, at a small size, without losing cripsness

With essentially all browsers being some variation of evergreen now, we can start tossing out old assumptions, like how stark the tradeoff is between filesize, image quality, and features (like transparency) in image compression, especially in images that mix photos with other graphics (like lineart or text).

SVG Compositing

SVG support is now good enough that you can avoid a lot of said tradeoffs by using an SVG as a container for two images with different codecs/formats. The images are then base64 data encoded directly into the same file. This allows you to optimize your graphics separately from your photos, which overall makes for a much smaller size, at essentially equivalent quality, in a single file. I doubt I’m anywhere near the first to notice this, but it should be talked about more widely, because it’s groundbreaking.

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
  <image xlink:href="data:image/png;base64,[DATA]"/>
  <image xlink:href="data:image/jpg;base64,[DATA]"/>

Background and alternatives

For example of why you’d want to do this, here are the artifacts that can form around the text of this post’s header image when you compress the whole file down to a reasonably sized jpg:

The text "SVG" with glitchy jpg artifacts around it

You could compress the text and the background separately, of course, and layer them in CSS. This has some tradeoffs of it’s own, such as requiring CSS that can be tricky to get just right in responsive layouts; requiring additional requests to the server, which is worse for optimizing mobile load time; and overall not being easy to maintain (or fitting in most peoples content management approaches). And then you will still need a single image version for things like the sharing/OpenGraph tile, if it’s the main image for the page.

Enter AVIF

In exploring this technique and optimizing further, I noticed that we now can pretty broadly just use AVIF. AVIF is an incredible format that greatly reduces artifacts and other compression problems, even when smaller than a JPG (and thus a fraction of the size of corresponding PNGs). And you can then combine SVG compositing and AVIF for very high quality images, at a fraction of the size.

Though, I discovered that for this particular image (with just a little text on it) a well-compressed AVIF beats out even the SVG compositing with a PNG. This isn’t too surprising, once you realize how great AVIF is. The base64 encoding has a cost, and the composited form still has to have a similar (if even more well compressed) AVIF as well as the data for the PNG.

Swapping in WebP for the PNG works better at getting the size down. For images with more complex graphics, or higher resolution needs, SVG compositing an AVIF and WebP could be a great solution.

But…

A match made in heaven: AVIF + vectors

If you are trying to get the crispest lines and overall best graphical art, you shouldn’t even be using a raster format anyway. And since we’re already working with SVGs you might as well include the vectors in the file we were using to composite images. It’s debatable at this point if that’s “compositing” or just “inlining a photo into an SVG”. Either way, for a small size penalty you can have an even better quality image than the large PNG we were using as our baseline.

Comparison table

Note: OG is “OpenGraph” support. See section in Tradeoffs. Late I may redo this with a larger image with more graphics in it to better demonstrate the tradeoffs.

FormatFilesizeOGNotesImage (link to full-size)
PNG627 KBXVery high quality, larger file
AVIF lossless413 KB Same quality; 30% size reduction
🔥 AVIF lossy (25%)15 KB Great size, pretty good quality. Good enough for many images or mobile generally
JPG (0%)21 KBXPoor quality, visible artifacts, still not as small as the lossy AVIF
JPG (25%)51 KBXSame as above, just a 2.5x file with slightly fewer artifacts
SVG + AVIF + PNG65 KB Tiny quality improvement over plain AVIF, at much larger size.
SVG + AVIF + WebP55 KB Similar quality, slightly better file size. Images with more graphics than photo will likely show more improvement
🔥 SVG vectors + AVIF36 KB Best quality. Razor crisp lines with zero artifacts at a decent size

Tradeoffs

No progressive rendering (AVIF)

Unlike JPGs, AVIFs don’t do progressive rendering so they won’t fill in until they are completely downloaded. I feel like the much smaller overall size more than negates that, since the whole image might download before the JPG even got to its first pass anyway.

Missing OpenGraph (AVIF & SVG)

Neither AVIFs or composite SVG work everywhere you can share an OpenGraph/preview tile images (and that’s not super easy to track, unlike browser support, since it’s based on every individual site or apps support). If you care enough about optimizing your site’s images to be reading this post, you are already used to having different sizes and formats for different uses. And since the OpenGraph tile image doesn’t actually load on your site, you can just use your default large png that you were likely already using for your largest responsive layout.

Difficulty managing multiple responsive images (SVG composite)

Using an inlined image file in an SVG makes it trickier to autogenerate different sizes for responsive layouts. You could write some custom tooling to extract the image, resize it, and make a new SVG. But much like the progressive rendering, I think this is somewhat moot. If you can just make all your images better quality at a fraction of the size, there is less need for using different images per layout anyway.

Missing tooling support (AVIF + composite with AVIF)

This will likely get better over time. To make an SVG composite I had to export the SVG from Figma with the original PNG in it, then manually swap in the compressed AVIF’s data. You may need to compress your AVIFs separate anyway, due to the next point.

Compression time (AVIF)

Running the highest compression settings on AVIF can be slow. This will get better as computers get faster. You may end up wanting some automated tooling around producing your AVIFs to manage this, or you may want to hand-tune them instead if you are only doing a few at a time anyway. Either way you probably want a decent standalone compressor. I found ImageTool+ to be well worth the $8 when trying to do a lot of images with different settings.

Final approach

Below is the gist of what I ended up on for my ideal composite SVG. The font, gradient, and overlay are all done in SVG making it even easier to swap in different photos. The SVG was autogenerated by Figma then cleaned up a bit via svgviewer.dev, which has been super helpful through the whole process of experimenting wiah all these possibilities.

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="918" height="560" fill="none" viewBox="0 0 918 560">
  <g clip-path="url(#a)">
    <path fill="url(#b)" d="M-134 0H918v560H-134z"/>
    <path fill="url(#c)" d="M423 0h496v560H423z" shape-rendering="crispEdges" style="mix-blend-mode:overlay"/>
    <use xlink:href="#d"/>
  </g>
  <defs>
    <linearGradient id="b" x1="-355.072" x2="190.854" y1="369.927" y2="-569.885" gradientUnits="userSpaceOnUse">
      <stop stop-color="#B45BCF"/>
      <stop offset="1" stop-color="#6E57FF"/>
    </linearGradient>
    <clipPath id="a">
      <rect width="918" height="560" fill="#fff" rx="7"/>
    </clipPath>
    <pattern id="c" width="1" height="1" patternContentUnits="objectBoundingBox">
      <use xlink:href="#e" transform="matrix(.00204 0 0 .00184 -.013 -.03)"/>
    </pattern>
    <path id="d" fill="#fff" d="[PATHDATA]"/>
    <image id="e" width="496" height="560" xlink:href="data:image/avif;base64,[IMGDATA]"/>
  </defs>
</svg>

© 2024. No rights reserved.