SVGO Multipass: When More Passes Mean Better Compression

Why Do Some SVGs Still Shrink After the First Pass?

When you run SVGO on a complex icon set you often see a noticeable size drop in the first run, but a second run sometimes yields a few more kilobytes of savings. That extra compression comes from multipass – a loop that re‑applies the full plugin suite until the output stabilises. If you’re looking to squeeze every byte, understanding and enabling multipass is the next logical step.

The Multipass Loop Explained

SVGO’s core optimisation pipeline is a sequence of plugins (e.g., removeViewBox, cleanupIDs, convertColors). In a single‑pass run, each plugin touches the SVG once and the process ends. With multipass: true, SVGO repeats that entire sequence until one of two conditions is met:

• The file size change between consecutive passes falls below a configurable threshold (default 0.1 %).
• A maximum iteration count is reached (default 4).

Because some optimisations only become possible after earlier passes have removed or altered elements, the loop can uncover savings that a single iteration misses.

How to Turn It On

Enabling multipass is a one‑liner in both configuration files and the CLI. Below is a minimal .svgo.yml that demonstrates the setting:

multipass: true
# optional: tweak the thresholds
# multipass:
#   iterations: 10
#   threshold: 0.01

On the command line you can pass the same flag:

svgo --multipass input.svg -o output.svg

Note: The flag is recognised by both the legacy and the new preset‑default plugin sets. No other configuration change is required.

Worked Example: Compressing a 100 KB Icon

Consider a 100 KB SVG file with many nested <g> groups and duplicate fill attributes. In a CI pipeline you might run:

# Single‑pass run
svgo input.svg -o out-single.svg
# Multipass run
svgo --multipass input.svg -o out-multi.svg

Typical observations:

• Size: single‑pass 95 KB → multipass 88 KB (≈7 % reduction)
• Build time: single‑pass 0.3 s → multipass 1.5 s (≈5× slower)

To verify functional equivalence, open both files in an SVG viewer or run diff on the text. The visual output should match, and any CSS classes or IDs used by your application must still be present unless you explicitly disabled plugins that touch them.

Trade‑Offs and Caveats

• CPU & Time – Each pass consumes CPU and adds to build times. For large projects or CI environments, monitor the impact and consider limiting iterations.
• Determinism – Within a given SVGO release, the output is deterministic. Across releases, small differences can appear because plugin logic may evolve.
• Side Effects – Plugins like cleanupIDs remove IDs that external scripts may reference. If your SVGs are used with JavaScript, keep cleanupIDs: false or whitelist necessary IDs.
• Iteration Limits – The default 4‑iteration cap may stop early for very large files. Adjust multipass.iterations if you need deeper optimisation.
• Test Strategy – Avoid binary equality tests. Instead, assert that the file size is below a threshold or that a diff tool shows only benign changes.

Actionable Checklist for Your Project

1. Benchmark – Run SVGO with and without multipass on a representative SVG set and record time and size.
2. Configure – Add multipass: true to your .svgo.yml or use the CLI flag.
3. Test – In your CI pipeline, add a step that asserts the output size is at least 10 % smaller than the baseline.
4. Monitor – Track build duration; if it grows beyond acceptable limits, reduce iterations or disable multipass for the largest files.
5. Validate – For SVGs that interact with scripts, run a visual regression test to ensure behaviour hasn’t changed.

By following this workflow, you can harness the full power of SVGO’s multipass optimisation without compromising build performance or application correctness.