Switching Icon Fonts Saves Nothing: Where the Bytes in an Icon Set Actually Go

A common suggestion on Bootstrap sites that use Font Awesome is to switch to Bootstrap Icons: same ecosystem, one less dependency, and presumably lighter. On a site we maintain, we checked that assumption against the actual icon inventory and the actual transfer sizes. The swap would have made the site slightly lighter at best, and the real saving was somewhere else entirely.

Count what the site really uses

The first estimate was that the site used a couple of dozen icons. A crawl of every route found several times that many distinct glyphs, including four brand marks (Facebook, Instagram, Google and WhatsApp).

The distribution matters more than the total. The heaviest users were all in the footer, which appears on every page: WhatsApp, envelope, home and phone, each repeated dozens of times across the site. At the other end, most of the glyphs appeared only a handful of times, many of them once. The site was shipping an entire icon font, around 2,000 glyphs, to draw a few dozen.

The weight comparison

All figures are transfer bytes, with CSS measured gzipped. (Measuring the decompressed size instead overstates CSS about four times; we covered that trap in a previous post.)

Swapping one webfont for another is roughly a wash. Bootstrap Icons is a large set of over 2,000 icons, and its single woff2 file (134 kB) is bigger than either Font Awesome font file. Most of the 164 kB saving comes from not shipping an icon font at all, and delivering only the glyphs in use as inline SVG.

A sprite is a hidden SVG with one <symbol> per icon, referenced wherever an icon is needed:

<svg hidden>
  <symbol id="bi-telephone" viewBox="0 0 16 16"><path d="..."/></symbol>
</svg>

<svg class="icon" aria-hidden="true"><use href="#bi-telephone"></use></svg>

Besides the bytes, SVG avoids the flash of invisible icons while a font loads, takes its colour from currentColor, and behaves predictably for screen readers. In a Yii2 view we would put it behind a small helper such as Icon::i('telephone'), so the markup lives in one place.

Where the mapping breaks down

Most of the icons map cleanly, by name or to a close equivalent. A handful have no honest match: searching the Bootstrap Icons catalogue returns nothing for handshake, hand-holding, scale, gavel or broom, among others.

On a service business's website those are often precisely the icons that carry meaning: working with partners, personal support, household services and the complaints procedure. The nearest substitutes are weak, such as a paintbrush for the broom. Where an icon is there to explain a service, a wrong metaphor is worse than no icon.

Two reasonable ways out:

• A mixed sprite. Take most of the set from Bootstrap Icons and the outliers from another permissively licensed set such as Tabler Icons or Material Symbols, both of which cover handshake and broom. It is still one small sprite, and the visitor never sees that two sets were involved.
• Drop the weak ones. Several of those icons sit next to headings where they add nothing. Removing an icon is a legitimate answer.

Why we deferred the full migration

The analysis said the sprite would remove most of the icon weight. We still did not do it as standalone work. Font Awesome's JavaScript had already been removed, and all static assets carry cache lifetimes of 30 days to a year, so the saving applies to a first visit only. Converting every icon across nearly every view, some of them from a second icon set, is about a day of work with real risk of regressions.

What we did instead was take the cheapest slice. The four brand icons appear only in the footer, so we replaced them with inline SVG. The brands font file is still declared in the CSS, but no element on the page uses it, so the browser never downloads it. That saved 75 kB for a change to one partial view. The regular-weight font was already never fetched for the same reason. The full sprite stays on file for the day those views are being rebuilt anyway.

Counting icons on our own projects

We have made the counting mistake in both directions on pinuno.com.gh. In June 2026 the testimonial star ratings rendered as nothing at all: the markup used Font Awesome 5 classes (fas fa-star) while the page loaded no Font Awesome whatsoever. We switched them to Bootstrap Icons (bi-star-fill), which the site already loaded.

In August an audit called a leftover icon font unused, because a search found no Font Awesome class names against many Bootstrap Icons ones. It was not unused. A social-share widget in the footer of every page used the classes icon-facebook, icon-twitter and icon-linkedin, defined in an old fonts.css. Three icons were keeping four font files and about 300 lines of CSS alive. We switched those three to Bootstrap Icons, already loaded, deleted the font files (including a 14 MB font nothing needed) and trimmed fonts.css to the font stack. The lesson matches the one above: count what the site uses by every class pattern it contains, not just the library's own prefix.

A font that never loads is the other way icons fail. Our energy management product loaded Bootstrap Icons and Chart.js from a CDN that its Content Security Policy did not allow, so in June 2026 we self-hosted both. In July a wider sweep of the policy found the back office still pulling the icon stylesheet from the CDN, and the policy still blocking it: every sidebar, button and dashboard icon in the back office had been rendering as blank space since the policy was introduced, and the marketing font had silently fallen back to the system font on every page. An icon font that is blocked costs nothing on the wire and shows nothing on the screen, so check that it loads before you count what it weighs.

Conclusion

The weight of an icon set is in the font file, not the library's name. If icons are worth optimising, take them out of the font and ship only the glyphs in use as SVG. If not, find the slice that removes a whole font file for the least work, and stop there.

If you want to learn to build and maintain PHP web applications like this one, have a look at our PHP Application Developer course.