Do not forget to chose the right answer and mark it as resolved, this will help upcomming coders to find solution faster.
Even if this is still more like a WORKAROUND.
To put it in extreme terms, I think the issue could be solved by preloading all the images from the start and stacking them on top of each other. By fading out the ones you don’t want to show and fading in the one you do, even if animations occur simultaneously, it would just result in a crossfade effect.
Another suggestion I have is that the issue might be because you’re attaching the hover event to the button itself. If you attach the hover event to the container that holds the button, it might react faster and load more efficiently.
I think two images should be enough. Once the mouse enters the container, the image should load, and when it hovers over the button, the image should fade in to replace it. If you handle the switch between the two images this way, it should work smoothly.
You both are flying like bees around their blooming flowers…
You are not far away from possible fast working solution (one of possible solutions).
So we know, that we have some problems with loading timings if it comes to load images on hover. Hovering is a process of milliseconds, so the IMAGE must be delivered in that time. In this case we recognize that loading those images are delayed.
So question → HOW TO LOAD THEM FASTER?
Maybe not on → HOVER ← but already before.
(This you both i think already have figured out).
But how exactly?
Maybe → again using the repeaters → onItemReady() ← and loading the images already before → HOVERING ← but direcly collapsing() or hiding() them and only showing them when needed → on HOVER. ???
Could this work?
This yellow marked field already was the idea behind it.
And what about your IMAGE-sizes and type?
Is there still space to reduce the size of your images? The smaler the image → the faster their loadings.
Depending on how big your images are in size, you even can hold them as base64-data-string inside an OBJECT, but not 100% sure if this will work → again back to the variable-solution, then it wouldn’t matter how much images you have, since you do no stacking but instead pushing your images as BASE64-STRING-DATA into your object!
Could that work ?
1. Direct Access vs. Event Binding
When you store your image URLs (or any data) in an object, you can access them directly by their keys. This is very efficient because JavaScript objects provide constant-time access (O(1)) to their properties.
On the other hand, when you use onItemReady in a repeater, you’re binding event handlers for each item in the repeater. This means that for each item, the code inside onItemReady will run when the user interacts with the item, and this introduces some overhead for each individual repeater item. Additionally, the event handler has to deal with DOM manipulation for each individual item, which can be more computationally expensive.
2. Reduced Overhead
Preloading images into an object or an array before any user interaction reduces the need for network calls or fetching resources repeatedly. This preloading reduces any delay when you access the data later (like when hovering over a button).
Repeaters, on the other hand, require more resources to process the item content and bind interactions (i.e., what happens on hover). This can add up if there are many items in the repeater, causing delays or a reduction in performance, especially for things like images.
I think there is now enough of input about your issue.
Yeah. On a regular HTML page, if you preload images using a script tag or similar method, you usually won’t see this kind of noticeable delay when switching images. Also, on normal HTML pages, once an image is loaded and stored in memory, subsequent loads are much faster.
But from watching Emme’s video, it seems like there’s still a delay even after the first load. That suggests that on Wix, the only reliable way to solve this is by preloading image and then swapping them in when needed.
It’s absolutely essential that the image is loaded before the hover event on the button. And this is something I’ve been thinking for a while now—but maybe the images themselves are a bit too large. Since they’re just simple visuals, you could probably compress them to just a few kilobytes using the AVIF format.
If you’re doing it manually, Squoosh is a great tool for that. And if you’re dealing with a huge number of images and don’t want to go through them one by one, you can also run a local batch conversion program to process them all at once.
For now, I’d say give Squoosh a try and see how it goes!
P.S.
Or, if the images are preloaded in another repeater on the same page, would that mean they already exist in memory, so when other image elements reference the same URLs, they load faster?
Thank you so much guys for your suggestions that made me think and search a lot…
I don’t think is an image dimension problem because they are very few kbites but I’ll do a test for sure with your code.
I’m trying to implement a preloading section but I’m facing some problems. my idea was in pseudo code:
for each item of the repeater, get the image url, load the image, store the image in an array.
then show the corresponding image when hover on button.
I’m facing difficulties since seems that you cannot create new images by code in Wix. Am I wrong or am I looking in the wrong direction?
So it comes in my mind your suggestion @onemoretime
Or, if the images are preloaded in another repeater on the same page, would that mean they already exist in memory, so when other image elements reference the same URLs, they load faster?
so I tried this approach and nothing…i’m facing the same problem. seems like the repeater images, being hidden by default, are like not loaded…
I tried the repeater collapsed image approach as suggested by @onemoretime (not hidden because otherwise it’s not preloaded) but no results . Same lagging.
I tried to prepend all the url in an array ,as @CODE-NINJA suggested, before the hover and then calling the image.src in the mouseIn function but nothing. Same glitch. i did something wrong for sure
I found a way of “preloading” images using fetch(url) method but seems like the glitch is the same… pasting the code for this attempt here.
I don’t feel like i wrote something that actually preload images…