SVG Optimization: The Complete Guide to Reducing SVG File Size

February 11, 2026

SVG files are everywhere on the modern web. Logos, icons, illustrations, charts, and infographics all rely on Scalable Vector Graphics for their resolution independence and small file size compared to raster alternatives. But "small" is relative. An unoptimized SVG exported from a design tool can be 5-10 times larger than it needs to be, packed with editor metadata, redundant elements, and unnecessary precision that browsers simply ignore.

When you multiply that bloat across dozens of SVGs on a single page, the performance impact is real: slower page loads, worse Core Web Vitals scores, and a degraded experience for users on slow connections. The good news is that SVG optimization is one of the highest-return performance wins you can achieve. A few minutes of work can cut file sizes by 60-80% with zero visual difference.

This guide covers everything you need to know about optimizing SVG files for the web: why it matters, what causes bloat, how to fix it manually and with automated tools, and how to measure the impact on real-world performance.

⚙ Try it: Optimize your SVGs instantly with our SVG Optimizer tool. Paste in your SVG code and get a leaner, faster version with one click.

Why SVG Optimization Matters

SVGs might seem lightweight compared to PNGs and JPEGs, but they are still code that the browser must download, parse, and render. Every byte counts, and the cumulative impact of unoptimized SVGs is often underestimated.

File Size and Bandwidth

A typical icon set exported from Figma, Illustrator, or Sketch contains 30-50 SVG files. Without optimization, each file might be 3-8 KB. After optimization, those same files drop to 0.5-2 KB. Across an entire icon set, you could save 100-200 KB of transfer size, which is significant on mobile networks where every kilobyte costs real latency.

For larger illustrations, the savings are even more dramatic. A complex SVG illustration exported from a design tool at 50 KB can often be reduced to 10-15 KB after optimization, a 70% reduction that directly translates to faster downloads.

Page Speed and Core Web Vitals

Google's Core Web Vitals are the primary metrics for evaluating page experience, and SVG optimization directly impacts two of the three:

Largest Contentful Paint (LCP): If your hero image or primary visual is an SVG, its file size directly affects how quickly it renders. An optimized SVG loads faster, improving your LCP score.
Cumulative Layout Shift (CLS): SVGs without explicit width and height attributes cause layout shifts as the browser determines their dimensions. Properly optimized SVGs include these attributes, preventing CLS issues.
Interaction to Next Paint (INP): Complex, unoptimized SVGs with thousands of nodes can strain the browser's rendering engine, making the page less responsive to user interactions. Simpler SVGs mean faster repaints.

Parse and Render Cost

SVG is XML, and XML parsing is not free. Every element, attribute, and namespace declaration in an SVG file must be parsed into the DOM. An SVG with 500 path elements and verbose coordinate data takes measurably longer to parse than one with 50 optimized paths. On low-powered mobile devices, this parsing overhead can add tens of milliseconds per SVG, which compounds across a full page load.

The rendering cost is even more relevant. Each path, group, filter, and gradient in an SVG becomes a render operation. Unnecessary groups, hidden elements, and unused definitions all consume memory and processing time without contributing anything visible to the user.

What Causes SVG Bloat

Understanding where the bloat comes from is the first step toward eliminating it. Here are the most common sources of unnecessary bytes in SVG files.

1. Editor Metadata

Design tools embed proprietary metadata into SVG exports. This information is useful to the editor but completely ignored by browsers:

<svg xmlns="http://www.w3.org/2000/svg"
     xmlns:xlink="http://www.w3.org/1999/xlink"
     xmlns:sketch="http://www.bohemiancoding.com/sketch/ns"
     xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
     xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
     inkscape:version="1.3.2"
     sodipodi:docname="icon-settings.svg">
  <!-- Illustrator adds even more: -->
  <!-- <i:pgf> blocks, data-name attributes, xml:space -->
  <metadata>
    <rdf:RDF>
      <cc:Work>
        <dc:format>image/svg+xml</dc:format>
        <dc:type rdf:resource="http://purl.org/dc/dcmitype/StillImage"/>
      </cc:Work>
    </rdf:RDF>
  </metadata>
  <!-- Actual visible content is below... -->
</svg>

This metadata can account for 500 bytes to several kilobytes per file. In an icon set of 40 files, that is 20-80 KB of pure waste.

