13

I have a webpage that is full of inline-SVG around 140+ inline SVGs! Just the HTML file size is 23MB, plus there is external CSS and JavaScript loading, though that is roughly only around 30KB. The real deal is the HTML file itself with thousands of lines of code mostly consisting of SVGs.

My webpage takes 2-3 minutes to load up on my (probably) average internet, how can I reduce the loading time while especially reducing the file size of the HTML file? I don't think using separate SVG files for the images would be any better because that would take even more time to load because of separate HTTP requests.

Is there any way for me to shorten the loading time from the current 2-3 minutes to under 5 seconds?

A small screenshot from the Networks panel in Chrome Dev Tools:

enter image description here

Syed M. Sannan - alt
  • 41
  • 2
  • 11

2 Answers2

42

From what you've stated in the comments (now chat), I understand that you cannot reduce the size of these SVG files, you cannot replace them with thumbnails (e.g. small png files), and you cannot split them up onto multiple pages. In other words you are stuck with a web page that has 23MB worth of SVG files on it, and there's no way to change that.

That leaves you with only a few options left:

  1. Make sure your server is properly compressing these files using gzip or brotli compression. You can check whether your server is properly compressing these files by following this Stack Overflow answer. SVGs are highly compressible, so this is a critical step. This alone could improve loading time by over 50%, if your server is not already doing this.

  2. Make sure these SVG files are properly optimized and minified, using something like svgo (and SVGOMG gui). This could save maybe another 20-40%.

  3. Consider linking the SVG files externally by using img tags, and use the loading: lazy directive on them. Then, at least the loading of the images will be deferred until the user scrolls down the page. (If, as you stated in the comments, your images are not initially visible in the viewport but are later shown dynamically by JavaScript, loading: lazy should still prevent them from loading until they are viewed, because it "Defers loading the image until it reaches a calculated distance from the viewport, as defined by the browser." Alternatively, you can modify your JavaScript to prevent the SVG tag from loading in at all until the script is triggered.)

If you link the SVG files externally by using img tags, that also has the added benefit of letting your HTML load to completion before the SVG files begin loading in. So parts of your HTML that are located below the SVG embeds in the document, like the footer, will load in before the SVGs finish.

To answer your concern about external SVG files generating separate HTTP requests that increase load time, this is not something you should need to worry about if your server supports HTTP/2 (so follow this Stack Overflow solution to double check that it's enabled). If so, all requests will be multiplexed over a single TCP connection.

Maximillian Laumeister
  • 16,461
  • 3
  • 32
  • 63
24

I don't think using separate SVG files for the images would be any better because that would take even more time to load because of separate HTTP requests.

Efficient handling of linked images is something that browsers are specifically designed to do well. By inlining 23 MB of data in the HTML, you're blocking those optimizations.

If you split the icons to individual files, then the browser will cache individual icons and avoid redownloading them when the same icon is used repeatedly, on the same page load and on separate page loads. The browser will also be able to display the full text of the page before receiving all the images, which will improve the user experience.

Also, your SVGs are overcomplex for rendering at typical icon size. 23 MB for 140 images is an average of 168 kB per image. How big are they displayed? A small icon, 32×32, at 3 bytes per pixel is 3 kB even as a completely uncompressed raw bitmap. A larger icon, 128×128, at 3 bytes per pixel, is a 48 kB raw bitmap. And uncompressed is the most pessimistic scenario to compare against. The point is, your SVGs contain more detail than you can possibly see at icon size. If you prerender them to PNGs, it will look identical but be dramatically smaller and lighter.

If you have the option to change the icons, you could also experiment with a different icon style. The current vogue is a flat iconographic shape with one or two colors, which happens to compress much smaller than a glossy gradient skeuomorphic icon. Changing the entire icon style is probably not necessary to fix your current performance problem, but if you needed to support very slow connections, it would help.

Boann
  • 341
  • 1
  • 3