Are there any tips to keep browser memory consumption as low as possible? Memory starts off around 400mb but climbs up quick after few navigations to 1.5gb to 2gb.
You have a memory leak somewhere, my best guess is any custom JS formulas or components.
Hey, I’m running into the same issue as Mahdi. I’m using an Input Wrapper component that I apply to every input field. However, when I navigate to another page, the RAM usage isn’t cleared. I don’t have any event listeners in these components, so I’m not sure why this memory leak is happening. Does anyone have ideas—especially in a weweb context?
I think this is a similar issue to what we’re having, I’m not sure what the solution is .This is a ticket I’ve put into weweb support about but heard nothing back.
I noticed there’s an issue with inputs that are causing DOM elements to be detached which is then being referenced in everything linked to it. It looks to be quiet a serious performance issue. In our case it’s a modal and essentially every element in the modal is becoming detached cause at some point it references back to the input.
I’ve tried many different ways so it can clear from detached elements but I’ve had no luck.
I’m not expert on this type of stuff and have only been learning about it while trying to find what the issue is so take it all with a grain of salt. But you can test yourself.
Do a memory snap shot in dev tools and look for the the detached elements you’ll find inputs in there.
There’s some weweb VUE thing that seems to be keeping it referenced.
Are you guys using consitional rendering to show/hide modals/fields?
Yes, I hide the fields conditionally at the start. If all fields remain inactive (and are never activated), no memory is used. However, once the fields are activated, RAM usage increases. This led me to realize that the issue is likely related to the components. The main problem is that even if I deactivate the components, switch pages, and reset all global variables , the memory is still not freed by the garbage collector.
Do you use a custom component for this modal? And are the inputs in a Dropzone of the Modal?
Doesn’t matter how we render the elements, modal anything the detached inputs still happen. I’ve tested this on a new page with nothing else even a fresh weweb account, always get the same issue. It’s possibly related to a chromium issue as well.
Not a custom component its wewebs modal and input components.
Have you already created a WeWeb support ticket? If so, what was their response? It would be great if a WeWeb engineer could weigh in on this issue.
Yes, I created a ticket over a month ago and have had no response back.
I have been trying to find out where this issue is as my application memory usage increases; but it has been hard to find the source. I’ve tried to manually trigger garbage collection without success.
Are you saying you have an issue with input fields? or the modal? I want to try to recreate it, but. Memory usage increases by just navigating back and forth between pages. This is true even though i do not interact with the input.
The input fields are the issue. You don’t need to interact with it, as long as its visible on the page this happens.
Here’s what i mean so people can see, basic page with nothing. Has no detached inputs
I then clicked section which is a simple workflow to show an input and then closed it again ( I’ve then preformed the snapshot then opened again for the screenshot here)
You can see the detached nodes grow massively from this, from my testing this is caused from the input element, if it were just a normal text element this doesn’t happen. Also have found multi select dropdowns can cause this as well.
Hey,
I’ve done a little test on a semi-blank page. In this test i have conditionally hidden (conditional rendering == off) input fields. Then i show them, then i hide them again. The app frees a little memory, but I never go down to the base line. Then i show and hide a couple of times, resulting in increasing memory.
I would guess this happens to more than just the inputs, since my app is not growing from 20-30 mb but from 40 to 2 gb pretty quick.
Great video displaying the issue!
I’ve just had a reply from WeWeb saying that they are aware and it is on a devs todo list but there’s no idea on when this will happen.
You’re definitely right though I noticed it happening on multi-select and I think date picker has a similar issue, but from my testing the date picker can actually be controlled if it’s made into a reuseable component (I think is what I done it’s been awhile).
The issue I noticed when it goes up massively is everything connected to the input (the parent div) gets pulled into the detached nodes as well and not just the immediate parent but everything that contains that div element. So for us everything in our modal becomes detached, which means we have the same issue going from 100mb to 4gb in half a day with frequent use and no page refresh.
Hi,
can you tell me if you used the new input or the old one? (with or without a wrapper)
The issue should be fixed for inputs
We still have the issue with inputs, I don’t know if we use an old or new one? How can we tell @aurelie?
I am running into the same issue, I am using a lot of conditionnal rendering (which I thought would actually help by rendering some element only when needed instead of using display property). What would be the best practice in that case ?
I too have been having a mysterious issue with performance that seems to be consistent with others in this thread. It eventually gets the the point where my iOS PWA will crash.
I know my logic and fetch is good, but my memory just keeps going up and up. The text input keyup change didn’t make a noticeable difference.