2. Redundant Groups and Wrappers

Design tools love nesting. Every layer, artboard, and component in your design becomes a <g> element in the SVG, even when the group serves no purpose (no transform, no shared style, no ID reference):

<!-- Typical Figma/Sketch export: deeply nested for no reason -->
<g id="Page-1">
  <g id="Desktop-HD">
    <g id="Header">
      <g id="Logo">
        <g id="Icon">
          <g id="Shape">
            <path d="M10 20 L30 40 Z"/>
          </g>
        </g>
      </g>
    </g>
  </g>
</g>

<!-- After optimization: just the path -->
<path d="M10 20 L30 40Z"/>

Six levels of unnecessary nesting replaced by a single element. The visual result is identical.

3. Unused Definitions and References

The <defs> section of an SVG can contain gradients, filters, clip paths, and symbols that were used during design but are no longer referenced by any visible element. These definitions are parsed and stored in memory but never rendered:

<defs>
  <!-- This gradient is used -->
  <linearGradient id="gradient-active">
    <stop offset="0%" stop-color="#3b82f6"/>
    <stop offset="100%" stop-color="#8b5cf6"/>
  </linearGradient>
  <!-- These are NOT referenced anywhere in the SVG -->
  <linearGradient id="gradient-old-v2">...</linearGradient>
  <clipPath id="clip-unused">...</clipPath>
  <filter id="blur-draft">...</filter>
  <symbol id="icon-deprecated">...</symbol>
</defs>

On complex illustrations, unused defs can account for 10-30% of the total file size.

4. Excessive Decimal Precision

Design tools export coordinates with far more decimal places than browsers can meaningfully render. At typical screen resolutions, anything beyond 1-2 decimal places is invisible:

<!-- Exported by design tool: 6+ decimal places -->
<path d="M12.839467,3.291856 C15.283746,7.918234
         19.472831,12.384756 24.918273,15.729384
         L31.284756,22.918374 C33.847261,25.193847
         28.374651,30.283746 24.918374,28.374651Z"/>

<!-- Optimized: 1 decimal place, visually identical -->
<path d="M12.8,3.3C15.3,7.9 19.5,12.4 24.9,15.7
         L31.3,22.9C33.8,25.2 28.4,30.3 24.9,28.4Z"/>

Reducing from 6 decimal places to 1 saved 40% of the path data in this example. Across an entire file with dozens of paths, precision reduction is one of the single biggest optimizations you can make.

5. Unoptimized Path Data

Path data (d attribute) is typically the largest portion of an SVG file, and there are several ways it can be unnecessarily verbose:

Absolute vs. relative coordinates: Using absolute coordinates (M, L, C) when relative coordinates (m, l, c) would produce shorter values.
Redundant command letters: Repeating the same command letter when the SVG spec allows implicit repetition (e.g., L10,20 L30,40 can be written L10,20 30,40).
Unnecessary whitespace: Spaces between numbers where the sign or decimal point already acts as a delimiter (M 10 20 can be M10 20 or even M10,20).
Leading zeros: Writing 0.5 when .5 is valid.
Trailing zeros: Writing 10.00 instead of 10.

<!-- Verbose path data -->
<path d="M 0.00,10.00 L 10.00,10.00 L 10.00,0.00 L 20.00,0.00
         L 20.00,10.00 L 30.00,10.00 L 15.00,25.00 Z"/>

<!-- Optimized path data -->
<path d="M0,10H10V0h10v10h10L15,25Z"/>

The optimized version uses shorthand commands (H for horizontal line, V for vertical line, h/v for relative versions), removes unnecessary whitespace, and eliminates trailing zeros. Same shape, 60% fewer bytes.

6. Inline Styles Instead of Attributes

Some editors export styles as inline CSS rather than presentation attributes. While both work, inline styles add overhead when the same property appears on many elements:

<!-- Inline styles: verbose, repeated per element -->
<rect style="fill:#3b82f6;stroke:#1d4ed8;stroke-width:2;opacity:0.9"
      x="10" y="10" width="80" height="40"/>
<rect style="fill:#3b82f6;stroke:#1d4ed8;stroke-width:2;opacity:0.9"
      x="10" y="60" width="80" height="40"/>

