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.
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.
Explanation:
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
<head>
<title>Logo Test</title>
</head>
<Body>
<div style="text-align:center">
<img src="shape.svg" width="200px" height="200px" onerror="this.src='shape.png'">
</div>
<div>
<p>
Loaded with fallback.
Loaded with fallback.
Loaded with fallback.
Loaded with fallback.
Loaded with fallback.
Loaded with fallback.
Loaded with fallback.
</p>
</div>
</Body>
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" />
</object>
</div>
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;">
</div>
</div>
I did lighthouse performance audits (for mobile) and here are the results:
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).
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.
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
