SVG: a resource hog ?

[lotus321]

I love the concept of SVG and have finally begun to learn it.

 

However, my background is in full-stack app design, not web design, and I wanted to know if browser's struggle to load them ?

 

Aside from browser support and a decent connection, I am concerned with how much of a resource hog SVG are ?

 

To me it's just text, so it should load instantly, but, of course, processing animations make wonder if the page will noticeably slow down ?

 

Is there such a thing as too much ?

[Vishera]

SVGs are a resource hog.

I tried to convert a photo to SVG and the performance was terrible.

[igormp]

26 minutes ago, lotus321 said:

I love the concept of SVG and have finally begun to learn it.

 

However, my background is in full-stack app design, not web design, and I wanted to know if browser's struggle to load them ?

 

Aside from browser support and a decent connection, I am concerned with how much of a resource hog SVG are ?

 

To me it's just text, so it should load instantly, but, of course, processing animations make wonder if the page will noticeably slow down ?

 

Is there such a thing as too much ?

No, most browsers can accelerate your SVG rendering through your GPU, so that's a non-issue. Even if hw accel is disabled for some reason, modern CPUs should render it fast enough.

 

8 minutes ago, Vishera said:

SVGs are a resource hog.

I tried to convert a photo to SVG and the performance was terrible.

Converting an image is not the same as just rendering it.

[Needfuldoer]

24 minutes ago, Vishera said:

SVGs are a resource hog.

I tried to convert a photo to SVG and the performance was terrible.

SVG works best for icons, logos, and other simple graphics. 

 

Why would you convert a photo to a vector format? At best you'll just turn it into an array of billions of squares...

[trag1c]

Not a web developer (primarily bare metal, RTOSs, embedded Linux and the occasional PLC) but my schooling was heavily focused on web. 

 

I would say that it depends. You need to balance several factors such as file size, processing time and use of the image. This combination is what determines site usability and SEO. If a page is slow to load it will get a lower SEO score and be moved down the list. If a file takes forever to process and your site won't be usable. If you're image doesn't need to be scaled then there isn't much point to using SVG unless you know that the image fits the format.

 

For things like logos that are typically based on shapes and as such can be easily represented in a mathematical format, SVG is perfect. The processing time will be minimal, the file will be extremely small and it is scaleable without data loss. It's an absolute win on all aspects.

 

If you try to do something like a very busy photo as SVG you're going to have a bad time. The file is going to be large and difficult to process since you're now into the territory of many shapes and colors that need to be represented. This will take a long time to rasterize and it potentially could be much larger than the equivalent raster image. Remember that each text character is at least byte. Integers that could normally could be stored in 4 bytes could be 11 bytes in size as example, that's 1 byte short of a 3 RGBA bitmap pixels.

 

JPEG may be a shitty lossy format but if your images don't need to be scaled or animated, it's super cheap to process and very small. This makes it good for both SEO and site usability. Great for things like thumbnails where they're small enough where detail isn't important.

 

PNG has the benefit of being lossless so you have higher image quality and its still relatively cheap to process. Great for things like product photos or other larger images.

 

Everything is a big balancing act. Too much data to load and your SEO will drop (also more hosting costs), to much time spent processing and your website will run like crap and no one will want to use it. Experiment and figure out what works best for your projects.

[lotus321]

Thanks for the replies.

 

I'm not interested in big graphics, mostly icons, avatars and other small niceties like accent design pieces, interactive graphics, or progressive illustrations as the user scrolls through a story.

 

I plan to utilise SVG because it can react with its surrounding, or with input, where rasterised imagery cannot, which is why I am concerned over performance.

 

I am surprised about SEO, surely this could be embedded into a text based format like SVG ? I found out a long time ago that SVG could react to differing screen sizes, surely they can be found with web crawlers ?

 

"Remember that each text character is at least byte. Integers that could normally could be stored in 4 bytes could be 11 bytes in size as example, that's 1 byte short of a 3 RGBA bitmap pixels."

 

Interesting, UTF-16 is double that, and so it doesn't take much to reach 1MB !

 

https://stackoverflow.com/questions/4850241/how-many-bits-or-bytes-are-there-in-a-character

 

SVG is pretty verbose, but there are tools to truncate it.

[trag1c]

2 hours ago, lotus321 said:

I am surprised about SEO, surely this could be embedded into a text based format like SVG ? I found out a long time ago that SVG could react to differing screen sizes, surely they can be found with web crawlers ? 

