Editor grinds to a halt whenever there is a repeater on the page

polkaset · August 25, 2021, 1:52pm

I am wondering if anyone is experiencing this. If I have a repeater on a page, the editor is basically non-functional. Every single thing I do takes at least 5 seconds for the editor to respond, and a lot of the time, I get the “Page unresponsive force quit|wait” dialog box in Chrome. This makes developing REALLY cumbersome, as it literally takes me MINUTES to do something that should take seconds.

I started noticing this slowdown many months ago, but it has been getting worse and worse.

My browser is up to date. I don’t have a ton of tabs open. I’ve restarted my browser many times.

If anyone wants, I can do a screen recording of this.

goldiftah · August 25, 2021, 2:02pm

The minute Wix started displaying all of the repeaters with their data in Editor mode rather than just a single repeater as they did in the past it all slowed down. This happens because every little change affects all. It happens in all browsers regardless of the version or OS. Hopefully they will return it to the way it was before.

polkaset · August 25, 2021, 2:09pm

This really needs to be remedied. Development is PAINFULLY slow to the point of being non-functional…not merely inconveniently slow.

It took me ALL DAY to do a simple refactor yesterday. The refactor involved replacing a few lines of code in a dozen or so pages that had repeaters on them. This should have taken 20 minutes.

goldiftah · August 25, 2021, 2:16pm

I totally agree.

quentin · August 25, 2021, 3:05pm

@polkaset Maybe you have some dead loop in your code? Does someone else experience the same editing issue on that website?

Do you notice which page creates the lag? Did you try to reduce your data size (working with sandbox you can delete most of the data)?

If I were you I would simply create a ticket, maybe there is something corrupt with your project

(ps: check your browser console for errors that only appear on that project)

polkaset · August 25, 2021, 4:57pm

There is no dead loop in my code. This happens even if I have NO code.
This happens on every page that has a repeater. Even if the repeater does no database/dataset access, but has its data hardcoded, and even if it does query through a dataset, but the data size is small (the query limits to 12).

For example, I am toggling between several pages in the editor that contain repeaters. In all cases, the editor performance is TERRIBLE.

The first page has a repeater that contains 8 items. There is no dataset involved. I simply have a const struct containing the repeater data, and I am using code to populate the repeater, not the repeater editor UI controls. Editor performance is poor.

The second page has a const struct containing 80 items, First, I created the struct, but did nothing with it. The editor performance was fine. Next, I added a repeater to the page. The editor performance went south even before I configured the repeater to point to the data. I just added a repeater. Next, I configured the repeater in code using onItemReady/data, etc. Editor performance is equally terrible both before and after I configured the repeater to use my const data.

The third page has a dataset with a filter that results in 119 rows that match the filter. The editor performance was fine. Next, I made sure that the dataset was configured limit/page to 12 items (the default). The editor performance was fine. Next, I added a repeater to the page and pointed it at the same dataset. Now the page is UTTERLY unresponsive and it takes 10 minutes to do anything.

Repeater performance is worse when there are a lot of UI elements in the repeater. (some of my repeaters have 10 or more elements in each repeater container pointing to different fields in the data). These pages are hopeless in terms of editor performance.

Whether or not I use a dataset or hardcoded data, whether the repeater contains 8 rows or 80, and whether or not the repeater has 2 UI elements or 10, editor performance is terrible on any page that simply contains a repeater.

Before creating a ticket, I thought I would ask to see if this is a common experience. From Iftah’s response indicates that it is not just me. His observation and conclusions are very plausible, and fit the pattern I am seeing.
Re: console errors. Are you talking about console errors when viewing the site? Or errors when editing the site? The performance problems are not when viewing the live site. They are specifically with the editor. There are some warnings in the console like the one below. I have no idea if this is related to repeaters, though. It’s all obfuscated JS and in the Wix editor codebase, so I lack any context with which to debug this further. Also, I cleared the browser console, then started loading repeater pages, and the warning below did not show up. So this may have been due to something else I was doing in the editor.

plomteuxquentin · August 25, 2021, 6:38pm

I guess this is part of the issue: MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 windowKeyDown listeners added. Use emitter.setMaxListeners() to increase limit. This might be a memory leak.

I don’t encounter your issue so I imagine this is related to your project (maybe start a new project see if you have the same issue on a fresh project) then contact support

goldiftah · August 26, 2021, 10:27am

This happens in various projects we manage as well.

polkaset · August 26, 2021, 2:22pm

That exception is spitting out from the EDITOR, not from my page code. If something is leaking memory, it’s the Editor code.

This is not a problem with my site. I have several other sites, and the moment I put a repeater on anything, the editor has issues.

clsnlsen · August 27, 2021, 10:12am

Gotta mention i have experienced this also. The easiest work around is limiting the repeater to 1 or disconnecting it from datasets and using wixdata instead. Also noticed it becomes much worse the more background things i have (always have youtube running in background making a lot of editor things worse if you want to see the editor break down and cry launch a youtube 360 movie in another window )

Have thought before I find repeaters strange cause even when they preload data its not consistent and often not with what you would see on the preview anyway. Have had several times it loads 3 containers but when clicking preview it would show 10.
So im very against the “loading in editor”. it have a hard enough time already.

