WeWeb app struggling with RAM usage, versions, variables and missing virtual scroll

Ask us anything
1

Hi everyone,

I’m Pedro Elias, co-founder of LiderHub.ai, a fast-growing platform built with WeWeb + Supabase, currently serving over 400 active users and processing more than 2 million messages.

Over the past few weeks, we’ve been facing a series of technical challenges that are severely impacting our app’s performance and stability. After weeks working on these issues, adding and removing components, isolating sections, and testing different structures, we still haven’t been able to resolve them.

To make it easier to understand our situation, I created this document detailing everything we’ve encountered so far:
:backhand_index_pointing_right: WeWeb Support – LiderHub Challenges

We’ve also reached out to WeWeb support, shared access and videos, but haven’t received any clear guidance or solutions. That’s why I’m now turning to the community to ask:

Has anyone faced and solved issues related to:

  • Significant performance drops in the live version vs staging/self-hosted
  • Memory leaks or very high RAM usage
  • Latency or crashes when updating variables
  • Missing virtual scrolling / inefficient DOM management in long lists

If so, I’d love to hear how you approached or solved these.

Or if someone from the WeWeb technical team could dedicate some time to clarify what’s going on, that would help us a lot. We’re just looking for clear direction so we can move forward confidently.

At this stage, we can’t afford to leave a production app with 400+ users struggling like this, especially when we’re fully committed to the platform.

We’re also open to paying whether through an Enterprise support plan or hiring someone from the community with deep WeWeb knowledge who can step in and help.

Thanks so much for any help or response :folded_hands:

3 Likes
2

Where is your production project hosted? Is the test and production data the same?

1 Like
4

Hey, Mauro! Great to talk to you, I was a student in your community, and it would be a pleasure to chat if you’re available.

I believe you asked about the performance differences between the versions:

  • Staging (WeWeb’s own environment)
  • Live (WeWeb’s own environment)
  • Homologation self-hosted (Brazil)
5

Regarding the performance difference, I would test hosting on Cloudflare. That’s what we’ve always done here, so you can see if there’s a difference in performance. You can access this free tutorial for hosting on Cloudflare (Tutoriais).

Regarding performance, the way the elements are rendered has a big influence, so everything will depend on your logic for loading the elements.

1 Like
13

Curious to see what’s the answers :eyes:

14

@PedroElias any news?

15

Hey @mauromequelussi
No updates so far, the system is still experiencing the same issues reported in the Notion document, and I haven’t received any further response from WeWeb support.

To answer your question, we deployed the app on our own server and the performance was better, but that’s only in comparison to the Live version managed by WeWeb themselves. That might make some sense since I don’t know how WeWeb manages their infrastructure. However, the performance difference between their Staging and Live environments is quite odd, and it seems I won’t get a clear answer about that.

As for the topic I saw the discussing with Broberto, the performance issues don’t seem to be directly related to the hosting location. The app still consumes a lot of memory (over 3GB), with frequent slowdowns and freezes. I agree that this might be linked to rendering conditionals, but the behavior is still strange. Even when exporting the code, it’s not easy to analyze, it’s heavily machine-to-machine structured, with parts in JavaScript, which makes debugging quite difficult.

Honestly, it would take a deep investigation and a lot of time in the codebase to maybe identify the root cause. What would really help is a proper response from support, but unfortunately, it doesn’t look like that’s coming.

Do you have direct contact with WeWeb developers or know of any app that has an enterprise plan with them?

1 Like
16

Something that wasn’t clear, is whether the data for the environments is the same or not?

Another issue, as I mentioned earlier, is that the way the elements are rendered on the screen directly influences memory usage and loading.

Does this problem start to occur after you scroll through the list of conversations and load some conversations? Or does simply loading the page without doing anything else also consume a lot of memory and cause crashes.

I say this because in most of the scenarios I encountered when things were slow, it was precisely how the elements were structured and how they were rendered.

From what I understand, did the problem start occurring recently, or was it from the beginning?

