Discover more from hrbrmstr's Daily Drop
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 resourcesare 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.
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.
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.
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.)
I'm going to kick the tyres of this in one of my upcoming WebR Experiments and report back.
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.
Two quick tips/tricks:
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.
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.
May your files be short, and your days be long. ☮
Technically three, since one section has two utilities.
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