The Case for Subsetting Font Awesome
Font Awesome is one of the most widely used icon libraries on the web, and for good reason. It offers thousands of glyphs across multiple styles, making it easy to drop polished icons into nearly any project. The problem is that the default setup ships all of those glyphs to every visitor, whether they use five icons or five hundred. That weight adds up quickly, particularly for mobile users on slower connections.
Subsetting is the process of stripping unused glyphs out of a font file so the browser only downloads the characters your page actually renders. Font Awesome supports several approaches to subsetting. Some are automatic and require no ongoing maintenance; others give you exact control over every icon in the bundle. We'll walk through each method and measure the impact on file size.
Measuring the Default Setup
To establish a baseline, we loaded an HTML page that imports Font Awesome's all.min.css and displays an icon set representative of a real side project. The CSS file itself gzips down to 33.4KB, which seems acceptable at first glance. However, when you inspect the network traffic, the font files are where the real cost hides.
In Chrome DevTools, the Fonts tab reveals the full scope of the problem. The default Font Awesome distribution pulls down multiple font files across its supported styles, and collectively they total roughly 757KB before compression. A portion of this traffic is unnecessary because the font rendering process fetches the full font file for any style used on the page, so even using a single widget icon means downloading every glyph in the solid weight.
CSS Purification Isn't Enough
The natural first instinct when trying to slim down an icon library is to remove unused CSS rules. Tools like PurifyCSS scan your markup, identify which selectors are actually referenced, and strip out the rest. Running PurifyCSS against our test page trimmed the stylesheet from 33KB to 7.1KB over the wire, an improvement of more than 70%.
That positive result, however, masks a more fundamental issue. PurifyCSS works at the CSS rule level and has no way to reach inside the font files themselves. The @font-face declarations and the complex unicode-range mappings used by Font Awesome still point to the full font files, which remain identical on disk. When the browser loads the page, it still downloads the same sized font files as before. The CSS got leaner, but the real weight of the page didn't budge.
Automatic Subsetting With Kits
Font Awesome offers a much more robust solution through its kit system. Available to paying Pro subscribers, a kit gives you a single script tag to place in your HTML <head>. Instead of static CSS files, the kit delivers code that analyzes the page and only loads the font data you need. You can think of it as a font delivery mechanism that inspects the DOM and builds a subset on the fly.
const purify = require("purify-css");
const content = ["./dist/**/*.js"]; // Vite-built content
purify(content, ["./css/fontawesome/css/all.css"], {
minify: true,
output: "./css/fontawesome/css/font-awesome-minimal-build.css"
});Switching our test page from the CSS import to a Font Awesome kit changed the loading profile completely. No legacy CSS files were required, and the JavaScript file came in at just 4KB. More importantly, the DevTools Fonts tab now showed only two font files being fetched rather than the full spread of weights and styles. Total font weight dropped from 757KB to 331KB, which is a reduction of more than 50%. Not bad for what amounts to adding one script tag.
The automatic kit is effective because it dynamically determines which styles your page actually needs. If your markup only uses solid icons, you don't pull in the light or duotone variants. The savings are real, but they are not necessarily optimal. If your page renders 54 unique icons, you're still sending 331KB of font data, much of which represents glyphs you'll never display.
Building a Manual Subset
For developers who want maximum control, Font Awesome provides a desktop application for manual subsetting. The tool resembles an icon picker: you can search the Font Awesome library, select specific icons from any available family, choose which weights you want, and then click the Build button to generate a custom package.
The resulting ZIP archive follows the same directory structure as the standard Font Awesome download, so swapping it into place requires no special integration work. The application saves your selections as a project file, which means you can reopen it later to add or remove icons as your needs evolve.
The size differences are remarkable. The custom package still contains the same set of .woff2 files that Chrome would normally load, but none of them exceeds 5KB on disk, even uncompressed. The accompanying CSS file drops to just 8KB raw and 2KB gzipped.
<script src="https://kit.fontawesome.com/xyzabc.js" crossorigin="anonymous"></script>Interestingly, if you build your project with Vite, you may notice in DevTools that your CSS file appears slightly larger than expected and that many of the expected font file requests don't show up as separate network entries. Vite detects that the subset fonts are so small that it inlines them into your CSS as base64-encoded strings, collapsing dozens of requests into one. The tradeoff is that the font file formats your target browsers will never use get bundled too. Vite may inline several .woff or .ttf versions, even when the browser only reads the .woff2 data. In this particular test case those discarded formats accounted for some additional CSS weight, but the overall byte count remains a fraction of what the default distribution required.
What About a CLI for CI/CD?
One obvious gap in the manual workflow is automation. The desktop app works fine for individual developers, but it doesn't integrate naturally with a continuous integration pipeline. When Font Awesome was asked about a command-line interface for their subsetter, the company confirmed that a CLI is in the works for the future. Until then, generating per-project font subsets means opening the desktop application for each release that touches the icon set.
Weighing Your Options
Font Awesome's out-of-the-box setup is easy but inefficient. The default configuration remains best for quick prototypes and low-stakes pages. For production applications that care about initial load time, the potential savings from subsetting are hard to ignore: the same set of 54 icons dropped from 757KB in font data down to roughly ten kilobytes when built as a manual subset. That's the difference between wasting a significant slice of a mobile user's bandwidth and moving that page's critical resources out of the way entirely.
