I think they are currently looking into my test I ran (see above). At least they asked if I’m using the columns element in the app, which I’m not. But seems that this element is already a known issue for memory leaks. Let’s see if WeWeb really works on this..
But I agree, with all the Vibe Coding tools popping off, WeWeb really needs to get this fundamentals straight otherwise the platform won’t have a great future..
hello everyone, thanks for sharing your feedback and sorry you are experiencing performances issues. We’ll have someone from the team reaching out to some of you so we can gather detailed feedback and identify where the problems come from.
Hi Pedro,
First of all, thanks for taking the time to document and explain your issue clearly. I regularly work on performance topics in the WeWeb code, and these are always challenging problems. It’s often a mixed situation between the client logic and WeWeb’s internal code. I usually have knowledge of the WeWeb internals but not the client logic, and for you (generally speaking), it’s the opposite — so no one fully understands both sides.
We’ve investigated several apps and tried to reproduce the issue with simpler use cases when possible. We’ve already identified and fixed several memory leaks related to components, and these fixes have been released in updated versions.
Also, each component in WeWeb consumes memory, and it’s fairly easy to build a page that uses too much of it. That’s why many support replies point to guidelines for optimizing memory usage.
Here are some initial answers based on a first read of your document:
Question 1 – Difference between environments
The code (on WeWeb’s side) can differ between the editor and the published app, but it doesn’t vary between staging and live environments.
Most of the time, when there are performance differences, it’s due to:
Question 2 – JSON causing freeze
If a large JSON object is being updated, there’s a good chance it’s also triggering significant re-rendering. That’s how Vue (the framework WeWeb relies on) works:
Data update ⇒ DOM update.
There are many mechanisms to minimize these re-renders, but since some of them depend heavily on your own logic, it’s difficult to automate everything perfectly.
Could you DM me more details about your use case? (a link to the exact page in the editor, with an account and reproduction steps) — I’ll be happy to advise you on a strategy.
Question 3 – Memory usage
As mentioned before, memory usage is closely tied to the number of elements rendered. We continuously work to reduce overall memory usage, but the total will always depend on what’s actually rendered in the app.
As several users have pointed out, virtual scrolling is key here — it prevents entire lists from being rendered all at once. Some components are already built with this in mind (like the new grid). I’ve reached out to the product team about your case to explore whether we could create another generic list component with built-in virtual scrolling.
Question 4
(See answer to Question 3.)
Question 5 – Supabase
I’m not directly working on this, but I know that an update is in the works with the new SDK version.
Question 6
You should have received updates from the support team by now, if I’m not mistaken. Our team is doing its best to respond as quickly as possible, but some questions require internal discussions before we can provide a solid answer.
@Slavo can follow up with you specifically regarding the Enterprise plan.
Hi @thomlov ,
Thanks - when you say ‘remove data’ do you mean to clear collections? Can you please explain HOW to remove data? (I have a single page app so turning off ‘preserve collection’ doesn’t do much).
I’m mostly using components for this, I create a component, and store data inside the component.
When component is removed the data inside it is cleared.
For example:
I have a virtual table consisting of 30-50k items, as a component. Inside the component I have a component variable where I store data used in the list. I start with fetching the first 50 items from a supabase query in a workflow (not collection) and when the user scrolls, I check the variable if I have the necessary items for the rows visible in the current viewport. If I dont have the data, I ask for another 50 rows from supabase, and add it to the data variable, and it fills the current viewport with data (Here I use virtual scrolling as well, making sure to not render any data not present in the current viewport).
Now, when the user scrolls this table the variable will fill up. When it has 2000 items, I start clearing the rows furthest away from the user viewport. So even if the supabase table has 50k rows, I will never store more than 2000 items in the component variable.
Then, when the user goes to another page in my app, this component is removed and all data within it is also cleared.