17

Yes, all the data is the same across every environment I tested.

I understand that the elements rendered on the page can affect performance, but the issue is that even when the page is fully loaded, memory usage is already high. As I continue navigating between those already-loaded elements and scrolling through more conversations, the memory consumption increases significantly.

Having high memory usage, say around 1GB at certain points is not necessarily a problem by itself. However, the way state and memory are managed can definitely have an impact. Since I don’t have control over how this is handled internally, I don’t know how WeWeb manages memory under the hood.

The issue happens in both scenarios (staging and live), but it worsens the longer the user stays on the page, especially while scrolling and navigating. Since this is a chat application, users tend to spend a lot of time on it. That’s why I mentioned virtual scrolling. I’m not sure how WeWeb handles components and state under the hood, but it seems like much of it is being stored in flash memory and not being cleaned up properly, which causes this high memory consumption.

These are the technical concerns and questions I raised with the support team, but unfortunately, I haven’t received any answers.

This issue has been happening for quite some time. The chat was never extremely fast, even from the beginning, despite following best practices. I believe one of the main reasons is exactly what I described above, how memory and state are handled by WeWeb. Now, with clients handling over 2,000 conversations, constantly opening and closing chats and sending messages, the problem has become much more noticeable.

Can you explain better about “Another issue, as I mentioned earlier, is that the way the elements are rendered on the screen directly influences memory usage and loading.” and how you solved similar problems?

18

i just ran some memory leak test using the fuit library: GitHub - nolanlawson/fuite: A tool for finding memory leaks in web apps.

and the result confirms that there are definitley some memory leaks:

Bildschirmfoto 2025-06-26 um 14.53.44
Bildschirmfoto 2025-06-26 um 14.53.441126×1786 217 KB

maybe @PedroElias you can also try to run it to see where the leaks happen.
i will create a detailed output for the weweb devs and create a bug ticket.

2 Likes
19

Thanks for sharing

20

Hey,
Maybe you are loading too many items on the page, if you don’t use DOM efficient components and you render all 2000 chats/texts, it will make your app very “heavy”. For example, the “datagrid” element is DOM rendering efficient, so you can upload a few thousand items each time, but it will render only the items shown on the user screen. So you’ll need to use this type of element if you want to upload all the messages or actively render only a few messages each time by using pagination.

21

Thanks for your contribution @jayjay13, it confirms my theory that this isn’t happening only in my app. This app you tested you created or is a example app?

That’s exactly what I wanted to do: document this general memory leak issue. But I haven’t been able to draw many conclusions yet, and I’d need to dedicate a good amount of time to really dive into the code and understand what’s going on.

I’ll try running the project you shared to check for leaks in my app. Alternatively, if I send you the URL, would you be able to run the test on your side as well?

It’s really important that we document all of this properly so we can share it with other WeWeb users and help the support team understand what’s going on. (Hopefully, this time they’ll respond to the ticket.)

22

Yes, you’re right, 2,000 items is quite a lot
But the main point is that these are necessary items that need to be rendered. I can’t prevent users from needing to view them.

I’ve already tried using other WeWeb components like List and DataGrid, but they don’t achieve the same effect as what I have today due to:

  1. Design limitations
  2. Lack of proper infinite scroll behavior
  3. No virtual scrolling, which causes the DOM to grow continuously

The ideal solution here would be to implement scroll virtualization and also investigate the memory leak

23

@PedroElias this is an app I built. the memory leak issue was already like 6 months ago an problem (you can find some community forum post in here).

Yeah you can send me the url (just needs to be a public site otherwise I also would need to credentials).

From the detailed logs it seems that these are the issues (summarized by Cursor AI based on the results):

The InstaSwiss web application exhibits memory leaks during navigation between planner pages. The leaks manifest as:
* Accumulating NavigationHistoryEntry objects
* Unremoved event listeners for DOMContentLoaded and load events
* Retained DOM objects that prevent garbage collection
24