<!-- Presentation attributes: cleaner, can be grouped -->
<g fill="#3b82f6" stroke="#1d4ed8" stroke-width="2" opacity=".9">
  <rect x="10" y="10" width="80" height="40"/>
  <rect x="10" y="60" width="80" height="40"/>
</g>

The grouped version with presentation attributes eliminates the repeated style declarations entirely.

7. Comments and Whitespace

XML comments, indentation, and newlines make SVGs human-readable during development, but they serve no purpose in production. A well-formatted SVG with generous whitespace can be 15-20% larger than a minified version with the same content.

Step-by-Step SVG Optimization Techniques

Now that you know what causes bloat, here is a systematic approach to eliminating it. We will cover both manual techniques (useful for understanding and fine-tuning) and automated approaches (essential for production workflows).

Manual Optimization Checklist

Open your SVG in a text editor and work through these steps:

Step 1: Remove metadata and editor namespaces. Delete everything between <metadata> tags. Remove namespace declarations other than the standard SVG namespace (xmlns="http://www.w3.org/2000/svg"). Delete any xmlns:sketch, xmlns:inkscape, xmlns:sodipodi, or xmlns:xlink (unless xlink is actually used for href references).

Step 2: Remove the XML declaration and doctype. These are optional for SVGs embedded in HTML:

<!-- Remove these lines -->
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
  "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">

Step 3: Flatten unnecessary groups. If a <g> element has no attributes (no id, transform, fill, opacity, etc.) or the attributes can be moved to its children, unwrap it. Keep groups that serve a structural purpose, such as applying a shared transform or enabling JavaScript interaction.

Step 4: Remove hidden elements. Look for elements with display="none", visibility="hidden", or opacity="0". If they are not toggled by CSS or JavaScript, delete them. Also check for elements positioned entirely outside the viewBox, which are rendered but never seen.

Step 5: Clean up the <defs> section. For each item in <defs>, search the rest of the file for a reference to its id. If nothing references it, delete it. Common culprits: old gradient versions, unused clip paths, and symbol definitions from component libraries.

Step 6: Reduce decimal precision. Find and replace coordinates with excessive precision. For most web use cases, 1 decimal place is sufficient. For icons at small sizes (16-24px), integers are often enough.

Step 7: Optimize path data. Convert absolute coordinates to relative where shorter. Replace L commands with H/V for horizontal/vertical lines. Remove command letter repetition. Strip leading zeros from decimals.

Step 8: Set explicit dimensions. Ensure the <svg> element has both a viewBox and explicit width/height attributes. This prevents layout shifts and gives the browser intrinsic dimensions for layout calculation before the SVG is fully parsed.

Automated Optimization with SVGO

SVGO (SVG Optimizer) is the industry-standard tool for automated SVG optimization. It applies dozens of optimizations in a configurable pipeline. Install it with npm:

# Install SVGO globally
npm install -g svgo

# Optimize a single file
svgo input.svg -o output.svg

# Optimize all SVGs in a directory
svgo -f ./icons/ -o ./icons-optimized/

# Show optimization statistics
svgo input.svg -o output.svg --pretty --indent=2

SVGO's default configuration handles all the common optimizations: removing metadata, collapsing groups, cleaning path data, reducing precision, and stripping comments. For most projects, the defaults are excellent. Here is a custom configuration for cases where you need more control:

// svgo.config.js
module.exports = {
  plugins: [
    'preset-default',
    'removeDimensions',       // Remove width/height, keep viewBox
    'sortAttrs',              // Sort attributes for consistency
    'removeStyleElement',     // Remove <style> blocks
    {
      name: 'removeAttrs',
      params: {
        attrs: ['data-name', 'class']  // Remove specific attributes
      }
    },
    {
      name: 'preset-default',
      params: {
        overrides: {
          // Keep IDs (needed for CSS/JS targeting)
          cleanupIds: false,
          // Reduce to 1 decimal place (default is 3)
          cleanupNumericValues: {
            floatPrecision: 1
          },
          // Keep viewBox even if width/height are set
          removeViewBox: false
        }
      }
    }
  ]
};

Run SVGO with your custom config:

svgo --config svgo.config.js input.svg -o output.svg

Integrating SVG Optimization into Build Pipelines

