DECISION NODE

Icons are a crucial part of any app: along with specific color schemes, layouts, and workflows, icons create a consistent language within the app that a user can easily identify. They are also valuable in a time in which users are bombarded by constant blocks of text. A simple image with a clearly conveyed meaning can offer the satisfaction of quick, unhindered movement, all without drawing attention to itself. A user wants to be guided without having to be aware they’re being guided; they want the act of moving through an app to feel instinctual.

What do developers and designers want from icons? Most likely they want them to be both simple and distinctive—clear enough that the user can glean each one’s meaning in a single glance, but designed in such a way that it feels specific to the site, so that the user feels fully immersed in the app, never distracted by an incongruous shape or color. Developers will also want pages with icons to render accurately, quickly, and consistently.

Because icons need to be easily scalable, a common solution is to make use of vector images. Some developers utilize icon fonts to quickly gain access to a wide array of icons, while other developers make use of SVGs, which allow for a high level of customization and optimization.

But what’s the best approach to use in your app? Let’s take a closer look at the options:

Icon Fonts

An icon font offers a typeface with icon characters rather than letters/numbers. Just like with regular fonts, they’re easy to style using CSS. This ease of use is one of their biggest advantages: when using ready-made fonts, getting the right color, size, and line width is as simple as adding a few CSS classes. (Some libraries even offer built-in animation options.) An icon font also gives you instant access to a wide array of images, which removes the need to obtain each one as a separate asset.

Typically, an app will fetch the font by way of an HTTP request. There are a few advantages to this: the font can be cached in the browser, so that on subsequent loads it will be ready to go, and it cuts down on the amount of code that needs to be stored in the app itself. The downside, of course, is that an HTTP request is never fully reliable, and this can cause visual issues that the user might notice. One possibility is “icon flickering”: because the font is fetched only after the page is loaded, there is the possibility that the user will briefly see an unstyled icon before it is replaced with the correct one. Even worse, if the request fails, the icon might be incorrectly rendered as a random character. These are edge cases, but given their possible impact on the user experience, they’re worth considering.

Accessibility is another area for concern with icons. If a user is using a screen reader, for instance, the site should clearly convey that an icon is an image, not text, and should make it clear whether the icon has semantic significance or whether it can be safely ignored. This behavior is entirely achievable with icon fonts—decorative icons can be hidden from screen readers using the <area-hidden> attribute, whereas others can be given a title—but the unfortunate reality is that, when these distinctions aren’t baked in and have to be made explicit for each icon, there’s always a chance that one of these labels will be unintentionally omitted due to human error.

Overall, icon fonts offer tremendous ease of use, and current available fonts can offer a great deal of flexibility and variety; however, it’s worth considering the possible risks involved in consistent rendering and accessibility.

SVGs

An SVG describes a vector image using XML. While the code itself is somewhat more complex than a pre-made font—a frontend developer might need to work with a design team, for example, in order to fully optimize the file—it’s worth noting that many current icon libraries offer their icons as SVGs as well as fonts.

Probably the biggest advantage SVGs offer is a higher degree of customization. Each separate stroke can be handled individually by CSS, which means SVGs can easily be made multichromatic (important if you want to catch the user’s eye or make use of a site’s existing color scheme) and can leverage CSS to create highly specific animations. Since the entire purpose of an icon is to convey a concept or action to the user via a precise, calculated appearance, this level of control is a massive advantage.

