Scalable vector graphics (SVG) have been around for a while. In fact the standard has been developed since 1999! But their use on the web has been a bit hit and miss until the last few years., with the usual suspects often causing a nuisance - looking at you Internet Explorer.
In the past I’ve tended to shy away from any web standards which do not have good support across all major browsers. However since the death of Internet Explorer, browser development seems to generally be going at a good consistent pace, with most browsers keeping up with each other.
Now, SVG has great support. And finally with this website I better explored its use.
SVGs, as per their name, are SCALABLE. This means no matter what size you view them at, they should have clean lines and no pixelation. The exception being if an SVG includes any raster graphics such as PNG or JPEG.
Being scalable means there’s not a huge amount of work required for an image to be optimised for different screen sizes. With raster graphics, you can end up needing multiple versions of the same image optimised for different screen sizes, pixel densities, and even internet speeds.
You can load an SVG file into a page the same as any other image, by using the tag. This makes it easy to pick up and use without any extra effort. However you can also embed SVG directly into a page’s code!
The logo top right, share icons, and Primebox logo in the footer are all SVGs. If these were PNG, they would likely be three separate files, or a cumbersome sprite sheet.
SVGs are XML based, as is HTML, meaning they sit together quite neatly. By embedding SVG, you remove the need for a separate SVG file, which reduces the number of requests, which can help website performance. However this does have a downside as well.
I’ve been exploring this with a couple of other projects, which I may talk about in a future post.
The cons… or just con
Maybe it’s because I’ve not been using SVG for too long, but I’ve only come across one con for SVGs so far, which is to do with embedding them.
An SVG as a separate file can be cached by the browser. An embedded SVG cannot, unless part of the whole page HTML being cached. This means that every time a page is requested, the SVG code is downloaded again.
This isn’t inherently bad. I think for small SVG files this is ok, as it has minimal impact on overall page size. But for larger SVGs I can see the potential for web pages potentially getting a bit sluggish.
The embedded SVGs on this website take up less than 6kb combined, which is miniscule. Going forward I fully intend to take advantage of the power of SVGs!