I am wondering about the use of option sets and images. I use a lot of SVG images as icons to have some custom icons for my apps. I previously used data types to store them, as they are usually connected to ‘options’ users would have on products such as product type.
Recently I did a quick and dirty test by having a set of 50 in an R.G. load as a data type and compared that to the load speed of the same 50 as an option set.
The option set was hands down faster, like about 4 seconds faster.
Now I have migrated a lot of these to be option sets and on a review page I use a set of four different types of option sets, one has 13, another 6, one other is 40 and the last is 50 different items in each. Each also has 3 different images (all SVGs) used as icons and the reason being they are different colors.
What I am getting is messages from bubble referencing speed optimization. It states that the downloading of images is slowing down my app performance and to optimize I should consider showing less or making the images smaller. These images are SVGs and have a very small size individually.
My understanding of option sets were they do not touch the database (ie: do not need to be downloaded from the database) and that they essential were browser side or something like that. This is what makes them faster to load.
If that is the case, why would having images affect the speed at which they are loaded? Are they still needing to download those images and so still having to touch the database to retrieve them and thus not really acting browser side?
If my SVG files are so small, why would there still be a concern of speed optimization. These file sizes are pretty tiny, and even though I am loading a considerable number, it still seems like they shouldn’t really affect the speed overall. After all, at these sizes, the total 120 or so I am loading on the page would still only average to be less than this one normal image.
When I load the image above I get no performance warnings.
This message is intermittent, hence the reason I do not have a screen shot of it as I can’t for the life of me get it to display again. I will update this post at some point if I see it again. I’ve seen it maybe 4 or 5 times over the last two days as I’ve been building this page.
I’m not entirely sure how option sets work behind the scenes, but if all the images are retrieved when a page loads, the issue might have more to do with “showing less” than “making smaller”, as the number of HTTP requests impacts page speed.
Also, keep in mind that by default, JPEG images are automatically processed by Imgix to generate a context-optimized version for your Bubble page (which is a good thing). I don’t think SVG images are processed by Imgix by default (which is also a good thing since an advantage of SVG, in addition to being resolution-independent, is that they’re generally smaller file sizes).
How are you displaying them on the page currently? I mean, which Bubble element are you using - the standard Image element? Or are they the background image for a different type of element? Or something else? Let me know, as I might have another tip.
Oh, ok. In that case, there is actually a way to have your cake and eat it too - i.e. deliver ALL of your images to the browser with ZERO http requests. It’s a technique often used for small design-related images such as icons, logos, etc. How? Meet our friend, the data URL.
A data URL contains the actual image data in the URL itself - typically encoded in base64. In other words, the image data is simply encoded into a long string of text - i.e. the URL is the image data. It doesn’t point to a file somewhere. And because it’s just a URL, it’s served inline with the page content, so the browser can render it immediately with no HTTP request required to fetch the resource.
For instance, if you copy and paste the following into your browser address bar, you should see the logo appear immediately (even if you’re offline)…
The drawback is that base64 encoding bloats the file size by 20-30%, so it makes sense only for small images. The data, which is just a text string, will reside in the database (or the option set in this case).
So in Bubble, you could do something like (vector images were used in this example)…
How well it will work for your situation, I can’t say; but it might be worth experimenting to see if there’s a performance benefit.
Good luck!
EDIT: Oh yeah, I forgot to address the obvious question. How do you convert the image into base64? One option is to use an online utility like this one.
This sounds like a promising idea. I will check it out. Seems like it could help me out on some other image related things I’m doing such as an automatic image gallery that shifts between about 15 images on a timer every 5 seconds.
Hey @boston85719 - curious to know your findings here! I’m using lots of SVGs pulled from option sets too and wondering whether or not I should bother switching to data URLs
For background I’m building a fashion ecommerce web-app which will involve lots of product images being pulled from the database so I’m conscious that’s already going to inevitably impact performance even with imgix encoded images, so I’m trying to optimize as I go where I can to compensate.
Also for something like my described use case, do you have any high level thoughts on how best to structure the database? Any / all advice and wisdom you might have to impart is greatly appreciated!
I am not sure what findings you are referring to. But if you asking about the difference between using options sets with images as an attribute vs option sets with images as an html element using the svg code, I now use the svg code and place it into an html element and I have no problems with page load speed of these images showing up.
That’s pretty much what I was referring to - whether to use SVGs from option sets or to use them directly in HTML elements, and it seems the answer is the latter. Thank you!
@boston85719 and @sudsy , would you recommend HTML encoding of images as a default strategy whether they’re being used as an option or straight from the DB? Are there any situations where you wouldn’t bother with the encoding?
Not sure what you mean by “HTML encoding”. There’s base64 encoding (where the actual binary data comprising the image is converted into text and stored inside a text field), and then there’s simply referencing the image by its URL, in which case the browser makes an http request to fetch the image data (which is the “usual” way). Unless poor performance (really slow page rendering) is an issue and there are only a few small images, then I don’t see a reason to use base64 encoding (which also bloats the image data by about a third).
Thanks @sudsy , I mixed up the terminology due to @boston85719 's most recent post - I thought he was talking about base64 and accessing images via url, maybe he wasn’t.
In my use case I have a number of country flag icons (svg), and a number of currency/crypto/company icons (mixed file types, working toward svg) that may not need to be stored as option sets. I don’t need to access the icons on every page load, but when they are accessed it will often be in bulk via RG. Until now I had the country flags in the DB with a custom state (I think, been a while) to access them for a drop-down I made using a vertically scrolling RG. This is what I was going to do for the other icon sets until I stumbled upon this thread. As I hadn’t imported all of the other icons as image files yet I figured now was a good time to ask for the best practice.
If you have very small SVG images and a lot of them, you could try both ways and see if there’s an appreciable impact on performance. I would not recommend option sets for that though. Either store them in a text field in the DB encoded as base64, or else as regular Bubble image types. The latter approach will make a separate http request for each image, whereas the former will include the image data directly from Bubble’s server when the data for the RG is fetched.
I don’t know if it’s worth your time to do such a comparison, but if performance is the primary objective, that’s the only way to know for sure.
EDIT
Actually, for SVG, you shouldn’t need to base64 encode, since the SVG format is already text (XML). (Don’t know what I was thinking.) Anyway, you can get a rundown on how to inline SVG images here. You would first properly construct the URL and then display it as an image on the Bubble page.
Thanks @sudsy this is very cool. I’m going to do the comparison in the next few weeks and i’ll update the thread with my results. I have a bunch of icons that haven’t made it into the DB yet that are PNGs so if it makes much of a difference for the SVGs i’ll just adopt the practice of using text-field images across the board.
Have you had any issues with the SVG file not rendering correctly or not rendering correctly after a few loads? Errors include: wrong width/height, incorrect colours, errant lines etc. I’m working with a set of country icons so these are more than just monocolour icons. perhaps that’s why? They are all 3:4 aspect ratio - height=“24” width=“32” viewBox=“0 0 640 480”