For production workflows, SVG optimization should happen automatically as part of your build process. Here are configurations for popular build tools:

Webpack (with svgo-loader):

// webpack.config.js
module.exports = {
  module: {
    rules: [
      {
        test: /\.svg$/,
        use: [
          'file-loader',
          {
            loader: 'svgo-loader',
            options: {
              plugins: [
                { name: 'removeViewBox', active: false },
                { name: 'removeDimensions', active: true }
              ]
            }
          }
        ]
      }
    ]
  }
};

Vite (with vite-plugin-svgo):

// vite.config.js
import { defineConfig } from 'vite';
import svgo from 'vite-plugin-svgo';

export default defineConfig({
  plugins: [
    svgo({
      plugins: [
        'preset-default',
        { name: 'removeViewBox', active: false }
      ]
    })
  ]
});

npm script for batch optimization:

// package.json
{
  "scripts": {
    "optimize:svg": "svgo -f ./src/assets/icons -o ./dist/icons --config svgo.config.js",
    "build": "npm run optimize:svg && vite build"
  }
}

Before and After: Real-World Examples

Let us walk through three real optimization scenarios to see the techniques in action.

Example 1: A Simple Icon (Settings Gear)

Before optimization (2,847 bytes):

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg"
     xmlns:xlink="http://www.w3.org/1999/xlink"
     xmlns:sketch="http://www.bohemiancoding.com/sketch/ns"
     width="24px" height="24px" viewBox="0 0 24 24"
     version="1.1">
  <title>icon/settings</title>
  <desc>Created with Sketch.</desc>
  <metadata>
    <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
      <cc:Work xmlns:cc="http://creativecommons.org/ns#">
        <dc:format xmlns:dc="http://purl.org/dc/elements/1.1/">
          image/svg+xml
        </dc:format>
      </cc:Work>
    </rdf:RDF>
  </metadata>
  <g id="Page-1" stroke="none" stroke-width="1"
     fill="none" fill-rule="evenodd">
    <g id="Artboard" transform="translate(-120.000000, -80.000000)"
       fill="#FFFFFF">
      <g id="icon/settings" transform="translate(120.000000, 80.000000)">
        <path id="Shape" d="M19.140000,12.940000
              C19.180000,12.640000 19.200000,12.330000
              19.200000,12.000000 C19.200000,11.680000
              19.180000,11.360000 19.130000,11.060000
              L21.160000,9.480000 C21.340000,9.340000
              21.390000,9.070000 21.280000,8.870000
              L19.360000,5.530000 ..."
              fill-rule="nonzero"/>
      </g>
    </g>
  </g>
</svg>

After optimization (389 bytes, 86% smaller):

<svg xmlns="http://www.w3.org/2000/svg" width="24" height="24"
     viewBox="0 0 24 24" fill="#fff">
  <path d="M19.1,12.9c.1-.3.1-.6.1-.9s0-.6-.1-.9l2-1.6c.2-.1.3-.4.1-.6
           l-1.9-3.3c-.1-.2-.4-.3-.6-.2l-2.4 1c-.5-.4-1-.7-1.6-.9l-.4-2.5
           c0-.2-.2-.4-.5-.4h-3.8c-.2,0-.4.2-.5.4l-.4,2.5c-.6.2-1.1.5-1.6.9
           l-2.4-1c-.2-.1-.5,0-.6.2L3.5,8.9c-.1.2-.1.4.1.6l2,1.6c-.1.3
           -.1.6-.1.9s0,.6.1.9l-2,1.6c-.2.1-.3.4-.1.6l1.9,3.3c.1.2.4.3
           .6.2l2.4-1c.5.4,1,.7,1.6.9l.4,2.5c0,.2.2.4.5.4h3.8c.2,0,
           .4-.2.5-.4l.4-2.5c.6-.2,1.1-.5,1.6-.9l2.4,1c.2.1.5,0,.6-.2
           l1.9-3.3c.1-.2.1-.4-.1-.6l-2-1.6zM12,15.6c-2,0-3.6-1.6
           -3.6-3.6s1.6-3.6,3.6-3.6,3.6,1.6,3.6,3.6-1.6,3.6-3.6,3.6z"/>
</svg>

