I know this has been asked multiple times, but I really could not find an answer.

I have a relatively small logo (icon) and I need to load it multiple times on specific places. I was wondering: should I create an svg (I tried, it's 26kb) and use <object> to load it? Or perhaps <img> to load the .svg file?

Or should I go for plain old background-image? I do not have alt related concerns, so it's purely about performance/speed here.

3 Answers 3


Short Answer: There will be no difference in the perceived performance between the three implementations (img, object and background-image). But when you use png fallback along with svg, img method can save you a network request.


I did a simple test on all the three implementations suggested in https://stackoverflow.com/questions/4476526/do-i-use-img-object-or-embed-for-svg-files

I used a svg logo and its fallback png in the tests. The sizes were in the range of 30 to 40 Kb.

The HTML page I used for testing had just two parts - the logo and a single paragraph of text.

Case I: Use of img tag

  <title>Logo Test</title>
  <div style="text-align:center">
    <img src="shape.svg"  width="200px" height="200px" onerror="this.src='shape.png'">
  Loaded with fallback.
  Loaded with fallback.
  Loaded with fallback.
  Loaded with fallback.
  Loaded with fallback.
  Loaded with fallback.
  Loaded with fallback.


Case II: Use of object tag

Note: From here on, I am just showing the varying (implementation) part of the HTML document from the previous one.

  <div style="text-align:center">
  <object data="shape.svg" type="image/svg+xml" width="200px" height="200px">
    <img src="shape.png" />

Case III: Use of background-image

  <div style="text-align:center" align="center">
  <div style="background-image: url(shape.png);background-image: url(shape.svg), linear-gradient(transparent, transparent);
  background-size: 200px 200px;margin:auto;width:200px;height:200px;">

I did lighthouse performance audits (for mobile) and here are the results:

svg implementation audit resutls

In the above table, img1 and img2 correspond to two runs of the case I and so on.

Why These Results

I don't think the logo is going to affect most of the metrics other than FCP (if at all).

For example, LCP or Largest Contentful Paint measures the time taken by the largest element to become visible in the viewport. A logo is usually small and doesn't figure in the LCP calculation. In my case, the paragraph was considered by Lighthouse.

Also a simple static SVG image with explicit height and width isn't going to cause a shift in layout. (My other element was a static paragraph.)

Now let us discuss FCP

FCP or the time taken for the first DOM element to become visible wasn't affected as well. Let us assume Chrome considered the logo for FCP. Chrome renders small SVG images implemented by any of the three methods at almost the same speed and any differences are negligible as shown by results.

Lighthouse performance metrics are synonymous with the perceived speed by visitors. Hence, there is no difference between the methods.

Network Request Saved:

I then checked waterfall for the above three implementations. When using the object and background-image methods, Chrome loaded both SVG and PNG images. However, for the img method, just SVG was loaded. (I believe, the onerror event will be triggered only if the browser is unable to load the SVG - unlikely for modern browsers).

  • Amazing, thank you Kannan! When checking your stats, I saw that the background image loads faster, but equally blocks more as well. So, what to choose here? I am now doubting between static image and background-image...
    – Siyah
    Jul 1, 2021 at 13:22
  • I think those differences are negligible. But background images don't get indexed (if I remember correctly). I think most sites would want logos indexed as well (handy when someone does a brand name search in Google Images). Hence, I would prefer img.
    – Kannan
    Jul 1, 2021 at 13:29

I think the optimal solution for speed would be to serve a compressed (svgz) file directly inside of an image tag. Using an image tag would at least keep your html semantic and would allow crawlers to understand that it is an image. I would only use a background-image for purely decorative purposes.

26kb is quite large for an SVG, I'm assuming that it isn't optimized (full of cruft probably). Serving a svgz file might make it comparable or smaller than a small png. A small png (like 2kb for example) would obviously load faster otherwise.

For SEO the initial load time of the page is what matters. However if you want to go beyond just SEO to perceived speed, I would put that file into a service worker cache for repeat visitors.

  • Thanks Lee! But how does the svg and image work? I mean, the SVG still needs to be loaded and in your case, the image would be some kind of placeholder. Wouldn't this be slower than e.g. background-image with plain image?
    – Siyah
    Jul 1, 2021 at 13:24
  • I meant you set the path of the image to the svg file. I didn't mean inline the svg code into the html, if that's what you mean by "placeholder." The svg will load just like a raster format (jpg, png, etc) and will scale and look good regardless of what screen size it's viewed on. You would probably have to adjust your css to control the size and such. It will get cached by your browser like any raster alternative, but it has the benefit of being the only file being cached. If you were using png or jpg for logos you might need to use srcset for multiple images of different sizes.
    – leecalvink
    Jul 2, 2021 at 20:47
  • If you were looking for pure speed, you can inline the svg code directly into the html. However this wouldn't be cache-able and would add a small bit to your page that would need to be loaded each time.
    – leecalvink
    Jul 2, 2021 at 20:52

One of the most effective ways to determine which image resources to use it checks the Google developer tools: PageSpeed Insights. This tool analyzes the entire page and all aspects including images types and formats will get some particular rate from this tool.

When we checked all our pages google suggest optimizing some images to make them smaller or use SVG or JPG in some particular cases.

So it was pretty informative and helpful. This tool helps us to level up our optimization rate to 97

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.