How to building an svg compression strategy for maximum web performance
- Step 1Baseline the transfer size — In Chrome DevTools Network tab, filter to SVG and read the transferred (compressed) Size column for your key SVGs. That's your real starting point — note it. For an isolated per-file baseline, drop each SVG on the Compression Estimator and record the gzip figure.
- Step 2Strip editor metadata — Run raw Figma/Illustrator/Inkscape exports through the Metadata Scrubber to remove
<metadata>, editor namespaces,<title>/<desc>, and tool signatures. Re-estimate — on bloated exports this alone can be a big chunk of the raw size. - Step 3Tune coordinate precision — Use the Precision Tuner at 1-2 decimal places. Sub-pixel precision rarely matters visually but inflates path data. Re-estimate to see the gzip impact — shorter, more regular numbers also compress better.
- Step 4Minify and purge dead defs — Run the Pro-Minifier and, if there are unreferenced gradients/clips, the Unused Defs Purger. Re-estimate. Expect the gzip savings percentage to drop even as the byte size falls — that's normal for a denser file.
- Step 5Enable transport compression — Turn on brotli (with gzip fallback) for
image/svg+xmlon your server or CDN. Pre-compress static SVGs to.svg.brat build time with brotli q11 for the best ratio at zero runtime cost. - Step 6Verify on the wire and lock in a budget — Re-check the DevTools Size column and confirm
content-encoding: br(or gzip) on the response. Set a per-icon gzip budget based on the estimator's number and enforce it in CI via the batch API.
The two-layer SVG optimisation stack
Content cleanup shrinks the file; transport compression shrinks the wire. They compound. Ranges are realistic, not guarantees — measure your own assets.
| Layer | Tool / action | Typical raw reduction | Measure with |
|---|---|---|---|
| Metadata | Metadata Scrubber | Large on raw editor exports; ~0 on clean files | Estimator (raw size drops) |
| Precision | Precision Tuner @ 1-2 dp | 10-30% of path-heavy files | Estimator (raw + gzip) |
| Structure | Pro-Minifier + Unused Defs Purger | 20-50% combined | Estimator (raw + gzip) |
| Transport | gzip / brotli on image/svg+xml | 70-85% of the cleaned file (on the wire) | Estimator gzip line + DevTools |
Inline vs. external SVG trade-offs
Where the SVG lives changes the caching and request math. The estimator measures the SVG bytes either way.
| Approach | Pros | Cons | Best for |
|---|---|---|---|
| Inline in HTML | No extra request; styleable with CSS | Inflates HTML; not cached independently; repeats per page | Critical above-the-fold icons |
External <img src> | Cached by CDN; shared across pages; loading=lazy | Extra request; can't restyle internals via page CSS | Reused decorative icons |
SVG sprite (<use>) | One request for many icons; great compression | Setup overhead; some <use> styling limits | Large icon systems — see Sprite Builder |
Cookbook
A real icon taken through the full stack, measured at each step with the estimator. Gzip figures are the estimator's real output; brotli is its 18% heuristic.
Step 0 — raw Illustrator export
The starting point: editor metadata, 4-6 decimal coordinates, and a <defs> block. The gzip savings already look good because XML compresses well, but the raw number is inflated.
feature-card.svg (raw AI export) Raw: 7.9 KB (8,092 bytes) Gzip: 2.4 KB — 70% savings Brotli: 2.0 KB — 75% savings
Step 1 — after metadata scrub
Removing the editor metadata and namespaces cuts the raw size with no visual change. Re-estimate to confirm the drop reached the wire number.
feature-card.svg (after Metadata Scrubber) Raw: 6.1 KB (6,248 bytes) Gzip: 2.0 KB — 67% savings Brotli: 1.6 KB — 73% savings
Step 2 — after precision tuning to 1 dp
Trimming path coordinates to one decimal place shortens every number. Shorter, more regular tokens both shrink raw size and help the compressor.
feature-card.svg (Precision Tuner @ 1 dp) Raw: 4.4 KB (4,510 bytes) Gzip: 1.5 KB — 66% savings Brotli: 1.2 KB — 73% savings
Step 3 — after minify + defs purge
Minification collapses whitespace and the purger drops an unreferenced gradient. The gzip percentage keeps falling (denser file) while the gzipped byte size keeps dropping — that's the metric to watch.
feature-card.svg (Pro-Minifier + Unused Defs Purger) Raw: 2.8 KB (2,866 bytes) Gzip: 1.1 KB — 61% savings Brotli: 902 B — 69% savings Net: raw 8,092 B -> 2,866 B (65%); gzipped 2.4KB -> 1.1KB.
Step 4 — confirm transport on the wire
Optimisation only counts if the server actually compresses. Verify the negotiated encoding and the transferred size in production.
$ curl -sI -H 'Accept-Encoding: br' https://cdn.example.com/feature-card.svg \
| grep -iE 'content-encoding|content-length'
content-encoding: br
content-length: 905
Matches the estimator's brotli ballpark (~902 B). Shipped.Edge cases and what actually happens
Embedded base64 raster dominates the size
Won't compressIf an SVG embeds a base64 PNG/JPEG, that high-entropy blob barely compresses and no content tool will help. The estimator's low savings percentage is the signal. Extract the raster, serve it as a separate .webp/.png, and reference it — the SVG itself collapses to a kilobyte or two.
Server isn't compressing SVG at all
MisconfigA static host serving SVG without compression (or with the wrong MIME type) ships the raw size to users. The estimator shows the savings you're missing. Fix the MIME type to image/svg+xml and enable gzip/brotli; verify with the content-encoding header.
Inline SVG inflates the HTML and isn't cached
Trade-offInlining avoids a request but the SVG bytes ride along on every HTML response and can't be cached separately. For a reused icon, an external file the CDN caches usually wins. Reserve inline for a small number of critical above-the-fold marks.
Over-aggressive precision breaks fine detail
Visual regressionTuning to 0 decimal places can visibly distort small or detailed paths. The Precision Tuner rounds coordinates in path data and shape attributes; check the rendered result. 1-2 dp is the safe range for most icons; large illustrations may need 2.
Path Simplifier skipped your curvy paths
By designThe Path Simplifier only reduces points on pure polyline (M/L) paths and skips any path containing C/S/Q/T/A/H/V commands. If your icons are Bezier-based, it won't shrink them — rely on precision tuning and minification instead, and re-estimate.
Minifying breaks an SVG that relied on whitespace
Rare regressionMost SVGs are safe to minify, but markup that depends on significant whitespace inside <text> or specific formatting can shift. Visually verify minified icons. If something breaks, keep the file lightly optimised and lean on transport compression for the win.
Counting raw size against a budget instead of gzip
Wrong metricBudgeting on raw bytes overstates the cost — users pay the compressed size. Always budget on the estimator's gzip line (or a real brotli measurement), which is the number that hits the network.
Tiny icons where compression overhead outweighs the gain
ExpectedSub-200-byte icons may show near-zero savings because the gzip wrapper overhead is significant at that size, and many CDNs skip compression below ~512 bytes. For a sprite of tiny icons, bundle them (see Sprite Builder) so they compress together.
Frequently asked questions
Which optimisation layer gives the biggest single win?
For raw Figma/Illustrator exports, content cleanup — metadata scrub plus minification — usually removes the largest chunk of raw bytes, because exports carry a lot of editor cruft. Transport compression then shaves 70-85% off the cleaned file on the wire. Measure each step with the estimator; the split varies by file.
Why does the gzip savings percentage drop as I optimise?
Because content optimisation removes the redundancy gzip was exploiting. A minified file is denser, so there's less for the compressor to squeeze — but the absolute gzipped byte size is smaller, which is what users download. Judge by bytes, not the percentage.
Should I inline SVGs or serve them externally?
Inline a small set of critical above-the-fold icons to avoid the request; serve reused decorative icons as external files the CDN caches across pages. For a large icon system, a sprite with <use> gives one cached request and excellent compression. Measure the SVG bytes either way with the estimator.
Does lazy-loading SVGs help performance?
For <img src="icon.svg"> you can add loading="lazy" to defer off-screen images, which helps initial load. Inline SVGs render with the HTML and can't be lazy-loaded the same way — use them sparingly for critical marks only.
What Lighthouse metrics do SVGs affect?
There's no SVG-specific Lighthouse audit, but oversized SVGs show up under "Reduce unused bytes" and the overall transfer/LCP picture. A practical target is each individual SVG comfortably under a few KB gzipped — measure with the estimator and budget on that.
How do I prove an optimisation actually reached users?
Two checks: re-run the estimator on the optimised file to confirm the gzip number dropped, then confirm the server compressed it on the wire — look for content-encoding: br/gzip and the smaller transferred size in DevTools or via curl -sI. Configuration without verification is how regressions ship.
Is the estimator's brotli figure safe to plan around?
As a ballpark, yes — it's a flat 18% below the real gzip number. Use it for rough planning, but for a firm brotli budget measure the real .br size with brotli -q 11. The gzip line is the one you can budget on directly.
Will the Path Simplifier shrink my detailed icons?
Only if they're built from straight polyline segments. The simplifier reduces points on pure M/L paths and skips any path with curve or arc commands (C/S/Q/T/A/H/V). Bezier-based icons won't shrink there — use precision tuning and minification, then re-estimate.
How small should an individual SVG icon be?
A well-optimised, minified icon typically lands in the few-hundred-bytes-to-low-KB range gzipped. Illustrations are larger. Rather than chase a universal number, set a budget per asset class from your own estimator readings and enforce it in CI.
Can I run the whole cleanup chain automatically?
Yes. The Metadata Scrubber, Precision Tuner, Pro-Minifier, and estimator are available through the runner-backed API, so you can chain minify-then-estimate-then-budget in CI on your own machine. See the batch estimation guide.
Does compression change the rendered SVG at all?
No. HTTP compression is transparent — the browser decompresses before parsing, so the rendered output is identical. Content optimisation (precision, minify) can change rendering if pushed too far, which is why you visually verify those steps; transport compression never does.
What about really large illustrations — SVG or raster?
If an illustration is photographic or gradient-dense and the estimator shows poor gzip savings, a raster (WebP/AVIF) is often smaller and faster. SVG wins for line art, icons, and anything that must scale crisply. Let the estimator's savings number inform the call.
Privacy first
Every JAD SVG tool runs entirely in your browser using the DOM API and Canvas. Your SVG files never leave your device — verified by zero outbound network requests during processing.