Icon Best Practices in a HTTP/2 World

In which we set out to assess whether to still bundle/sprite icons together when using HTTP/2.

The Incumbent: Icon Bundling

It’s been widely accepted for some time that you must bundle your icons somehow, for the same reason you bundled your JS and CSS: performance. Recent debates have focused on how to bundle, see: The Great Icon Debate: Fonts Vs SVG, Inline SVG vs Icon Fonts [CAGEMATCH], Making the Switch Away from Icon Fonts to SVG and Seriously, use icon fonts, etc.

Whatever approach you choose though, it’s an added workflow to do the bundling, you need to make decisions about whether and how to split your bundles (e.g. global icons, page-specific icons, etc) - and probably also add some custom approach to your front-end workflow too.

So can we do away with it?

The Challenger: HTTP/2 Unbundling/multiplexing

If you’d like a high level understanding of HTTP/2 and performance, it’s like this: HTTP/2 Performance

But then, you read that actually there’s a lot more to it. Hence maybe icons aren’t that simple either.

Looking specifically for icon advice with HTTP/2, we don’t find a lot.

Yoast thinks it’s pretty open and shut:

Image spriting is the practice of combining several small images into a larger image so as to reduce the number of requests. This is a cumbersome process with quite a bit of overhead, and HTTP/2 entirely removes the need for it.

But here’s Smashing Magazine a year ago being rather equivocal:

Serving the small images individually will be better in many cases; you will only need to serve what is required for the page that the visitor is on. Creating a sprite will still be warranted in some cases; HTTP requests are only one aspect of performance. Combining some images together in a sprite might achieve better compression and, thus, a smaller download size overall, especially if all of those images are used on the page being loaded.

So what are the cutting edge sites actually doing now?

Assessing Leading Websites

What Would Scott Jehl Do?

I really like what Scott and the Filament Group do, especially when they kindly open source their work so the rest of us can use it. I remembered they had written about modernizing their progressive enhancement delivery a few months back, so I thought I’d check out their site first.

Amusingly, that blog post has zero icons, as does their home page. I had to go hunting until I eventually found Twitter icons on their Who We Are page. Inspecting it, we see:

Filament Group Icon

and digging further:

Filament Group CSS Icons

I guess when you only have four icons and you already authored a grunt-based icon CSS tool tool, you know what you’re going to choose.

Twitter Lite

Twitter’s made headlines recently with their fast new Progressive Web App, Twitter Lite. And they even wrote about their performance learnings too!

In Twitter Lite, we use SVG icons, as they’re the most portable and scalable option available to us.

OK, so they’re SVG-based. But… sprited or not? Let’s read on:

Now, our SVG icons are simple stateless components, don’t use “dangerous” functions, and mount an average of 60% faster. They look like this:

