SVG Fragments Identifiers are a smart sprite-ing solution. Instead of defining slices of an SVG image by using CSS, you can define them within the SVG itself and refer to the individual parts by using URL fragments. Ex:

<img src="//s.svgbox.net/materialui.svg#bell" />
<img src="//s.svgbox.net/materialui.svg#heart" />

These two requests refer to the same file but different icons by using fragment identifiers.

CSSTricks has an excellent primer on fragments identifiers, which you should read to understand them better.

Spriting is one of the oldest web optimization tricks in the book. Instead of serving multiple individual icons, serve one big sprite. Makes sense, right? But does it actually perform better these days? I expected it to, and in some cases, it really does. That's the reason why SVGBox included an option to use the icon via SVG fragments.

In practice though, for the majority of use-cases, the benefits of sprite-ing are limited. Here are a few reasons why:

1. HTTP/2's multiplexing allows multiple resources to be requested on a single TCP connection.. That means the limit of six concurrent HTTP requests is no longer a concern. Although, compression works better if files are bundled, and if you're serving several dozens of resources bundling would still be a great optimization, but most apps and websites wouldn't load that many icons on their web page.

2. Shaving off a few kilobytes and requests won't have a measurable impact in the grand scheme of things. For instance, I just visited nytimes.com and even the mobile version downloaded more than 7MB of resources. The impact of a few SVG icons loaded over HTTP will have a very insignificant impact on the performance in most cases. This isn't just limited to nytimes.com. For most applications the deciding factor in performance is heavy resources like embeds, javascript, and big images, and what is the overall approach of loading the page, not small icons.

3. Number requests don't matter as much as blocking requests. Not all requests are created equal. For instance, CSS files loading in the HEAD will block rendering until all of them are loaded, and will have a measurable impact on the website's performance, but the same can't be said for tiny requests being loaded asynchronously that don't block rendering.

4. Effective caching headers reduce a lot of overhead for subsequent page loads. If the resources are served with effective caching headers, browsers can cache most of requests for subsequent browsing. For example, SVGBox, by default, serves icon with a max-age of 1 year, because a particular icon is never supposed to change. Therefore, for multiple visits, the overhead of serving pages is further reduced.

I realized that number of requests doesn't affect the user experience to an extent I was thinking it did. For instance, take a look at this example. Even though it loads 10+ icons, nearly all of them appear at the same time. Even on slow connection, the effect on performance isn't very perceptible.

In fact, SVG Fragments would probably hamper the performance since the whole bundle needs to be downloaded instead of a tiny icon.

They feel like an unnecesarry option for most scenarios. Granted, it probably has its place, but I want to avoid the needless choice the developer has to make when the default one would solve most of their problems.

The old requests will work as normal, but SVGBox won't be displaying fragment URLs from now on.