Frontend System Design/Icon Rendering
Lesson 14 of 17 · Episode 14

Icon Rendering — Part 3

Tying icon rendering back to performance and component APIs.

PerformanceTree-shakingComponent API
Watch on YouTube ↗

The last three techniques are vector-based, built on SVG. They recover everything raster lost — infinite sharpness, recoloring, animation — and the final one folds in the sprite idea too. Then we'll put all six side by side and see how real apps mix them.

Technique 4

SVG as an asset

The simplest jump from raster: keep using an <img> (or background) but point it at a .svg instead of a .png. You instantly gain scalability — one file, sharp at any size — and SVGs are usually smaller (compressible text). But because it's still loaded as an external image, you're back to one request per icon and you have no access to its internals — you can't recolor or animate the paths inside.

Technique 5

Inline SVG

Inline SVG drops the <svg> markup straight into the document (or bundles it as a component). Two big wins: it ships with your markup/JS bundle (no extra request), and the paths live in the DOM so you have full control — restyle any part, animate it, react to state. Try it:

Inline SVG — full internal control
Change it live — no new request
<path stroke="neutral" />

Because the markup lives in the DOM, every part is stylable and animatable — impossible with an <img>.

In a component world you wrap it once (<HomeIcon />) with props for color and size, import SVGs as components via a build plugin (SVGR and friends), and even tree-shake the unused ones.

The cost: DOM bloat & caching
Every inline icon's full markup sits in the DOM — hundreds of them bloat it and slow rendering. And since icons are now part of the JS bundle, changing one busts the whole bundle's cache (no per-icon caching).
Technique 6

SVG sprite

The SVG sprite is the image-sprite idea reborn in vectors: one big SVG holds every icon as a <symbol> with an id, and you stamp one out with <use href="#home"/>. You keep full SVG control (recolor, animate) and collapse everything to one resource. It comes in two flavors:

Side by side

All six, side by side

Here's the whole journey scored on five pillars. Flip to Autoplay to tour them and watch the trade-offs shift — notice how the vector techniques light up scaling and color control:

raster
<img src="home.png">
Few requests
Scales sharp
Color control
Granular cache
Light DOM
Dead simple and independently cached, but one request per icon and it pixelates when scaled.
There's no single winner
Each technique trades something. Inline SVG gives you total control but bloats the DOM; an external SVG sprite wins back caching and trims the DOM but adds a build step. The “best” choice depends on your icon count, how often they change, and how much control you need.
In the wild

How real apps mix them

Production apps rarely pick just one — they mix techniques per need. Tap through three real examples:

Practice

Check your understanding

Q1Multiple choice
What does inline SVG let you do that an SVG loaded via <img> does not?
Q2Sort each scenario
Which technique fits the trait?
Risks DOM bloat with hundreds of icons
Caches separately from your JS bundle
Unused icons can be tree-shaken from the bundle
~1,000 icons via one request + <use>
Q3Multiple choice
What's the overall lesson from comparing all six techniques?
Try it yourself

Design challenge

For an app you're building, plan its icon strategy:

  1. Roughly how many icons, and how often do they change?
  2. Do you need recoloring or animation (→ inline/sprite) or is one color fine (→ font)?
  3. Pick a primary technique and name one spot where you'd deviate — and why.
Key takeaways
  • SVG as asset: scalable and small, but one request each and no internal control.
  • Inline SVG: bundled (no extra request), full recolor/animate control, tree-shakeable — at the cost of DOM bloat and bundle caching.
  • SVG sprite: one resource of <symbol>s used via <use>; external references restore caching and trim the DOM.
  • Across all six there's no single winner — real apps (Wondercraft, Luciq, Facebook) mix techniques per use case.
← Previous
13. Icon Rendering — Part 2
Next →
15. State Normalization