Our image pipeline: Payload CMS sizes, webP, and Next.js image
How we generate CMS image sizes, serve WebP with blur placeholders, & cache-bust on update, the full image pipeline behind our Core Web V...
The Blog
Social icons, UI icons, navigation glyphs, most sites load each one as a separate file or inline each SVG independently. An SVG sprite bundles them into a single hidden element, referenced by symbol ID. Fewer requests, less component weight, same visual result.
The pattern
Most sites handle icons one of three ways: individual SVG files loaded per-request, inline SVGs duplicated in every component that uses them, or an icon font that loads the entire character set regardless of how many you use.
Each approach has a cost. Individual files mean more HTTP requests. Inline duplicates inflate the HTML. Icon fonts load glyphs you never display and introduce a flash of invisible text while the font loads.
An SVG sprite takes a different approach. Every icon is defined once as a <symbol> inside a hidden <svg> element mounted at the root of the page. Components reference icons by ID using <use href="#icon-name">. The browser renders the symbol without re-downloading or re-parsing — one definition, multiple references.
The implementation
We mount a single IconSprite component in the root layout. It contains <symbol> definitions for every site icon, social platforms (Facebook, Instagram, LinkedIn), UI elements, and navigation glyphs. The SVG element is hidden and renders no visible output on its own.
Individual Icon components reference symbols by a namespaced ID. The component handles sizing and colour inheritance, and the icon renders inline without loading any external file.
For accessibility, decorative icons (like social platform logos next to a text label) get aria-hidden="true". Icons that serve as the sole interactive element (like a social link with no visible text) get an aria-label describing the action.
Why it matters
An SVG sprite is not a dramatic performance win on its own. It's a hygiene pattern, the kind of small decision that compounds across a site.
On a page with a footer containing five social icons, a header with three navigation icons, and a handful of UI icons in the content, the difference is measurable: one cached SVG definition versus a dozen separate inline elements or network requests. Multiply that across every page load and the cumulative savings in parse time and HTML weight add up.
It also keeps components cleaner. An icon component that references a symbol ID is smaller and simpler than one that contains the full SVG path data inline. When an icon needs updating, you change it in one place, the sprite definition, not in every component that uses it.
For sites focused on web performance, these hygiene patterns are part of the foundation. No single one transforms your Core Web Vitals score. Together, they're the difference between a site that passes comfortably and one that's always borderline.