I have multiple collections that are utilized throughout the site.
One of the collections is only used when a user is logged in. The other one is for the general public.
How do I ensure that the collection that is used when a user is logged in is not even called from WeWeb.
In the backend, I ensure that the user is logged in before sending data back to the frontend, but I don’t even see a need to make the call and waste the resources when it will not be needed at all.
Hey @kevinwasie 
I think all collections are fetched on page load.
One thing would be to filter them so that they don’t return any data on some pages, but they’ll still be fetched anyway.
Maybe something you can add to the requested features here: feedback.weweb.io
@Quintin Yes, that definitely seems like a needed feature. Practically, there is just no need to load all of those collections when they are not being used. In my case, there are 10+ collections loading with 100’s of records that don’t need to be loaded.
Second, for security, there is no need to expose authorized endpoints the the client side unnecessarily.
@kevinwasie wrong Quintin 
I’m not sure whether this was mentioned, but I had the same query a few months ago. How it works is, in the editor in order to make all the elements bindable to any collection you have. all collections are always loaded. This is not the case in the published version. So your development would be really resource intensive on your backend, but once you don’t work on it as regularly you should see those numbers go down 
I hope this helps you
Ahhh this makes sense. Thank you
Thought I’d add this from last week’s changelog in this thread in case you missed it and for future users who may have similar questions 
We did quite a few things to improve performance in the past few weeks.
First, we optimized how Collections are loaded in the Editor. This won’t impact your published app but will greatly improve your developer experience while building in WeWeb 
BEFORE
All the Collections were loaded in the Editor, even if they weren’t used in the page.
All the Collections were loaded every time you went into Preview mode as well.
This slowed you down while you were building, especially when it meant hitting API limits when using Xano or Airtable on a free plan for example.
NOW
We only load the Collections that are used on the page and that have the “Fetch this collection automatically” setting enabled.
Let’s talk more about this setting.
We added the option to optimize how you want to load your Collections in the Live Project.
By default, when you add a Collection, it will be fetched automatically on the pages that use that Collection in the Live Project.
However, you can disable the setting to gain full control over when your Collection is loaded:
When you disable the “Fetch this collection automatically” setting, you will need to use the “Fetch collection” Action in a Workflow to load the Collection.
For example, if you use a Collection in a Popup element, you can add a “Fetch collection” Action to the Workflow that is triggered to display the Popup.
Joyce, if the collection is not used on the page, but ‘fetch this collection automatically’ is set, is the api called?
No
so it’s safe performance wise to have ‘fetch collection automatically’ on for every collection is that right?
Does it affect performance if we have preserve on navigation?
I’m assuming if we preserve on navigation, it could build up the cache after a few page changes and make it slow?
I’m glad @Joyce clarified that, because I was wondering the exact same thing.
I have my collections set to fetch automatically, but I do not preserve the results on navigation. I feel like most use-cases you would keep that off.
The way I have it set up is when the user is filtering collection results, the collection itself is being filtered by variables that keep getting updated. If the user clicks through to a product page, but then hits the back button to go back to the results, a new API request is made on page load, but the results look the same because the variables I do have set to preserve on navigation.
Then, if there are obvious behaviors like going back to the home page and trying to search again, or cases where the user would obviously be wanting to start a new search from scratch, I have a workflow that clears all of those variables.
My thinking is it’s a lot less data to preserve a handful of variables than an entire collection. But I’m also very new to WeWeb 
If you have a collection that you don’t need immediately on page load, it makes sense to disable the automatic fetch. For example, you might want to fetch a collection when the user opens a modal on a page and not on page load.
Mmm… I think in many cases, preserving on navigation would be a good thing performance-wise because you don’t need to make the API call and wait for the data to come back.
A common use case where you DON’T want to preserve on navigation: a collection that fetches a single item selected on a previous page (if you preserve on navigation, there might be a blink where the info from the previously selected item appears while the API call takes place to fetch the info of the new selected item)
This is especially problematic if the collection data concerns a specific user with potentially private information. You want to make sure that data is not preserved on navigation in case 2 users connect to your app using the same browser.
Does that make sense?
