SVG, Iconfonts vs PNG

Article based on Images in layout. Stop it . Rather, even based on the comments on this article and in general, the reaction of the Habr to the call for the use of vector graphics wherever possible and really necessary.

Frankly, I was a little surprised by the reaction to such thoughts in 2014, or that year. On this occasion, we consider in more detail the existing techniques for working with icons.

At the moment, everything is more or less simple. We can typeset icons using SVG, create icon fonts, and the good old technique using rasters, in particular PNG, has not gone away. True, some nuances were added with the appearance of a bunch of HDPI devices with completely different pixel density.

Svg

The most violent reaction was caused by the use of SVG. First, the user franzose noticed that:

Only here the weight of a complex vector is much greater. And the chances of hanging the browser too

Since the article was mainly about icons, such a comment is completely incomprehensible to me. Yes, I myself several times received from the designer terrible icons, which were a pile of primitives stuck on each other. But there’s nothing stopping you from approaching the designer and saying, “What the hell, man ?!”, or fix this thing yourself in the same illustrator, combining it into some common shape (well, this is exactly my case, other “complex vectors ”I have not seen yet). You can also use SVGO for these purposes. Combining into a common shape seems to be the only part that really dramatically affects performance.

In fact, even if you forget about all these things with icons, I can’t imagine any at least minimally frequent case about the “complex vector”. Yes, anyway, a vector, in relation to the tasks of today's web there will be less raster (this is about weight).

We all understand that there are tasks where this still happens, but in such cases, developers think in slightly different categories. For example, you need to display some huge, complex scheme in a small area, and there will be an approach like “something SVG comes out under megabytes, colleague, let's rasterize it on the server”. Tiles are the same on maps.

Then a bunch of users came and spoke extremely negatively regarding the performance of SVG as such. They say everything is disastrously shitty, the desktop browser on 3 and a half SVG shamelessly slows down on the scroll, mobile devices explode in the hands.

In fact, I thought that absolutely in all SVG browsers, sticky via background-image is cached by the most unlikely. After all, are we talking about this particular case? In practice, everything turned out to be a little more complicated.

I talked with a couple of people who work on the SVG part in Chrome and Firefox and showed them this demo that Adrian Osmond did a year ago for, in principle, the same goals. But then everything was much worse. Why, you can read in his article and the webkit bug tracker.

So:

Chrome

FPS sags about one and a half times, two. Sad of course, but not 10x though. So what happens under the hood of Chrome at that moment?
I read the source code on chromium.org a bit, found some caching code for SVG, and it confused me even more. Then I decided to ask knowledgeable people.

Google's Philip Rogers, who basically writes most of the SVG stuff in chromium, said the differences between rendering SVG and PNG are a bit more complicated. Firstly, PNG is decoded in a separate stream, and SVG in the main stream, and secondly, in addition to performance, there are such things as, for example, memory. In general, they decided to abandon cache storage for svg in order to save memory. As for me, this is some dubious plan. I don’t quite understand why not cache this whole thing. Bitmap, which ends the rendering, will not be of any indecent size, with today's memory volumes, even on mobile devices. Well, the vector is coming, a promising topic. But apparently that's why they work at Google, not me.

So yes, in the SVG chrome, every frame is re-counted. True, Philip said that they came up with something there that “should bring it much closer to png performance”. Will be in the next Canary. We'll see. Nevertheless, the performance is at a level slightly lower than 60 FPS (and I generally have such an average configuration) on a huge pile of icons that are simultaneously on the screen - this is quite adequate performance.

Firefox

I don’t know how to measure FPS in FF (I saw some software, but the installation process was not completely trivial and I didn’t bother), but the performance of PNG and SVG is the same. Robert Longson, the SVG contributor to Firefox, also thinks the same. According to Robert, in Firefox there is a cache for all images and the difference between SVG and PNG may consist only in the fact that SVG is a bit longer “decoded” at the first rendering, which is quite natural.

Thus, in FF, we generally have identical performance if we do not perform any manipulations of invalid SVG cache. Naturally, scroll does not invalidate anything. Perhaps there are still some points, but they cannot dramatically degrade performance.

IE

Newer IEs are often very good at all sorts of unobvious places, like WebGL. Here is the same situation. In IE, the demo works much better than in the previous 2 browsers, it shows the same framerate for SVG and PNG. But for some magical reasons, this is not done immediately.

Unfortunately, I do not know who is involved in the development of SVG in IE, and it is doubtful to write such things in a bugtracker somehow, so this part will remain without comment on the other hand.

Regarding things like SVGO - I am pretty skeptical about them. I don’t know how much of a percent rendering will accelerate with a little faster parsing, but in my opinion this is a dubious thing. Those. Of course yes, there is some profit, but minimal.

