You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: _posts/2024-09-01-svg-ccc.md
+11-8
Original file line number
Diff line number
Diff line change
@@ -27,13 +27,15 @@ SVG support is now good enough that you can avoid a lot of said tradeoffs by usi
27
27
## Background and alternatives
28
28
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:
29
29
30
-
30
+
31
31
32
32
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.
33
33
## Enter AVIF
34
34
In exploring this technique and optimizing further, I noticed that we now can pretty broadly [just use AVIF](https://caniuse.com/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.
35
35
36
-
I discovered that for this particular image (with just a little text on it) a well compressed AVIF basically 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 even better at getting the size down. For images with more complex graphics, or higher resolution needs, SVG compositing an AVIF and WebP can be a great solution.
36
+
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.
37
+
38
+
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.
37
39
38
40
But...
39
41
## A match made in heaven: AVIF + vectors
@@ -46,25 +48,26 @@ Note: OG is "OpenGraph" support. See section in [Tradeoffs](#tradeoffs). Late I
46
48
|-|-|-|
47
49
| PNG | 627 KB | X | Very high quality, larger file |[](/assets/img/posts/svg-ccc/original.png)|
| 🔥 **AVIF lossy (25%)**| 15 KB || Great size, okay quality. Good enough for many images or mobile generally |[](/assets/img/posts/svg-ccc/25.avif)|
50
-
| JPG (0%) | 21 KB | X |Visible artifacts, still not as small as the lossy AVIF |[](/assets/img/posts/svg-ccc/0.jpg)|
51
+
| 🔥 **AVIF lossy (25%)**| 15 KB || Great size, pretty good quality. Good enough for many images or mobile generally |[](/assets/img/posts/svg-ccc/25.avif)|
52
+
| JPG (0%) | 21 KB | X |Poor quality, visible artifacts, still not as small as the lossy AVIF |[](/assets/img/posts/svg-ccc/0.jpg)|
51
53
| JPG (25%)| 51 KB | X | Same as above, just a 2.5x file with *slightly* fewer artifacts |[](/assets/img/posts/svg-ccc/25.jpg)|
52
54
| SVG + AVIF + PNG | 65 KB || Tiny quality improvement over plain AVIF, at much larger size. |[](/assets/img/posts/svg-ccc/composite-png.svg)|
53
55
| SVG + AVIF + WebP | 55 KB || Similar quality, slightly better file size. Images with more graphics than photo will likely show more improvement |[](/assets/img/posts/svg-ccc/composite-webp.svg)|
54
-
| 🔥 SVG + AVIF + vector| 36 KB || Best quality. Razor crisp lines with zero artifacts at a decent size |[](/assets/img/posts/svg-ccc/composite.svg)|
56
+
| 🔥 SVG vectors + AVIF| 36 KB || Best quality. Razor crisp lines with zero artifacts at a decent size |[](/assets/img/posts/svg-ccc/composite.svg)|
55
57
56
58
57
59
## Tradeoffs
58
-
### No progressive rendering
60
+
### No progressive rendering (AVIF)
59
61
Unlike JPGs, AVIFs don't do [progressive rendering](https://docs.imgix.com/apis/rendering/format/jpg-progressive) 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.
60
-
### Missing OpenGraph
62
+
### Missing OpenGraph (AVIF & SVG)
61
63
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.
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.
64
66
### Missing tooling support (AVIF + composite with AVIF)
65
67
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.
66
-
### Compression time
68
+
### Compression time (AVIF)
67
69
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+](https://apps.apple.com/us/app/image-tool/id1524216218?mt=12) to be well worth the $8 when trying to do a lot of images with different settings.
70
+
68
71
## Final approach
69
72
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](https://www.svgviewer.dev), which has been super helpful through the whole process of experimenting wiah all these possibilities.
0 commit comments