You have to remember there's a lot more to SEO than indexing a site and looking at metadata. Google has a lot of documentation to read through about SEO. One big metric is how fast the page loads and how fast it becomes responsive. You can view this with this tool from Google.

 

Page insights

 

So with large files comes longer load times since more data has to be sent from the server to the client. So generally what will happen a lot is asynchronous/on the fly loading. So you will send a super barebones version of your page and then load content in with JS so that your page "loads" and becomes responsive as fast as possible.

 

CDN networks that are physically closer to the client are common as well. This is beneficial since HTTP/HTTPS utilizes TCP which has error checking and a lot of back and forth communication. This back and forth really adds up when sending a lot of data as everything is round trip. A lot of extra packets and latency.

 

2 hours ago, lotus321 said:

Interesting, UTF-16 is double that, and so it doesn't take much to reach 1MB !

 

https://stackoverflow.com/questions/4850241/how-many-bits-or-bytes-are-there-in-a-character

 

SVG is pretty verbose, but there are tools to truncate it.

Both UTF-16 and UTF-8 also suffer the problem of they might require multiple bytes (up to 4 for both) to represent every possible character. This can be messy to deal with since the number of encoded characters can differ by from the string length since multi byte character exist. E.g it may take 3x UTF-8 bytes to encode a specific character or 2x UTF-16. So you're text file might end up even larger than you expect

 

You also have UTF-32 which uses 4 bytes to encode a character. This has the benefit of being able to encode every character using only a single variable but you waste a lot of memory for characters that are less than 4 bytes. I never actually seen this used though.

 

However multi byte characters are generally not an issue unless you're using special characters or dealing with localization. So in a file describing a vector image it shouldn't be a problem.

 

In my day job strings/text are generally a nightmare to deal with since they're extremely constrained systems (24MHz with 16KB RAM microcontroller and a 60MHz MPU with couple hundred KB of RAM are our slowest chips.) Every byte counts as well as the way you interact with strings. One wrong move and you can end up copying your entire string buffer which has a worst case time complexity of O(n). It's capable of killing performance on the desktop so on a pitiful 16bit processor it's absolutely devastating lol.

[Sauron]

5 hours ago, Vishera said:

I tried to convert a photo to SVG

This makes no sense conceptually. There is no information in a photo that can be meaningfully converted to an svg. The converter probably just embedded the image as-is inside the svg file, which yes would hurt performance.

[Vishera]

5 hours ago, Needfuldoer said:

Why would you convert a photo to a vector format? At best you'll just turn it into an array of billions of squares...

 

23 minutes ago, Sauron said:

This makes no sense conceptually. There is no information in a photo that can be meaningfully converted to an svg. The converter probably just embedded the image as-is inside the svg file, which yes would hurt performance.

There are different algorithms and methods for such conversions.

 

The reason why one would prefer a SVG image is the sharpness of the image at any size.

 

Shape based conversion:

f2177bee478ccad2eb24c9568fc8894c.svg

Pixel based conversion:

2022_05_28 (2).svg

[Sauron]

31 minutes ago, Vishera said:

The reason why one would prefer a SVG image is the sharpness of the image at any size.

 

Sure, but you can't invent information - or you can't necessarily do it well. If it's a picture of a straight line it might work but a normal photo you might take with a camera isn't going to be easily convertible...

[Franck]

4 hours ago, Sauron said:

The converter probably just embedded the image as-is inside the svg file, which yes would hurt performance.

There is 2 options. If you embed the image in the SVG it simply render the image using the original graphic renderer and you have no performance impact. If you start playing with transformation or animation they are managed completely by the SVG renderer which is very slow overall.

 

second option is you can trace bitmaps as svg so it wont be an embed image in the svg. It can convert to lines and polygons. At worst like someone else mention it could create 1 square per pixel in vector. It will be a bit slower performance but not that much UNLESS you start playing with transformation or animation then performance will drop exponentially.

Some basic tool usually allow to trace bitmap with reduced palette which allow "close enough" color to be the same and merge as larger regions to make it with less shapes.

[lotus321]

That's right, the same with memory management on 64-bit apps, it's just a waste sometimes, as with your UTF-32 example.

 

I am only looking to serve the desktop/smartphone accessible market, a little be more than the KB range

 

I've only ever come into contact with SEO through Squarespace, where much of what you write is refactored away. I am sure there is much to explore..