SVGO for Animated SVG: A Safe Optimization Configuration

The short answer: treat SVGO as a compiler, not a cleanup button. Keep the editable source, define which IDs and descriptions are public contracts, run an explicit configuration, and test the optimized output in the same embedding context used by production.

Animated SVG is more fragile than a static illustration because seemingly redundant markup may be doing real work. An ID can connect CSS, aria-labelledby, a gradient, a mask, a <use> reference, or JavaScript. A group may be an animation target. A description may provide the graphic’s accessible name. File size matters, but preserving those contracts matters more.

Use two artifacts: source SVG and delivery SVG

Keep the design export or hand-cleaned master in version control. Generate an optimized delivery file from it. Never make the optimized file the only recoverable copy; later plugin changes can otherwise turn a safe experiment into an irreversible edit.

Source SVG

• Purpose: Editing and review
• May contain: Readable names, groups, metadata
• Must prove: The intended geometry and semantics are recoverable

Delivery SVG

• Purpose: Production
• May contain: Minified paths and attributes
• Must prove: All references, animation hooks, labels, and visuals still work

Inventory the contracts before optimizing

Search the SVG and its consuming code for every id, class, data attribute, URL reference, and selector. Record which names are internal and which are used outside the file. Pay special attention to:

• url(#gradient), url(#clip), filters, masks, and markers;
• href="#symbol" and sprite references;
• aria-labelledby and aria-describedby;
• CSS selectors and JavaScript queries;
• timeline targets, motion paths, and test selectors;
• server-rendered components that can appear more than once.

If a name is consumed outside the SVG, it is an API. Renaming it requires a coordinated code change, not an optimizer assumption.

Start with a conservative configuration

SVGO’s default preset includes many transformations, including ID cleanup and removal of descriptions. Disable the risky parts first, establish tests, and enable additional plugins only when the diff is understood.

export default {
  multipass: true,
  plugins: [
    {
      name: 'preset-default',
      params: {
        overrides: {
          cleanupIds: false,
          removeDesc: false
        }
      }
    },
    'sortAttrs'
  ]
};

This is a starting policy, not a universal answer. The right configuration depends on whether the SVG is used as an image, inlined as a component, inserted into a sprite, or manipulated by external code.

Choose one ID strategy

Strategy 1: preserve deliberate public IDs

Use stable, namespaced IDs such as checkout-icon__check. Disable ID minification or preserve the prefixes used by your animation and accessibility contracts. This is the clearest choice when external CSS, scripts, documentation, or tests address individual parts.

Strategy 2: prefix every reusable instance

SVGO’s prefixIds plugin prefixes IDs and class names to reduce collisions when multiple vectors are inlined. Prefer deterministic prefixes based on a component or filename. Random or counter-based prefixes can create server/client mismatches in rendered applications.

{
  name: 'prefixIds',
  params: {
    prefix: 'checkout-icon',
    delim: '__',
    prefixIds: true,
    prefixClassNames: true
  }
}

Do not add prefixing after external selectors have shipped without updating those consumers. The optimizer can keep references inside the SVG synchronized, but it cannot discover selectors stored in another stylesheet, component, test, or CMS field.

Understand cleanupIds before forcing it

The official cleanupIds documentation says the plugin normally backs off when a <script> or <style> element is present. Setting force: true bypasses that safeguard and can be destructive. The same documentation warns that separately optimized inline SVG files may receive predictable short IDs that collide in one document.

Use force only when automated tests prove that every internal and external reference survives. For a component library, predictable namespacing is usually more valuable than saving a few bytes through short IDs.

Plugins that deserve a visual and DOM review

Collapse or remove groups

• Potential failure: Animation target disappears
• Verification: Query every expected target after optimization

Merge paths

• Potential failure: Independent motion parts become one path
• Verification: Replay every sequence and hover state

Convert shapes to paths

• Potential failure: Geometry APIs or authored selectors change
• Verification: Check path-length logic and component code

Remove hidden elements

• Potential failure: A masked or future state vanishes
• Verification: Test all states, not only the first frame

Remove descriptions

• Potential failure: Accessible context is lost
• Verification: Inspect the accessibility tree

Minify styles

• Potential failure: Selector or keyframe behavior changes
• Verification: Inspect computed styles and active animations

Build a before-and-after verification gate

1. Render the source and optimized SVG at the same size and background.
2. Compare the initial, middle, and final animation states.
3. Confirm every URL reference resolves to an element in the same document.
4. Check IDs are unique when the component is rendered twice.
5. Inspect the accessible name and decorative behavior.
6. Enable reduced motion and verify the meaningful static state.
7. Exercise hover, focus, click, replay, and teardown paths.
8. Record byte savings only after all functional checks pass.

For automated checks, parse the optimized file and fail the build when required IDs or references are missing. Use a browser test for actual rendering because XML validity alone cannot prove that CSS, timing, accessibility, and embedding behavior survived.

A practical CI command

npx svgo src/motion/*.svg   --config svgo.config.js   --output dist/motion/

Run that command in continuous integration, then run DOM assertions and visual snapshots against the generated files. Commit the configuration and lock the SVGO version so a dependency update cannot silently change the delivery artifact. Review generated diffs when the version or plugin policy changes.

When should you skip an optimization?

Skip a transformation when its size benefit is smaller than the new maintenance risk. An animation used once may not need aggressive ID minification. A complex illustration may not benefit from merged paths if designers and developers need to address its layers. Production optimization is the smallest artifact that remains understandable, testable, and safe—not the fewest possible bytes.

Quick answers about SVGO and animation

Can SVGO break CSS animations?

Yes. It can rename or remove selectors and targets, collapse groups, convert geometry, or change embedded styles. An explicit configuration and a browser-based regression test are the safeguards.

Should cleanupIds be disabled?

Disable it by default when external code depends on IDs. If all references are internal and tested, configure it deliberately or use deterministic prefixing for reusable inline components.

Should removeDesc stay enabled?

Not for an informative SVG whose description contributes to accessibility. Decide the semantic model first; do not let an optimizer choose it.

Is multipass always better?

Multipass can find additional savings, but every pass still has to satisfy the same visual, semantic, and animation checks. More transformation is not automatically safer.

Put optimization inside the production workflow

Optimization belongs between source inspection and animation verification—not at the end as a blind minification step. Use the broader SVG animation production workflow to connect this configuration with embedding, accessibility, profiling, and release evidence.