What changed: removed XML declaration, editor metadata, three levels of unnecessary groups, moved the fill to the root SVG element, reduced decimal precision to 1 place, optimized path commands, and removed the version attribute.

Example 2: An Illustration with Gradients (Logo)

Before optimization (8,234 bytes):

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 200 200">
  <defs>
    <linearGradient id="grad-primary" x1="0%" y1="0%" x2="100%" y2="100%">
      <stop offset="0.000000%" stop-color="#3B82F6"/>
      <stop offset="100.000000%" stop-color="#8B5CF6"/>
    </linearGradient>
    <linearGradient id="grad-old-draft">...</linearGradient>
    <linearGradient id="grad-unused-v2">...</linearGradient>
    <clipPath id="clip-artboard">
      <rect width="200.000000" height="200.000000"/>
    </clipPath>
    <filter id="shadow-draft">...</filter>
  </defs>
  <g clip-path="url(#clip-artboard)">
    <g id="Background">
      <g id="Group">
        <rect width="200.000000" height="200.000000"
              fill="url(#grad-primary)" rx="24.000000"/>
      </g>
    </g>
    <g id="Icon-Group">
      <g id="Shape-Wrapper">
        <!-- 40+ paths with 6-digit precision -->
      </g>
    </g>
  </g>
</svg>

After optimization (2,156 bytes, 74% smaller):

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 200 200">
  <defs>
    <linearGradient id="a" x1="0%" y1="0%" x2="100%" y2="100%">
      <stop offset="0%" stop-color="#3B82F6"/>
      <stop offset="100%" stop-color="#8B5CF6"/>
    </linearGradient>
  </defs>
  <rect width="200" height="200" fill="url(#a)" rx="24"/>
  <!-- Optimized paths with 1-digit precision -->
</svg>

What changed: removed three unused gradients, an unused clip path, and an unused filter from defs. Shortened the gradient ID from grad-primary to a. Removed the clip path that matched the viewBox exactly (redundant). Collapsed four layers of groups. Stripped trailing zeros from all numeric values.

Example 3: An Icon Sprite Sheet

SVG sprite sheets combine multiple icons into a single file using <symbol> elements. Optimization here has a multiplied effect because every improvement applies across all icons:

<!-- Before: 12,400 bytes for 10 icons -->
<svg xmlns="http://www.w3.org/2000/svg" style="display:none">
  <symbol id="icon-home" viewBox="0 0 24.000000 24.000000">
    <title>Home Icon</title>
    <g id="Layer-1">
      <path d="M12.000000,3.000000 L2.000000,12.000000
               L5.000000,12.000000 L5.000000,20.000000
               ..." fill="#000000" fill-opacity="1.000000"/>
    </g>
  </symbol>
  <!-- 9 more icons with similar bloat -->
</svg>

<!-- After: 3,100 bytes for 10 icons (75% smaller) -->
<svg xmlns="http://www.w3.org/2000/svg" style="display:none">
  <symbol id="icon-home" viewBox="0 0 24 24">
    <path d="M12,3 2,12h3v8h4v-6h6v6h4v-8h3z"/>
  </symbol>
  <!-- 9 more optimized icons -->
</svg>

Performance Benchmarks and Impact

To quantify the real-world impact of SVG optimization, here are benchmark results from optimizing SVGs on a typical web application with 25 inline SVGs and 15 external SVG files:

Metric	Before	After	Improvement
Total SVG size (uncompressed)	284 KB	68 KB	76% smaller
Total SVG size (gzipped)	82 KB	24 KB	71% smaller
DOM nodes from SVGs	1,847	612	67% fewer
HTML parse time	45 ms	18 ms	60% faster
Largest Contentful Paint	2.4s	1.8s	25% faster
Lighthouse Performance Score	72	89	+17 points

The gzipped improvement (71%) is notable because SVGs compress extremely well with gzip/brotli, being text-based. But optimized SVGs compress even better than bloated ones because the redundant patterns in unoptimized SVGs do not compress as efficiently as you might expect. The optimizer removes entropy, making compression more effective on what remains.

The DOM node reduction (67% fewer) is arguably the most impactful metric for runtime performance. Fewer nodes means faster style recalculation, faster layout, and lower memory usage. On a page with many SVGs, this directly improves INP and overall responsiveness.

Best Practices for SVG in Web Development