const HeartIcon = (props = {}) => (
  <svg {...props} viewBox='0 0 ${width} ${height}'>
    <g><path d='M38.723 12c-7.187 0-11.16 7.306-11.723 8.131C26.437 19.306 22.504 12 15.277 12 8.791 12 3.533 18.163 3.533 24.647 3.533 39.964 21.891 55.907 27 56c5.109-.093 23.467-16.036 23.467-31.353C50.467 18.163 45.209 12 38.723 12z'></path></g>

Taking a look at the Sources for mobile.twitter.com confirms that the icons are bundled up somewhere in that JS:

Twitter Mobile sources

So I’m doing to declare that as a vote for "bundling", even though it’s done in a very Reacty way. This is not looking good for unbundling icons so far.

Smashing Magazine

Another high profile redesign this year has been Smashing Magazine. It’s been written about by themselves here.

Let’s jump straight in and inspect their link icon:

Smashing magazine icon source

A standalone icon!

Let’s look for another to make sure it’s not a fluke. There’s a camera icon next to an image caption, and digging into its CSS we see:

.article__content figure figcaption::before, .article__image figcaption::before {
    content: url(data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zd…45MSAwIDEgMSAzLjkxLTMuOTEgMy45MSAzLjkxIDAgMCAxLTMuOTEgMy45MXoiLz48L3N2Zz4=);
    width: 1.5em;
    padding-right: .6em;
    display: table-cell;
    vertical-align: baseline;
    position: relative;
    top: .05em;

So… it was a fluke? Let’s head to the home page (https://next.smashingmagazine.com) to look for more icons.

These are sort of icons:

Smashing Magazine Icons

And inspecting the source, we see:

<span class="main-nav__icon">
  <img src="https://d33wubrfki0l68.cloudfront.net/2bc30327ebf529a249e825447d86f18546a1d6db/36b19/images/nav-icons/articles.svg" alt="">

That’s another standalone SVG icon, in a folder called "nav-icons".

Venturing further down the page revealed a “speech bubble” icon that was also embedded in CSS.

So for Smashing Magazine we’ll call it a draw.


Flipkart from India made a “high profile” Progressive Web App with lots of traffic, so let’s see what they’re doing.

At the top of the page they have a bell/notifications icon and inspecting it we see it’s… inline SVG. Running “View Source” in Chrome and then searching for <svg reveals 8 hits. Down the bottom we find that the icons here are part of the same PNG sprite:

Flipkart sprite

Meanwhile, inspecting their social icons reveals a huge other PNG sprite, so Flipkart definitely counts as another in the sprite basket.


Another high profile Indian PWA came from Housing.com. Inspecting the icons in their header:

Housing.com header

…reveals they’re using icons from icomoon, so that’s another in the “bundling” camp.


Staying in Asia, we check out the AliExpress PWA:

Aliexpress PWA

…And find it’s using an icon font.

Google I/O

Let’s check out Google’s I/O app from 2016 and see what approach they chose.

We don’t see typical “small” icons but their layout utilises large icons like this:

Google I/O icons

Inspecting it, we see:

element.style {
    height: 100%;
    background-image: url(/io2016/images/home/icons/android.png);

Yes! Tally one in the non-bundled category.

One more thing: AMP

The first thing that led me to “unsprite” my SVG icons was adding AMP support to certain types of pages on the site. In that case, SVG sprites were not feasible so we use separate SVG files for each icon we need. I wondered what everyone else is doing?

The Guardian are a high profile AMP success story, and you can find example AMP articles like this one. Inspecting that page reveals… they have inlined every single SVG into the HTML! Searching the HTML source reveals 46 SVG elements on the page. Interestingly, they appear to do the same on their non-AMP versions too.

Checking out a Reuters article reveals they’re using a traditional PNG sprite with CSS:

Reuters PNG sprite


I started this hoping we might find enough evidence that the web world was moving towards “de-spriting” as a result of HTTP/2’s multiplexing capabilities.

Here’s the summary of what we observed:

  • Filament Group: Icon bundling in CSS
  • Twitter Lite: Icon bundling in React JS
  • Smashing Magazine: Mix of icon bundling with CSS + individual SVG icons
  • Flipkart: Mix of Inline SVG + icon bundling with PNG sprites
  • Housing.com: Icon fonts
  • AliExpress: Icon fonts
  • Google I/O: Individual SVG icons
  • Guardian AMP: Inline SVG icons
  • Reuters AMP: Icon bundling with PNG sprites

So what can one conclude?

  1. There’s no common practice for icon handling
  2. Icon bundling is still the dominant solution
  3. There is evidence to suggest some sites are embracing non-bundled icons

Finally, a little editorialising on why we’re not seeing any move to unbundling yet.

First of all, it’s possible that the performance gains of multiplexing icons are negligible in most cases - icons are definitely not “low hanging fruit” when it comes to performance redesigns.

Second, although many icon bundling workflows might have been painful to set up, once they’re in place and work… well, they’re working, aren’t they? Inertia can be hard to overcome.

Rhys Arkins-

Rhys is the founder of Key Location