Virtual scroll, you should build this yourself. It’s not that much work, and you dont rely on weweb creating the perfect component that fits your usecase exactly.

Here are my tips:

  • learn to handle the number of dom elements in your page
  • Dont nest unnecesary.
  • Use fixed widths to ease up on intensive dom recalculations. Lots of online resources to learn to manage dom in a good way.
  • Reuse and move around elements instead of destroying elements and creating new ones. This is core element of virtual scrolling as well.
  • Handle loading of resources yourself, dont let weweb ‘automaticly’ handle your datasources. Make sure to remove data you dont need any more. Does wonders on app memory usage.
  • Load what you need, when you need it. And remove it.
  • Having 1000 or 4000 users does not necesarily put more load on your weweb instance, as long as you do not use their proxies. A weweb app is simply a transaction between the client and your backend. Time your backend queries. Check the load of your backend.
  • Locate the source of high memory usage by trial and error.

I’m 100 procent sure that your app can be optimized so it becomes fast again. Just spend some time learning DOM management and dont spend your time waiting for weweb to solve your problem.

25

I believe we have also been experiencing memory leaks for quite a while. The issue is not with data. You can test it by just using standard WeWeb components on a blank project. Use a toggle and button, bind the button’s conditional rendering to the toggle state, and start toggling repeatedly.

The memory usage will just go up and up. Usually this is normal, then after a second or two, the memory will drop to it’s original state, but sometimes the memory will just build and build until the page crashes.

26

@PedroElias

We are having the same memory problem in the app in production.

I have already filed a request, and they only responded with good practices, but the problems persist.

Honestly, we left Bubble, partly because of @mauromequelussi 's influence, but the experience we are having is worse, our project is growing a lot, and the memory problems are growing with it, which is making our business unviable. It is very worrying and disappointing at the same time.

It makes no sense to use a lowcode tool, where you should be even more concerned than choosing traditional programming, and also because you should use few of their components, because if you use too many, we will have memory problems.

Anyway, I think this is a native problem of the platform and I don’t see enough effort from the weweb team to solve it.

1 Like
27

Do you mind sharing a public url to me that I can test we had issues with this a while back. What I found was the possible problem for the memory leak which was native weweb components like inputs and date finders weren’t disposing of the memory properly when it was unrendered so it kept stacking up everytime we opened the pop up with these types of inputs. Weweb did end up fixing the issue we had at some point as we stopped having users say they’ve crashed but I haven’t checked it again recently.

Here’s the post where I go into what I found a bit more in-depth, might help you find if it’s the same issue or a new one. You might need to do some research on how to navigate the memory snapshot data took me a bit to figure out what I was possibly looking for.

Also on another note my editor has been crashing a lot today.

1 Like
28

Hey Bruno, is bad to hear you’re going through this too. I had a very similar journey. I started with Bubble, which is a great platform with excellent support. But when I needed to build something more complex, I decided to move to WeWeb, aiming for a more robust and scalable application using a low-code platform that offers those kinds of tools.

I don’t know exactly how your app was built, but for a while now I’ve been facing serious performance issues and I’ve noticed many others in the community reporting similar problems.

I’ve tried everything:

  • Reported it to support
  • Exported the code to investigate
  • Broke my app into multiple pieces
  • Spent weeks trying to find the real cause

Still, I couldn’t find a definitive solution. Honestly, it’s been pretty frustrating, especially when combined with other issues I’m facing.

My suggestion: consider exploring code-based development. No-code platforms are still great for MVPs and smaller projects, I truly believe in their value for fast development. But they will always come with limitations, and eventually, you become dependent on the platform. Even if you export the code, maintaining it later can be very difficult.

Once you make the switch, you’ll likely feel a huge sense of freedom and control, which helps avoid a lot of the issues we tend to face. Of course, there’s a steeper learning curve, but I’d recommend starting small and testing other tools it really helps you understand how apps work at a deeper level.

Especially now, with so many AI-powered tools available, development is becoming easier even for those without a coding background.

1 Like