I am populating a repeater with data queried from the backend. Using console.time(), I am finding the following loading and execution times:
page warmup (until $w.onReady()): 100ms;
query of 20 items: 200ms;
forEachItem (of the repeater) function running directly after queries: 100ms.
Note: values come from the published site.
So, all gets done in a very short amount of time: let’s round it up to 0.5 seconds in total. This should be indicative of it not being a local performance/internet connection issue. However, the visual population of the repeater has a best-case waiting time of at least 17 seconds after the page has been loaded and the repeater data has been assigned to the queried results.
Setting the repeater properties to ‘collapsed on load’ or ‘hidden on load’ and expanding/showing afterwards do not change loading time of the repeater noticeably.
I’d like to know what should be the cause of this seemingly extraordinary loading time (it really shouldn’t take so long to populate a repeater with only 20 items, should it).
Any thoughts/suggestions/insights are appreciated.
@vicihealthco Is your repeater connected through code? Keep in mind this forum is for the Corvid product only, so if you have code post it here in a code block. If it’s connected through a dataset, try connecting it through code to debug it first and post your issues here, or else contact Wix support.
As implied by the first sentence of my post, I use wixData.query()… .find() in the backend - and a simple $w(‘#repeater’).data = results.items in front.
Was able to make it a lot faster already by incrementally assigning data to the repeater so it has to load only 5 containers per assignment (20 containers show on page afterwards). However, even after optimising this and the ‘load more’ behaviour*, it’s responding very slow to my actions - which are only button hovers/clicks - after 40 items or more are shown on page (1 ‘load more’ event).
I am thus starting to think this is a repeater code issue on Wix’s side more than anything, especially since I have seen other posts pointing out its slowness. Hoping you guys will have a look into this.
Otherwise, I’m thinking about maybe using a table, but I don’t know whether I can implement buttons in a table and/or if it’s faster at all. Do you have any suggestions?
Would appreciate your recommendations for improving site speeds given the repeater’s slow visual load time. Confident it’s not my code, that’s why I emphasise the visual part of it.
*After the first 20 items are loaded (visually), I immediately load 20 more items into the repeater with collapsed containers. When the user scrolls down, the 20 pre-loaded containers are expanded, but even this usually takes up to 5 seconds. Then I load 20 more collapsed items again and the process repeats if the user keeps scrolling down. After displaying 60 items, the responsiveness is unlike even pre-2010 computer speeds. Again, pretty confident it’s not due to my computer.
@vicihealthco Although you are fetching the data and delivering it with code, that does not mean you are connecting it with code. If you use the onItemReady property of a repeater you can connect it with Corvid directly and thus control the loading behavior.
Bear in mind, even if you are using a backend function to deliver data that does not guarantee a faster load time like a router would.
I see where you’re coming from, maybe my explanation was not clear enough. In my original post, I told I called the forEachItem function of the repeater - thinking it was clear that I connected my repeater with code. However, now I have onItemReady properties set since they would have the same result for the first loaded elements.
Regarding your second note, I do have significantly faster loading times than when the repeater was not connected with code. It still is very slow though. But I guess there’s nothing to do about it yet.
@vicihealthco Sure. For most purposes a router would be noticeably faster. The delay is probably partly due to module load order, and I’m guessing since the data is delivered alongside the HTTP request it can load before these modules intervene.