SVG, Iconfonts vs PNG

Article based on Images in the layout. Stop tolerating it . Rather, even based on the comments on this article and the general reaction of 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 that year. On this occasion, we consider in more detail the existing techniques of 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 a raster, in particular PNG, has not gone anywhere. True, some nuances were added with the advent of a heap of HDPI devices with completely different pixel density.

Svg

The most violent reaction was caused by the use of SVG. First, 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 dealt mainly with icons, such a comment is completely incomprehensible to me. Yes, I myself several times received horrible icons from the designer, which were a jumble of primitives stuck together. But nothing prevents you from approaching the designer and saying, “what kind of garbage, man ?!”, well, or fix this thing yourself in the same illustrator, combining into some common shape (well, this is specifically my case, other “complex vectors ”I have not seen yet). Even for these purposes, you can use SVGO. It seems to be a combination in a common shape - this is the only part of it that really dramatically affects performance.

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

We all understand that there are tasks, where it does happen, but in such cases, the developers think in several other categories. It is necessary, for example, to display some huge, complex scheme in a small area, well, there will be an approach like “something SVG-ha for megabytes goes out for us, colleague, let us rasterize it on the server”. The tiles are the same on the cards.

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

In fact, I thought that absolutely in all SVG browsers, stuck through the background-image is cached for the most undesirable. We're talking about this particular case, right? In practice, everything was a bit more complicated.

I talked to a couple of people who deal with the SVG part in Chrome and Firefox and showed them this demo, which 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 webkit bug tracker.

So:

Chrome

FPS sags about a half, two. Sad of course, but not 10x yet. So what happens under the Chrome hood at this 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.

Philip Rogers from Google, which generally writes most of the cases with SVG in chromium, said that the differences between drawing SVG and PNG are somewhat more complicated. Firstly, PNG is decoded in a separate stream, and SVG in the main, and secondly, in addition to performance, there are also such things as, for example, memory. In general, they decided to refuse to store the cache for svg in order to save memory. As for me - this is some kind of dubious plan. I don't quite understand why not cache this whole thing. Bitmap, which ends the render will not be some indecent size, with today's memory, even on mobile devices. Well, the vector is coming, the topic is promising. But apparently, therefore, they are working on Google, not me.

So yes, in the SVG chrome each frame is re-counted. True Philip said that they invented something there that “should bring it much more to png performance”. Will be in the next Canary. We'll see. Nevertheless, the performance at a level slightly lower than 60 FPS (and I generally have an average of such a config) on ​​a huge pile of icons on the screen at the same time is quite an adequate performance.

Firefox

I do not know how to measure FPS in FF (I saw some kind of software, but the installation process was not completely trivial and I did not bother), but the performance of PNG and SVG is the same. Robert Longson, SVG contributor to Firefox, also thinks so. According to Robert, Firefox has a cache for all images and the difference between SVG and PNG can be but the fact that SVG is “decoded” a little longer when it is first drawn, which is quite natural.

Thus, in FF, we generally have identical performance if we do not perform any manipulations of invalid SVG cache. Naturally, the scroll does not invalidate anything. Perhaps there are still some moments, but they can not worsen the dramatic performance.

IE

Newer IEs are often very good in all non-obvious places, such as WebGL. There is the same situation. In IE, the demo works much better than in 2 previous browsers, it shows the same framerate for SVG and PNG. But doing this for some magical reason, not immediately.

Unfortunately, I don’t know who is developing SVG in IE, and it’s dubious to write such things to a bugtracker, so this part will be left without comments from the other side.

As for things like SVGO, I’m rather skeptical about them. I don’t know at what percentage of the percent the render 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 this purpose, for example, here .
You can also do this with the data url. Here I recommend just such a thing and their software here , for those in whose Grunt process is not included for some reason. Well, you can still directly files on 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, in principle, draw everything your heart desires, then using fonts are limited to monochrome icons (if you don’t take into account perversions like stackicons), which doesn’t seem such a drawback to the current trends in design. But before us opens a lot of opportunities ranging from the banal change of color and size, ending with a pack of CSS manipulations with fonts, such as shadows, etc.

Technology with icon fonts is more complicated than the same SVG. Here you need to have a certain amount of knowledge in areas where not every designer is oriented. It would seem that the case, put your SVG-hee in one of the heaps of online packers like Icomoon or the mood of some Grunt \ Gulp plugin, and you will be happy.

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

rendering awful in small sizes (obvious ladders) (c) designiac

What did you guys want? Draw a huge icon of approximately 6 pt. So of the 48th, work out the small details, then stick it with the pt. So the 12th and instead of wondering about some bad rendering of these terrible web font, enjoy the perfect clean icons?

Hinting!

Here is the basic thing you need to know about iconfonts. Here it is, the holy grail of icons on the web! I think that if you know for sure what we say, the color of the icons or their size will not change (it probably happens that way), you need to take SVG and not fool your head. Using fonts unnecessarily is not very critical, of course, but still overhead.

To collect a suitable font, we need:

1. icons in vector
2. analog icomoon
3. professional gizmo for working with fonts. I use FontLab Studio

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



like this:



Best seen on a small point, naturally.

With the onset of the era of HDPI devices, the front-end probably won't have to bother with these things at all, because to hint the glyph in this situation:



slightly more complicated than this:



I am not the person who can write authoritatively about hinting, so I will not do this. I would be glad if a serious type designer comes and writes a detailed article. You just need to take into account the fact that he (hinting) exists. And it’s not the fonts that are crookedly rendered, it’s some developers don’t hint them at all, or they mold auto-screws (which, I must say, save time well).

Subpixel anti-aliasing

Well, all you need to know about subpixel anti-aliasing is what it is. A version ago with this was a problem in chrome, but now everything works as it should.

PNG

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

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

Total

I work on a system to monitor and control all serious equipment, such as electrical substations or boiler houses. We have a solid pack of icons denoting certain faults on objects. 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, to definitely abandon such tasty techniques as fonts, and the vector as a whole. There are moments of course, like the same solution in chrome to give up the cache, but in general, with performance and render quality, everything is in order. And if you stop theorizing and look at the standard tasks, then in general there will be a couple of cases where you should look towards the raster.

Bet

So, why did I write all this? I offer to users who have negatively responded about the performance and rendering of vector icons in the post that started it all, or who sympathizes with them and their point of view, with a bet.

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

The result should be a page on which the FPS sags no more, say, 30%. We will agree on further conditions in the process. How do you? We prove SVG flawed?