Beyond file-level optimization, how you use SVGs on your pages matters as much as the files themselves. Here are best practices for maximum performance.

Choose the Right Embedding Method

There are four ways to put an SVG on a web page, each with different performance characteristics:

<!-- 1. Inline SVG: best for icons and interactive graphics -->
<!--    Pros: no extra request, full CSS/JS control -->
<!--    Cons: increases HTML size, not cached separately -->
<svg viewBox="0 0 24 24" width="24" height="24">
  <path d="M12,3 2,12h3v8h4v-6h6v6h4v-8h3z"/>
</svg>

<!-- 2. img tag: best for illustrations and decorative images -->
<!--    Pros: cached, lazy-loadable, simple -->
<!--    Cons: no CSS/JS access to SVG internals -->
<img src="/images/illustration.svg" alt="Feature overview"
     width="600" height="400" loading="lazy">

<!-- 3. CSS background: best for decorative/repeated patterns -->
<!--    Pros: cached, easy to swap, no DOM nodes -->
<!--    Cons: no accessibility, no interactivity -->
<div style="background: url('/images/pattern.svg') repeat"></div>

<!-- 4. SVG sprite with use: best for icon systems -->
<!--    Pros: single request, reusable, stylable -->
<!--    Cons: requires sprite setup, slight complexity -->
<svg width="24" height="24">
  <use href="/sprites.svg#icon-home"/>
</svg>

For most sites, the optimal strategy is: inline SVGs for frequently used icons (under 1 KB each), an <img> tag with loading="lazy" for illustrations, and an SVG sprite for icon systems with 10+ icons.

Always Set Width, Height, and viewBox

This is the single most important SVG attribute practice for preventing layout shifts:

<!-- BAD: no intrinsic dimensions, causes layout shift -->
<svg viewBox="0 0 200 100">...</svg>

<!-- BAD: no viewBox, cannot scale responsively -->
<svg width="200" height="100">...</svg>

<!-- GOOD: intrinsic dimensions AND scalability -->
<svg width="200" height="100" viewBox="0 0 200 100">...</svg>

When both width/height and viewBox are present, the browser knows the aspect ratio before the SVG content is parsed. This lets it reserve the correct space in the layout immediately, preventing CLS.

Compress SVGs with Gzip or Brotli

SVG is text, and text compresses exceptionally well. Ensure your server sends SVG files with content encoding:

# Nginx configuration
gzip on;
gzip_types image/svg+xml;
gzip_min_length 256;

# For even better compression with Brotli
brotli on;
brotli_types image/svg+xml;

With Brotli compression, an optimized 5 KB SVG typically compresses to under 2 KB on the wire. Combined with file-level optimization, this is the one-two punch that delivers the smallest possible transfer size.

Use CSS for SVG Styling When Possible

Instead of embedding colors directly in SVG attributes, use currentColor and CSS to control styling. This makes SVGs smaller and more reusable:

<!-- SVG uses currentColor instead of a hardcoded fill -->
<svg viewBox="0 0 24 24" width="24" height="24" fill="currentColor">
  <path d="M12,3 2,12h3v8h4v-6h6v6h4v-8h3z"/>
</svg>

