Drop #224 (2023-03-21): How Low Can You Go?

svgo/pngcrush; TinyVG; (Docker)Slim; vim/gzexe

Living and enjoying most of my recreational activities in Maine means that I regularly get to experience one of the “joys” other humans in developing nations, or other rural areas do: extra horrible internet connections, especially when mobile. As such, I am a bit more critical of bloated websites and apps that seem to assume everyone has superfast and consistent network connections.

I also come from the early days of modern technology, where everything associated with a “computing session” was very conscious of how little RAM and spindle-based drive space we had to work with.

Younger-me, insta-dropped into the world today, would likely marvel at the fact that present-day-me has a thin, glowing, palm-sized rectangle with an embarrassing excess number of gigabytes of RAM/SSD, and can stream 4K video to it without any wires. Truth be told, I'm in that fortunate “middle space” where I remember the “old”, but also can wield the “new”, which makes every new advancement pretty magical…except when the conditions in the first paragraph manifest.

So, today's drop is a tad self-serving. Two of the resources

¹

are associated with making bitmap and SVG images smaller, so they might actually load the next time I'm in a terrible internet zone. The third one will be of use if you, like me, have poor personal Docker hygiene. I tossed in a fourth section on two command line compression “hacks” that I don't see often referenced, but are kind of cool.

svgo

Photo by Annie Spratt on Unsplash

We're finally hitting the digital Overton window point where SVG is becoming the default majority image type for websites and applications. That's wonderful for our eyes, but we're also still at a stage when far too many SVG files are bloated, complex beasts.

Take this example from Wikipedias “large SVGs” topic. That beastie is 101,036,085 bytes! I could likely finish one of the longer trails at Acadia National Park before that thing would load into my iOS Safari browser

²

.

SVGs are XML files, so they are, by default, pretty verbose to begin with. Layer on the cruft that Adobe shoves in them, and toss in the fact that many are (poorly) programmatically constructed these days, and soon that XML tag verbosity begins to add up.

We need not act like the SVG monsters we are, though, thanks to svgo.

svgo is a javascript CLI and library that optimizes SVG files (‘tis what the o stands for), reducing their size without sacrificing quality. It does this by removing unnecessary information, minifying the code, and applying various optimizations to the SVG structure. The result is a smaller, cleaner, and more efficient SVG file that can significantly improve an app or website's performance.

It has some pretty cool options, too; some of which aren't only related to optimization:

-v, --version              output the version number
-i, --input <INPUT...>     Input files, "-" for STDIN
-s, --string <STRING>      Input SVG data string
-f, --folder <FOLDER>      Input folder, optimize and rewrite all *.svg files
-o, --output <OUTPUT...>   Output file or folder (by default the same as the input), "-" for STDOUT
-p, --precision <INTEGER>  Set number of digits in the fractional part, overrides plugins params
--config <CONFIG>          Custom config file, only .js is supported
--datauri <FORMAT>         Output as Data URI string (base64), URI encoded (enc) or unencoded (unenc)
--multipass                Pass over SVGs multiple times to ensure all optimizations are applied
--pretty                   Make SVG pretty printed
--indent <INTEGER>         Indent number when pretty printing SVGs
--eol <EOL>                Line break to use when outputting SVG: lf, crlf. If unspecified, uses platform default.
--final-newline            Ensure SVG ends with a line break
-r, --recursive            Use with '--folder'. Optimizes *.svg files in folders recursively.
--exclude <PATTERN...>     Use with '--folder'. Exclude files matching regular expression pattern.
-q, --quiet                Only output error messages, not regular status messages
--show-plugins             Show available plugins and exit
--no-color                 Output plain text without color
-h, --help                 display help for command

It was able to take that Wikipedia example map SVG and reduce it to 18,555,093 bytes (~80% reduction).

The utility also has a rich plugin system, that also makes it a kind of Swiss Army knife for SVG processing. Finally, svgo can help ensure that your SVG files are compatible with a wider range of browsers and devices by removing or converting problematic elements and attributes.

A related utility on the bitmap side of things is pngcrush (GH). It focuses on PNG IDAT streams, and tries various compression levels and PNG filter methods on them to reduce the overall file size. It also can be used to remove unwanted ancillary chunks, or to add certain chunks including gAMA, tRNS, iCCP, and textual chunks (all those acronyms are explained at the URL for “IDAT streams”, above, points to).

Not only that, but it has so many settable and tweakable options, that I'll leave to y'all to explore.

TinyVG

SVG's are great! Except when they're not (as partly demonstrated in the first section). What if I told you there was a better option that provides the crispness of vector graphics?

(Oh, you probably want me to actually tell you what it is.)

TinyVG (GH) is a new, binary vector graphics format that supports the SVG features the vast majority of SVG files solely use.

It has impressive benchmarks, a dead simple specification, browser and CLI renderers, and a library that works in your fav language.

I'm going to kick the tyres of this in one of my upcoming WebR Experiments and report back.

(Docker)Slim

Slim(toolkit) (formerly DockerSlim) is a suite of tools (build, xray, lint, debug) for optimizing and securing containers by understanding how the application works and what it needs using various analysis techniques. It throws away what you don't need, which also can reduce the container's attack surface.

There are way more benchmarks at the GH repo, but this short list is impressive enough:

• ubuntu:14.04 - 432MB => 14MB (minified by 30.85X)

• debian:jessie - 406MB => 25.1MB (minified by 16.21X)

• node:alpine - 66.7MB => 34.7MB (minified by 1.92X)

• node:distroless - 72.7MB => 39.7MB (minified by 1.83X)

The section banner image outlines how it works.

My only detraction is that this just further encourages my poor local Docker hygiene, since I don't actually need to clean up things I don't use anymore to free up disk space.

vim/gzexe

Photo by Dan Smedley on Unsplash

Two quick tips/tricks:

vim some-archive.tar.gz

will display a menu of the filesystem in the gzip'd tar archive and let you select a file to edit. You edit the file, and it goes back in the gzip'd tarball.

gzexe

Did you know that you can compress macOS/linux executables in place and have them automatically uncompress and execute when you run them? It slows things down a bit (not much, though, given modern CPUs and fast SSDs), but can be handy if you're trying to squeeze every ounce of space in an existing drive.

Taking a literal page out of the manual:

For example, if you execute gzexe /usr/bin/gdb it will create the following two files:

-rwxr-xr-x  1 root root 1026675 Jun  7 13:53 /usr/bin/gdb
-rwxr-xr-x  1 root root 2304524 May 30 13:02 /usr/bin/gdb~

/usr/bin/gdb~ is the original file and /usr/bin/gdb is the self-uncompressing executable file.

You can remove /usr/bin/gdb~ once you are sure that /usr/bin/gdb works properly.

FIN

May your files be short, and your days be long. ☮

1. Technically three, since one section has two utilities.

2. Some spots in Acadia still have notoriously horrible cell coverage, which, tbh, I think is actually a good thing.

#docker #svgo #pngcrush #dockerslim #slimtoolkit #slim #tinysvg #compression