In 2010, we decided to embed images because of:

• how browsers worked at the time and our understanding of how browsers worked,
• the use of HTTP/1 (relatively high cost for each additional request, limited number of connections that each can only start requesting the next resource after the previous has gotten its complete response),
• our focus on reducing the total time taken and bandwidth spent for loading a page.

Embedding images allowed the images to act like a super-sprite in terms of compression (saving on bytes transferred) and reduced the number of requests (fewer roundtrips, thus faster page load time). Between then and 2019, some things have changed:

• we now use HTTP/2, in which parallel requests have fewer disadvantages, less overhead, and there is no longer a concurrency limit after which requests would be stalled. There is still non-zero overhead and saving requests can still benefit. But, its overhead is now smaller, and as such there are now also scenarios in which an extra request would actually save time rather than increase time. It's also important to note that we spent fewer bytes on HTTP in HTTP/2 due to the ability to compress values over multiple requests (HPACK).
• we still consider bandwidth cost an important factor. But for a given individual and a given quantity of bytes on the network, it is now cheaper than it was ten years ago (citation needed). Hence, while 10 KB may've been a deal-breaker in some trade offs before, a similar trade off might now only be justified for 30 KB. Depending on how many bytes a change saves or adds, and how much it improves other factors (e.g. UX, perceived performance, rendering speed, battery power, etc.), it may now be acceptable to be less optimal on bytes if it means a significant improvement on other factors.
• several browsers now support HTTP Preload.
• we now have much better insight into visual rendering in browsers (RUM: Paint Timing. WebPageTest: Visual metrics). And we've decided to make them part of the key performance metrics we monitor.

The way browsers work, and have worked even in 2010, is that a stylesheet blocks the appearance of any content or layout on the page. The flow is as follows:

1. Browser requests HTML page from server, and
2. Browser starts to receive HTML from server.
3. Browser detects sub resources, such as stylesheets, images, and scripts. And requests them. Stylesheets are given a high priority through the HTTP/2 semantics.
4. Browser continues to receive HTML from the server and parses it, but may not yet render.
5. Browser starts to receive the stylesheet.
6. Browser receives the remaining parts of the stylesheet.
7. Browser may now render the HTML it's parsed so far. (First paint)
8. Browser continues to receive HTML and will progressively parse/render in chunks until it reached the end of the HTML stream. The same applies to images and scripts.

By embedding icons in stylesheets, no page content, text, or layout may appear until all icons are downloaded. This is in essence a sort of "ultra high priority" hack, analogous to synchronous scripts (and we know how much we don't like synchronous scripts). The use of embedding is therefore imho unacceptable, without exception. No icon can be more important than the layout of the website, and the article text itself.

I'm closing this in favour of T120984. In there, we'll evaluate ways to make sure we will not regress visual completion times for the above-the-fold rendering. For example, by introducing a @preload annotation that would eagerly start parallel HTTP requests for those icons before the browser has finished the HTML/CSS rendering; which we would selectively apply to a subset of icons in CSS that we know render above-the-fold on most view ports.