First of all, I‘m a huge fan of WeWeb. The team is doing an incredible job and I enjoy watching every new video - merci beaucoup!!!
Regarding the issue I‘m facing: as others already stated here in the forums, the performance issues of the editor lately give me a very hard time as well. I want to show my client the current state of a project I‘m working on, but I’m experiencing very long loading times and delays, which might make my client doubt that WeWeb was the right choice for the project (and might leave a bad impression regarding my professional expertise as well). Deploying the app and presenting a live version is not possible as we‘re on a free plan and want to upgrade to paid plan once we‘re done with development. It would be great if people on a free plan could deploy at least to a weweb subdomain to be able to check wether the long loading times are only related to the bad editor performance or in fact due to too many complex queries etc.
Can someone from the team give an estimate when this performance issue will be resolved? What are best practices to check the actual performance of the app without already upgrading to a paid plan?
Even thought long load times in editor not necessarily means a slow page when sent to production, it is probably a hint that you are loading to much data in the project.
Go through all your collections, and make sure they are only loaded when needed, and not kept on navigation if that is not needed. Use backend filtering and pagination. Make sure to not use too much calculation for each row in a collection as well.
When you have a better control of what data is loaded, I believe you will find the editor much faster to work with.
I’m not aware of any bad performances related to the WeWeb editor at the moment.
If you share a video of your project in the Editor that shows the performance issues you are experiencing, we might be able to help you optimize your project (or it might help us catch something we’re missing!)
Of particular interest:
how many elements are rendered on a specific page
how many collections are loaded on a specific page
when each collection is loaded (all on page load or some at other times)
how much data is loaded in each collection
how many items are displayed on the page
how long does it take for the backend to send the data
Hi Joyce,
thank you very much for your message!
Indeed, since yesterday, the editor performance is not bad anymore (the editor consumed about 4 GB of memory according to Chrome - I’m not sure if this is related to the fact that I turned off automatic fetching for all collections). However, I’m still experiencing unusual loading times in preview mode. I only use 5 collections (Supabase tables) on this page, one of them has about 100 rows, the others only between 1 and 5 rows, so I doubt that the collections itself could be the reason. I made two short videos to show you what I mean. In video1 you see what I mean by “long loading times” and in video 2 I show how the collection in the table is sorted/filtered by several variables. What could be the issue for this loading time? I’m not using pagination (since I assume that for 100 records, this probably is not necessary). Your help is highly appreciated! Thank you very much!
Thanks a lot for taking the time to provide more information about your project
Actually, asking a web browser to render 100 rows that each contain 4 containers that each contain a text element can be an issue. This is not specific to a frontend built in WeWeb, it’s applicable with traditional coding as well.
So in that case, when you feel the WeWeb editor is slowing down, it’s actually the browser slowing down. The same thing would happen on the published application.
You might want to consider using pagination in combination with a load more button to ask less of the browser and improve the user experiences.
Regarding the variable that takes a long time to update when you click on Alle in your first video, I’m not quite sure what’s going on. Could you show me what the workflow looks like?
Thank you so much for taking the time to reply, @Joyce ! I appreciate it very much.
I made another video to show you the issue with the filtering with the variable and the respective workflow.
Looking forward to your thoughts!
Here is the link: Loom | Free Screen & Video Recording Software | Loom
Hi @julian! This is expected behavior. When you set your filter to “Alle,” all items are rendered, which takes quite some time. If you filter for “M,” for example, you only render a subset of items, which is much faster. The overall performance will be significantly better in the published app than in the editor. In the editor, there is a lot of overhead (logging, navigators, etc.) that won’t be present in the published app.
If you still find the filtering too slow in the published app, you need to limit the number of items you show at once (pagination or infinite scroll).
Hey @Max , thanks for your reply! That’s what I assumed, but since the collection has already been loaded (so it’s already in memory), I didn’t expect it to take that much time to display 100 rows. However, then I’ll check the performance once it’s published and implement pagination if it’s still that slow.