<!-- CSS controls the color -->
<style>
.icon { color: #3b82f6; }
.icon:hover { color: #60a5fa; }
.nav .icon { color: #e4e4e7; }
</style>

One SVG file, infinite color variations through CSS. No need to duplicate SVGs for different color states.

Lazy-Load Below-the-Fold SVGs

For SVG illustrations loaded via <img> tags that appear below the viewport, use native lazy loading to defer their download:

<!-- Above the fold: load immediately -->
<img src="/images/hero.svg" alt="Hero" width="800" height="400">

<!-- Below the fold: defer until near viewport -->
<img src="/images/features.svg" alt="Features" width="600" height="300"
     loading="lazy" decoding="async">

Consider SVG Alternatives for Simple Shapes

Not everything needs to be an SVG. Simple shapes like circles, lines, and gradients can often be created with CSS alone, eliminating the SVG overhead entirely:

<!-- Instead of an SVG circle -->
<div style="width: 40px; height: 40px; border-radius: 50%;
            background: linear-gradient(135deg, #3b82f6, #8b5cf6);">
</div>

<!-- Instead of an SVG arrow -->
<div style="width: 10px; height: 10px;
            border-right: 2px solid #fff;
            border-bottom: 2px solid #fff;
            transform: rotate(-45deg);">
</div>

CSS shapes have zero network cost and zero parse overhead. If the shape is simple enough for CSS, prefer CSS.

Common SVG Optimization Mistakes to Avoid

Even experienced developers make these errors when optimizing SVGs:

Over-optimizing and breaking accessibility. Do not remove <title> and <desc> elements from SVGs that need alt text for screen readers. These are important for accessibility, not bloat.
Removing viewBox when you should not. The viewBox attribute is essential for responsive SVGs. Removing it to save bytes will break scaling behavior.
Converting strokes to fills prematurely. Some optimization tools convert strokes to filled paths, which can increase file size if the stroke was simpler. Test the output size both ways.
Ignoring the SVGO removeViewBox plugin. SVGO's removeViewBox plugin is enabled by default in some configurations. Always disable it unless you have a specific reason to remove viewBox.
Not testing optimized SVGs. Aggressive precision reduction (0 decimal places) can cause visible artifacts in detailed illustrations. Always visually compare before and after, especially at the sizes your SVGs will actually be rendered.
Optimizing SVGs but forgetting gzip. Server-side compression is the other half of the equation. An uncompressed optimized SVG is still larger on the wire than a compressed unoptimized one. You need both.

Measuring SVG Optimization Results

After optimizing your SVGs, verify the impact with these approaches:

File size comparison: Compare the total uncompressed and gzipped sizes before and after. Use gzip -k to create compressed versions for comparison without modifying originals.
Chrome DevTools Network tab: Filter by "img" or "svg" to see the actual transfer sizes of your SVG files. Check both the uncompressed size and the gzipped transfer size.
Lighthouse audit: Run a Lighthouse performance audit before and after optimization. Look specifically at "Properly size images" and "Efficiently encode images" suggestions.
DOM node count: For inline SVGs, open DevTools and check the total DOM node count before and after. Fewer nodes means faster style recalculation and lower memory usage.
WebPageTest: Run a full page test at webpagetest.org for waterfall analysis. Look for how SVG loading affects your visual progress filmstrip.

# Quick command-line comparison
# Show original vs optimized sizes
ls -la icons/*.svg
svgo -f icons/ -o icons-opt/
ls -la icons-opt/*.svg

# Compare gzipped sizes
for f in icons/*.svg; do
  orig=$(wc -c < "$f")
  gzip_orig=$(gzip -c "$f" | wc -c)
  opt="icons-opt/$(basename $f)"
  optsize=$(wc -c < "$opt")
  gzip_opt=$(gzip -c "$opt" | wc -c)
  echo "$(basename $f): ${orig}B -> ${optsize}B (gzip: ${gzip_orig}B -> ${gzip_opt}B)"
done

Putting It All Together

SVG optimization is a high-leverage performance improvement that takes minimal effort once you set up the process. Here is a summary workflow for any project:

Set up SVGO in your build pipeline so optimization happens automatically. Configure it once, benefit forever.
Configure your export settings in Figma, Sketch, or Illustrator to produce cleaner SVGs from the start. In Figma, uncheck "Include id attribute" and set precision to 2 in SVG export settings.
Choose the right embedding method for each SVG based on its purpose: inline for icons, <img> for illustrations, sprites for icon systems.
Always include width, height, and viewBox on every SVG element to prevent layout shifts.
Enable gzip or Brotli compression on your server for SVG files.
Use currentColor and CSS to style SVGs instead of hardcoding colors, reducing duplication.
Lazy-load below-the-fold SVG images to prioritize above-the-fold content.
Measure the impact with Lighthouse, DevTools, and file size comparisons to validate your optimizations.

The typical result is a 60-80% reduction in SVG file size, a 50-70% reduction in SVG-related DOM nodes, and a measurable improvement in Core Web Vitals scores. For a site with dozens of SVGs, this can mean hundreds of kilobytes saved and a noticeably faster, more responsive experience for every user.

Start with the automated tools to capture the easy wins, then apply manual techniques to your most critical SVGs. The combination of both approaches ensures you ship the leanest, fastest SVGs possible.