SVG files too big: svgo and manual cleanup

In an SVG exported straight from a design tool, often half the bytes are editor metadata, comments, hidden layers and excessive decimal precision. Trimming is not optional: an icon that appears dozens of times in a list multiplies every extra kilobyte by that count.

Contents

• First, see what is actually in the file
• What svgo does, and which plugins to be careful with
• Three high-yield manual fixes
• Two things beyond compression
• How to verify before and after

First, see what is actually in the file

Open it in a text editor. Common redundancy includes <metadata>, <!-- comments -->, editor namespaces, unused <defs>, transform wrapper layers, and decimals beyond six places. A line icon above 2KB almost always has room; large illustrations above a few dozen KB are worth processing too.

• Delete <metadata> and comments
• Delete unreferenced <defs> / <clipPath>
• Merge nodes that could be a single path
• Round decimals to one or two places

What svgo does, and which plugins to be careful with

svgo is the community-standard SVG optimiser. By default it strips comments, removes metadata, merges paths, compresses numbers and shortens colours. A few behaviours need attention: removeViewBox breaks responsive scaling and should normally be disabled; cleanupIDs can cause id collisions when several SVGs are inlined into one page, so prefix them; convertShapeToPath makes later editing harder.

• Keep viewBox, or the icon cannot scale proportionally
• Prefix ids when inlining multiple SVGs to avoid collisions
• Compare rendered before/after screenshots, not just byte counts
• Put optimisation in the build, not a manual step before launch

Three high-yield manual fixes

(1) Remove every hard-coded fill / stroke and switch to currentColor. (2) Fold repeated transform="translate(...)" into the path coordinates. (3) If one page needs several icons, consider one SVG sprite referenced with <use> to cut request count.

<!-- sprite 用法示意 -->
<svg style="display:none"><symbol id="i-close" viewBox="0 0 24 24">
  <path d="M6 6l12 12M18 6L6 18"/></symbol></svg>
<svg width="24" height="24"><use href="#i-close"/></svg>

Two things beyond compression

Set cache headers plus gzip / brotli for static SVG, and add loading="lazy" to icons below the fold. Reducing bytes and reducing requests have to happen together; svgo alone will not fix a first screen stacked with large illustrations.

How to verify before and after

Do not just watch the number drop. After optimising, do three things: render before and after side by side at the same size and check for shifted strokes or sharper corners; re-import into the design tool and confirm it is still editable; finally open it in the target browsers, especially files using <use> or clipPath. Some svgo plugins merge paths that look “equivalent” and produce subtle differences in older rendering engines. Putting this check into the build is more reliable than eyeballing before each release.

• Side-by-side render to catch shifts and corner changes
• Re-import into the design tool to confirm editability
• Open once in the target browsers
• Script the verification instead of sampling by eye

FAQ

← All SVG guides　·　Licence and usage FAQ →