82

I'm currently building a website aimed at modern browsers and mobile devices. In terms of performance, is it better to inline SVG's directly inside the HTML using <svg> or is it better to use <img> and/or background-image instead. I run gzip on the server to further compress my content and prefer not to rely on Javascript.

General Grievance
  • 4,555
  • 31
  • 31
  • 45
Dave
  • 7,283
  • 12
  • 55
  • 101

5 Answers5

64

Pros for inline:

  • Fewer http requests;
  • You can use css fill property and change the color;
  • Svg is part of the content, so it is clickable and you can insert text;

Pros for separate file:

  • Svg files can be cached;
  • You don't see multiple lines of irelevant code in your files;
  • If you need to change it later then you just change one file;
Claudiu Creanga
  • 8,031
  • 10
  • 71
  • 110
  • So if I only have to change the height of svg, I could just go with sourced to svg file and just change height of the img, or am I doing it wrong? – Samiullah Khan Aug 30 '18 at 08:41
  • 8
    Svg files can be cached; >> HTML can also be cached. You don't see multiple lines of irelevant code in your files; >> You could make a file seprate file give it a name like you would for the svg and use include for php to import it on the place you want it. If you need to change it later then you just change one file; >> See above. – Roy van Wensen Oct 29 '18 at 15:23
  • 8
    @RoyvanWensen html changes more often than images so it is better to cache images separately. Also you have the same svg icons used in different html pages so you only need to cache it once. – Claudiu Creanga Oct 29 '18 at 16:00
  • 1
    Also, if you inline your SVG, it needs to be downloaded before the browser gets to subsequent content. Whereas if it's an external resource, the browser can download it in parallel and control priorities. This distinction doesn't matter as much with tiny SVGs. – JaffaTheCake Jul 22 '19 at 08:05
  • @JaffaTheCake - Do you mean that similar to CSS or JS, inline SVG is a blocking resource? – Motivated Nov 19 '20 at 08:11
  • @Motivated all inline content blocks the thing that comes after it, as the inlined thing needs to be downloaded in order to get to the content afterwards – JaffaTheCake Nov 20 '20 at 09:54
  • @JaffaTheCake - Sorry, I'm confused. My understanding is that any inline content is downloaded and interpreted as part of the browser reading and executing the DOM. If yes, why would an inline SVG be a blocking resource if it is base64 encoded? – Motivated Nov 26 '20 at 22:09
  • @Motivated if I have a 30 byte reference to an external image, followed by 30 bytes of text, the browser has to download 60 bytes to display that text. If I have a 100k inlined image, followed by 30 bytes of text, the browser has to download over 100k to display that text. The inlined image is effectively blocking. – JaffaTheCake Nov 28 '20 at 11:05
  • @JaffaTheCake - Righto. I am assuming that although an image may be larger in size if inline, the browser processes it faster versus establishing another connection, download the resource and parsing it. – Motivated Nov 28 '20 at 18:37
  • @Motivated an external asset shouldn't need another connection if you're using HTTP/2 and the same host. But yes, with inline, you don't have the request/response overhead, but you do get the blocking behaviour. – JaffaTheCake Nov 30 '20 at 10:31
  • @JaffaTheCake - Thanks. I imagine that even if it's the same host that there would be the overhead of a DNS request/response. – Motivated Nov 30 '20 at 17:49
  • @Motivated you wouldn't need to go via DNS if it's same origin. The existing HTTP/2 connection would be used. – JaffaTheCake Dec 03 '20 at 15:01
  • @JaffaTheCake - Thanks Jake. Can a connection to a server be primed so that when you make a request, it's in memory? – Motivated Dec 04 '20 at 23:45
  • @Motivated yep, you're looking for `` – JaffaTheCake Dec 10 '20 at 15:19
52

There is no universal approach. It really depends on many things, but here some basic strategies which can be used separately or combined.

If we have:

  • Small number of SVG(s) with < 5k file size each–inline them in HTML. Compressed gzip/brotli each will be around 1k. Any small number multiplied by 1k is better than same number of additional requests, no matter cached or not.

  • Huge number of small SVG(s) < 5k - Make SVG sprite

  • Any number of big SVG(s) > 5k and let's say we do not need to access SVG properties via CSS or JS. Then <img src="name.svg">

  • Any number of SVG(s), but we do need to use CSS to change a SVG property or lets say animate some SVG property. The only viable option is inline svg.

  • If we need SVG(s) for backgrounds but they are < than 5k each:

    .bg { background: url('data:image/svg+xml;utf8,<svg ...> ... </svg>'); }

  • If we need SVG(s) for backgrounds but they are > than 5k each:

    .bg { background: url('images/file.svg'); }

  • I have never had a chance to try SVG sprite as background, but it is an option too

mherzig
  • 1,528
  • 14
  • 26
user2170348
  • 546
  • 4
  • 4
  • About SVG in a `.css` file, i.e. `... background: url('data:image/svg ...` — is the reason you recommended against this for > 5k SVGs, that then, if the CSS changes, all that > 5k SVG will get downloaded again together with the modified CSS? Or did you have in mind other reasons too? — Thanks for this detailed answer :- ) – KajMagnus Aug 09 '20 at 14:37
  • Does 15 is a small number? Also "Any small number multiplied by 1k is better than same number of additional requests, no matter cached or not." does that mean 15 * 1k is better than one request with 15k? Thank you very much. – alancc Aug 24 '21 at 22:50
  • Unless you're in a almost-0 latency lab network, even one 100K request is much better than 10 10K requests. There are modules that exist for Apache Http proxy, and others, that essentially "inline" significant number of href'd resources on the origin server and then transmit the combined response to the user-agent. Unless you can rely upon such a network device, the strategy recommended above is a good one. Cheers! – R.G. Feb 10 '22 at 22:02
27

Inline SVGs would reduce the number of HTTP requests, so it should make the page load faster the first time someone's visiting. But the drawback is that your SVGs won't be cached in the browser and therefore it will have to be loaded every time. I'd say if you're only using a few SVGs (like 10 or so), inline them; but if you have many, go with img+background-image.

You may also want to consider using SVG definitions and using the SVG use tag to reference SVG definitions. This method is pretty good; especially if you need to repeat an SVG multiple times in your page. More info on this technique: http://css-tricks.com/svg-sprites-use-better-icon-fonts/

My web app can also help you easily make these SVG definition & use pairs.

Keyamoon
  • 1,785
  • 17
  • 16
7

Claudiu Creanga, you are correct on most, but not on the last one :)

Concerning file SRC: "If you need to change it later then you just change one file;"

The file can be a separate SVG as Inline also. Just include the XML/text source via PHP for instance:

<?php include_once($_SERVER['DOCUMENT_ROOT'] . '/img/icon-home.svg'); ?>

I'm using this tactic since I do CSS3 animations on my icons. This way you have the original reference file for modifying in a vector program and simple upload will fix all inline code. Object and path ID's inside the SVG won't change if you just rearrange or manipulated them.

Magnus72
  • 99
  • 1
  • 3
0

Being able to cache SVGs is a big reason to include them as images. What I love doing is including them using CSS masks - this is for me the perfect cross between a true image and the ability to change the color of the icon like I would if it was inline SVG. This results in icons that are easily controlled through CSS classes, can be customized, and don't bloat the code at all.

Reference for this method: https://equinusocio.dev/blog/accessible-icon-buttons-with-masks-and-svg/

Hannah Beasley
  • 36
  • 3