Unlike icon fonts, SVGs can be placed directly in the code, meaning there is no need to fetch any additional assets. In many cases this can help the page’s load time. As an informal experiment, I created two plain HTML files, each with five icons from Font Awesome: one using a script in the page’s <head> to fetch the font file, and one using the same icons coded in as inline SVGs. The SVG version of the page was consistently transferring about 2.2kB on each page load; for the font version, the initial load was 195kB, but once the font file was cached, that number went down to 412B. So for the initial load, the SVG version performed significantly better. One issue, however, is that these SVGs can’t be cached separately from the HTML, and they will inevitably make the codebase more verbose. When I updated each of my test HTML files to display 100 icons as opposed to only five, the results looked a bit different: the SVG version transferred about 209kB, while the font version transferred about 217kB on the initial load and only 22.9kB on subsequent loads, a major difference. In cases like this, where caching can make a large impact, it’s possible to store SVGs externally so that they’re fetched as needed and cached separately. (This is especially useful if the same SVG is used on separate pages.)

In terms of accessibility, SVGs make use of more semantic attributes such as <aria-labeledby>, which ensures that the element is given an accessible name, as well as <desc>, a longer description of the icon than the <title>. They are also more semantically accurate than fonts, since they declare themselves as images rather than an element that could potentially be read as text.

PNGs

Unlike fonts and SVGs, which use vectors, PNGs are raster files, meaning they don’t lend themselves as well to scaling up/down. This is obviously a big disadvantage; however, it’s worth mentioning that PNGs can be used to store bitmap images, which can be useful for visuals that are taken from sources like digital photographs.

TL;DR

While SVGs have gained wider overall popularity in the past few years, there are still significant trade-offs between both approaches. The advantage that stands out most for icon fonts is their ease of use. A developer doesn’t need to worry about obtaining SVG assets or optimizing them, and attributes like color, line stroke, and even a good number of animations can be utilized with a quick update to a CSS class. Caching can also make a difference in performance when a large number of icons are displayed on a single page.

SVGs, on the other hand, work best where customization and accessibility are primary concerns. Overall SVGs offer more opportunities for customization, ranging from multiple colors or color gradients to detailed animations. They also reduce some of the risks involved with fetching a font via an HTTP request. For accessibility, it’s generally easier for technologies like screen readers to recognize an SVG as an icon, while fonts require aria attributes that can easily be left out by mistake.

Regardless of the approach, the goal is the same: not for the user to admire an icon’s definition or performance, but rather for them to be unaware of it, to enjoy a streamlined experience in which the process of accessing different parts of an app feels as intuitive as walking from one room to the next.

AI Diagram Prompts

Here are the prompts that were used to generate the above diagrams with Eraser AI.

Incorporating Icon Font into Codebase: Create a diagram showing the process of incorporating an icon font into an existing codebase. First, add a url to the <head> of the app's html. Then, create an <i> element and assign it specified class names in order to determine the image, size, stroke, etc. Then, make sure icons are positioned correctly by using CSS properties like line-height and vertical-align.

Icon Font Fetching Process: Create a diagram to show the process of fetching an icon font. First, the page performs its initial load, and if the font is already cached, it is used automatically. If the font is not cached, an HTTP request is made to an external source, which returns a file such as a woff2 that contains the font. Then, the page is re-rendered using the newly obtained font.

Incorporating SVGs into a Codebase: Create a diagram showing the process of incorporating SVGs into an existing codebase. First, obtain the SVG itself from an external source. Then, add the <svg> into the DOM, either by inserting the element directly into the HTML or, in a React app, importing it as its own component. Then update the styling, such as size, color, or animation, through CSS.

SVG Fetch Process: Create a diagram to show the process of fetching an SVG. First, if the entire page is cached, then the SVG will be cached along with it. If the SVG is stored externally, the page first checks if the SVG is cached. If the SVG is not cached in either of these ways, then it will be retrieved and loaded along with the rest of the HTML for the page.

Decision Tree for SVGs vs Icon Fonts: Create a decision tree deciding between SVGs and Icon Fonts. If you want an easy setup with a wide array of options, use icon fonts. If you have strict accessibility requirements, use SVGs. If you need to customize with multiple colors or animations, use SVGs. If you want consistent performance that avoids failed HTTP requests or "flickering", use SVGs. If you want a less verbose codebase, use icon fonts (OR use External SVGs).