23MB of HTML with 140 inline SVGs means that each of your SVGs is very complex, over 160KB on average! Why do you have so many SVGs on the same page, and could you replace them with small thumbnail images?

@MaximillianLaumeister I cannot, It's a huge ERP application with many over 50 icons and each of those icons contains an average of 2-3 SVG images, plus I am required not to do so and would that effect on performance though?

Why not use external SVG? Using external resources can reduce time because you will get files parallel multiple at once. get 23MB for only 1 page HTML is too big. and also dont forget to use brotli compression.

Are the SVG images already optimized and compressed?

@StephenOstermiller Some are, but some can't be i.e. don't need to be.

@MuhammadDyasYaskur Wouldn't external SVG send seperate http request increasing even more loading time? Also, I have no idea what brotl compression is, mind sending any reference links or something about that?

I just noticed that the SVG is 140. But you could optimize it by using a lazy load image. stackoverflow.com/questions/49040771/…

for brotli it's depend on your server, what server you used now?

@MuhammadDyasYaskur I am using HostGator's hatchling 2000 plan with shared hosting.

But I think the better solution is convert the SVG to png or jpg, as you said its just icons, so only need a small image dimension.

@MuhammadDyasYaskur Should I include a screenshot of the page to show the size of those icons?

@MaximillianLaumeister in the context of SVGs 160kB isn't large. I came here interested because I've dealt with single SVGs of over 20MB and was hoping for some tips; my data graphs can easily be a couple of MB each (that could be optimised down but not by most tools; some stuff is present but clipped)

Your "small screenshot" appears to show a much more resource-intensive page than the one discussed in the question? "158 requests" / "39.0MB resources" / 5+ minutes?

@MrWhite Well, It is quite variable, you see sometimes It's 2-3 minutes and sometimes It's well over 5 minutes as well.

@ChrisH In that case, since you are much more experienced with SVGs and have handled the ones with 20MB+ size please give me more tips as an answer, I would be really thankful. :D

@SyedMohammadSannan SVGs are more my thing than webservers, by far. I could make some suggestions about optimising SVGs, but nothing about serving them. Before embedding at least try passing them through SVGO as stated in the top answer (there are GUIs, but you'll want to script this, and you'll have to try various options). Logos and icons are often drawn at large scale, with excessive precision in numbers (coordinates). It really is worth hitting the source files as hard as you can.

BTW are they all unique, or are you embedding duplicates? If the latter are you sure the page isn't downloading the same image twice? Like I said, I'm not an expert in web delivery, but the answers to this SO question have more detail (I'd be using img tags referring to separate SVG files anyway)

It is most likely the rendering of the complex svgs that slow down. Also note that in a single page may make loading less efficient if they are rendered in loading order.

@ChrisH Oh like I said before in my case aren't images but inline-SVG vectors which are directly inside the HTML code using the <svg> tag in HTML.

@ThorbjørnRavnAndersen In that case can you give me suggestions on how to speed up the rendering, etc. you are talking about? I am most welcome for any new answers.

@ChrisH But I will try to use the Python html parser to convert those SVG tags into separate .svg files so then more optimizing, etc. could be done, though I almost no idea on how to use Python's html parser library to extract each <svg> tag from the HTML file and turn them all into separate numbered .svg files.

So you're assembling images from multiple <svg> tags on the fly? That sounds inefficient at this scale but it's getting beyond me. The chances of identical <svg> tags being downloaded repeatedly would seem very high. Even just the tags themselves account for some of your overhead, before you get to any actual content.

make your svgs simpler, and load them in parallel. Check cpu usage while you load your page.

I can only support the top answer, noting that caching of likely duplicates should be better with files rather than inline.

I see, thanks to everyone for all the help and I will try all the suggestions given.