With the practice of layout SVG, everything is more or less clear. I prefer to draw SVG sprites. The technique is the same as for raster sprites. The problems they solve are basically the same. Naturally there are a bunch of different plugins for these purposes, for example, here .
You can still do this using the data url. Here I recommend this kind of thing and their own software right here , for those whose Grunt process is not included for some reason. Well, you can still directly files on the background-image, but not necessary.

The only modern browser where I saw problems with SVG rendering is IE on Windows Phone. But there this problem is solved.

Iconfonts

If in SVG we can basically draw whatever we want, then with the help of fonts we are limited to monochrome icons (if we do not take into account perversions like stackicons), which, within the framework of current trends in design, does not seem such a drawback. But before us opens up a bunch of possibilities, starting from a banal change of color and size, ending with a bunch of CSS manipulation of fonts, such as shadows, etc.

The technique with icon fonts is more complicated than the same SVG. Here you need to have some knowledge in areas where not every designer is oriented. It would seem business then, cram your SVG-chi into one of a bunch of online packers like the same Icomoon or the mood of some Grunt \ Gulp plugin, and you will be happy.

In the comments on the article, the main accusation regarding fonts was something like

terrible rendering in small sizes (explicit ladders) (c) designiac

What did you guys like? To draw a huge icon of approximately the size of the 48th, to work out small details, then to stick it with the size of the 12th and instead of wondering about some bad render of these terrible web fonts, enjoy perfect clean icons?

Hinting!

Here is the basic thing you need to know about iconfonts. Here it is, the holy grail of web icons! I believe that if you know exactly what we’ll say, the color of the icons or their size will not change (this probably also happens), you need to take SVG and not fool your head. Use fonts unnecessarily - some not very critical of course, but still overhead.

To collect a suitable font we need:

1. icons in vector
2. analog icomoon
3. professional gizmos for working with fonts. I am using FontLab Studio

To make it clear why we need this at all - here is an example: we take the fashionable Font Awesome and with one hint we make the following pinterest icon:



this: This is



best seen on a small size, naturally.

With the advent of the era of HDPI devices, the front-end may not have to bother with these things at all, because hinting the glyph in this situation is a



little more complicated than in this:



I'm not the kind of person who can authoritatively write about hinting, so I won’t do this. I would be glad if a serious typographer comes and writes a detailed article. You just need to take into account the fact that he (hinting) exists. And it’s not fonts that are crookedly rendered, some developers don’t hint them at all, or sculpt auto hints (which, I must say, can save a lot of time at times).

Subpixel Smoothing

Well, all you need to know about subpixel smoothing is what it is. A version ago with this there were problems in chrome, but now everything works as it should.

PNG

The disadvantages of raster graphics with such a need to take into account the HDPI device, which is now - are obvious. Perhaps, if the density were limited to 2 variants of retin / not retin, this would be a worthy option, and few would have thought of bothering with all the ambiguities of the vector that now exist on the web. But we have 1.5x, 2x, 3x devices. And collecting sprites for each of them no longer seems a pretty elegant option.

On the other hand, a lossless raster has a dignity that, for me personally, covers all the shortcomings in service - it is stable. You can be sure that the way you draw the icon - the way it will look in the end. Pixel to pixel. The only question is whether such accuracy is needed in each case.

Total

I am working on a monitoring and control system for all serious equipment, such as electrical substations or boiler rooms. We have a solid pack of icons that indicate certain malfunctions at the facilities. Moreover, these icons are found in different places, of different sizes and different colors. And we would actually kill a lot of time if we did all this in PNG, also under HDPI.

In general, I don’t quite understand why, in the current conditions, I definitely have to give up such delicious techniques as fonts, and the vector as a whole. There are moments of course, like the same decision in chrome to refuse the cache, but in general, everything is in order with the performance and quality of the render. And if you stop theorizing and looking at standard tasks, a couple of cases will come out where you should look in the direction of the raster.

Bet

So, why did I write all this? I offer users who negatively commented on the performance and rendering of vector icons in the post from which it all started, or who sympathize with them and their point of view, bet.

You provide me with a layout or some specific site (which is better), the icons on which are now made up in PNG for both retina and simple displays, the source of the icons of which you have in the vector, which produces 60FPS on any average machine with any effects. Immediately make a reservation that objectively this should be a regular site. Not an online icon management software and not an example from this article.
I replace the raster with a vector and optimize what I want in ways.

The result should be a page on which the FPS sags no more than, say, 30%. We will agree on further conditions in the process. How do you like it? Prove the flaw of SVG?