When to Turn on SVGO’s Multipass: A Practical Guide

Balancing Build Speed and SVG Size

Modern front‑end pipelines often hit a classic optimization dilemma: should we spend extra seconds during a build to shave a few kilobytes off each SVG, or keep the build lean and accept a slightly larger asset? SVGs are frequently the largest static files in a web bundle, and even a 5 % reduction can improve page load times and data usage for mobile users. SVGO, the de‑facto SVG optimizer, offers a multipass mode that can deliver that extra size reduction, but it also increases the CPU load of the build. The question is: when is the trade‑off justified?

What Is Multipass?

SVGO’s default operation runs its plugin chain once, then writes the result. In multipass mode the optimizer repeats the plugin pass until the output stops changing. Because some plugins (e.g., cleanupIds, removeViewBox) make incremental changes that only become effective after a previous pass, running them multiple times can squeeze out an extra 10‑15 % of size on complex assets.

Multipass is deterministic: the same input will always produce the same final file. However, each additional pass can reorder nodes (the order of <path> elements, for example), which may affect downstream consumers that rely on stable ordering.

Enabling Multipass

CLI Flags

# Single‑pass (default)
svgo -p 1 input.svg -o out1.svg

# Multipass mode
svgo -m input.svg -o out2.svg

The -m flag turns on multipass. The -p flag explicitly sets the number of passes; using 1 shows the baseline for comparison.

Configuration File

When using a configuration file (e.g., .svgo.yml), add the multipass key:

multipass: true
plugins:
  - removeDoctype
  - cleanupAttrs
  - cleanupIDs
  - removeViewBox

All other plugin settings remain unchanged, so you can combine multipass with your usual optimization strategy.

Worked Example

Suppose we have an SVG that contains 200 <path> elements, each with unique IDs. We want to see the effect of multipass on size and build time.

1. Run a single pass and capture the output size:

   svgo -p 1 complex.svg -o single.svg
   stat -c %s single.svg
   

2. Run multipass and capture the output size:

   svgo -m complex.svg -o multi.svg
   stat -c %s multi.svg
   

3. Compare the two files:

   diff -u single.svg multi.svg | grep -E '^\+|^\-'
   

   Look for differences in node order or removed attributes.
4. Measure processing time:

   time svgo -p 1 complex.svg -o single.svg
   

   time svgo -m complex.svg -o multi.svg
   

Typical results show a 12‑15 % size reduction with a 2‑3× increase in CPU time for this file. The actual numbers vary with SVG complexity.

Trade‑offs and Limitations

• Build Time: Multipass adds roughly one extra pass per plugin that can benefit from repeated execution. Large projects with many SVGs may see noticeable slowdowns in CI pipelines.
• Cache Stability: Because multipass can reorder elements, cache keys that depend on file content may change. If you use a content‑hashing strategy, consider excluding multipass output from the hash or regenerating the hash after optimization.
• Plugin Compatibility: Custom or third‑party plugins that maintain internal state across passes may produce inconsistent results or errors. Test your plugin stack before enabling multipass.
• Marginal Gains on Small SVGs: For assets that are already lean or very small, the size benefit may be <1 %. In those cases, the extra processing time is not worth it.
• CSS/JS Selectors: If your code relies on specific IDs or element order (e.g., #logo path:nth-child(3)), multipass may break those selectors. Use cleanupIDs with the prefix option to avoid collisions instead.

When to Turn It On

Use multipass in the following scenarios:

• Production Builds: When file size directly impacts performance metrics and you can afford a few extra seconds per asset.
• High‑Complexity SVGs: Icons or illustrations with many paths, gradients, and embedded metadata.
• Controlled Build Environments: CI/CD pipelines with ample CPU resources and time budgets.

Skip multipass when:

• You run a fast, incremental build for local development.
• Your SVGs are already optimized or very small.
• Cache stability or element order is critical for downstream tooling.

Actionable Checklist

1. Run svgo -v to confirm your SVGO version supports the -m flag.
2. Benchmark a representative SVG set with and without multipass to quantify size vs. time trade‑off.
3. Update your .svgo.yml with multipass: true only if the benchmark shows a meaningful benefit.
4. After enabling, verify that any CSS selectors or scripts that rely on element order still work.
5. In CI, monitor build times and consider throttling multipass for very large assets or running it only in release branches.

By following this approach, you can make an informed decision about whether SVGO’s multipass mode should be part of your build pipeline.