plomteuxquentin · August 27, 2021, 1:15pm

@polkaset I’ve never said you code was wrong. I’m seeing the project might be corrupt which create that memory leak, hence my recommendation to have support investigate the project.

I, fortunately, do not experience that issue but as @clsnlsen mentioned I avoid using datasets or limite the number of records displayed.

ic_forrest · September 4, 2021, 4:50pm

I think the problem is that you are loading every item from the database (or every one picked up by a search) into the Repeater in one go. The more items there are the longer it takes, so as you add them, the delay gets worse and worse.

The solution is either an ‘infinite scroll’, which loads 10 or so items, then when you scroll down and hit a marker, the next 10, etc, etc. Or you could have pages with a limited number of items on each.

polkaset · September 4, 2021, 6:14pm

This is happening in the EDITOR , not in the live site. (sorry for the bold and caps…but I’ve made this point many times in this post, and people keep suggesting things that might cause performance problems on the live site). The live site works fine. The editor grinds to a halt and even crashes my browser anytime I have a repeater on the page that I’m editing.

First. This is not a matter of infinite scroll on the live site. It is the editor that is crashing. Whenever I programmatically populate a repeater (as opposed to manually adding items using the Repeater > Manage Items inside the editor), I delete all but the first item in the repeater, just to see what it would look like. So this should not be that the editor is trying to load everything in the database.

Second. No, I am not loading a huge number of items from the database. Right now, for example, my database query returns exactly 11 items, and the full table only contains 12 items. Yet my editor is grinding to a halt and even crashing my entire browser. In fact I just had to hard reload the editor because my entire browser ground to a halt and NO tabs would load without crashing/timing out.

Third. This happens (again…in the editor. Not in the live site) in ALL of the following circumstances:

Populate the repeater using wixData.query (not a dataset). REGARDLESS of the number of items returned by the query.
Populate the repeater using a dataset REGARDLESS of the number of items matching the dataset filter.
Hardcoding the data object in Javascript REGARDLESS of the number of items in the data object.
Adding items manually in the editor (Repeater > Manage Items). Even if there are less than like…10 items.

Again, I am not talking about any kind of performance problem on the live site. I simply mean that the editor grinds to a halt and becomes totally unresponsive. Everything I do in the editor takes several minutes to do, instead of sub-seconds, like it should.

ic_forrest · September 4, 2021, 9:06pm

Sorry, I should have read further before commenting.
I also find the editor variable and sometimes impossibly slow.

goldiftah · September 5, 2021, 5:45am

Did anyone here open a case about this for Wix? What was their response?

polkaset · September 5, 2021, 1:42pm

I created this screen recording as a reproduction of what’s happening. Because my screen recording mechanism doesn’t show things like mouse clicks, I have accompanied it with a timeline/script.

And created this issue:

In the video attached, you will see me trying to do the following:

switch from the page “toxic-to-dogs” to “clay-tolerant”
find the string “/plant/” in the page code for that page
Paste in one line of code

This should take NO MORE than 10 seconds. Instead, it takes 2.5 minutes.

0:00 - Click on the page “clay-tolerant”
0:00 - 0:27 - literally nothing happens…the editor just stalls
0:27 - Get the “page unresponsive” dialog from Chrome. Click “wait”
0:30 - The editor FINALLY switches to that page (yes…it took 30 seconds to switch to a different page in the editor)
0:30 - 0:55 - Try, in vain, to search for the string /plant in the code search. The editor is completely unresponsive
0:55 - The editor is still unresponsive and I get the “page unresponsive” dialog from Chrome. Click “wait”
0:55 - 1:30 - Try to ctrl-F to find the string “/plant” in the page code. The editor is totally unresponsive. At 1:28, I again get the “page unresponsive” dialog. Click “wait”
1:45 - I am FINALLY able to go to the line of code I want. Now I just need to paste in one line of code. The editor once again becomes unresponsive.
2:04 - get the “page unresponsive” dialog from Chrome. Click “wait”
2:20 - I am finally able to paste in the 1 line of code.

marlowe-shaeffer · September 20, 2021, 4:42pm

Hi everyone,
The team investigated Tracey’s issue and discovered a regression due to an experiment we’re rolling out. If you’d like your site investigated to see if this is the reason you’re experiencing repeater issues, please reply here with your site URL. Thanks!

goldiftah · September 21, 2021, 11:57am

Can you please check our site as well?
www.aromaspa.co.il

marlowe-shaeffer · September 21, 2021, 3:18pm

@goldiftah Can you please provide some more information or steps to reproduce? At first glance, everything seems OK.

Topic		Replies	Views
How do I improve the editor performance Ask the community design	10	276	August 5, 2021
Editor loading Super Slow/Crashing also site is super slow. Ask the community partners , code , technical-talk	7	77	June 21, 2019
Freeze or Crashing Editor Ask the community code , question	9	4379	December 4, 2019
New repeater 'live' content in wix editor is killing editor performance Ask the community code , question	0	62	April 24, 2021
Wix Editor slowness workaround Ask the community code , question	3	154	May 20, 2020

Editor grinds to a halt whenever there is a repeater on the page

Related topics